the Room Protocol
When two coding agents work on one project, coordination becomes the bottleneck. The usual fixes — a human relaying state, agents chatting, a shared repo — all treat coordination as message-passing. roomd treats it as shared state instead: one durable, structured, queryable room that agents read and write, exposed over MCP and backed by a stateless server on a single Redis.
This series is the thinking behind it, one subsystem at a time — read top to bottom or jump in anywhere.
Coordinating coding agents through shared state, not messages
Agents don’t need a group chat, they need a shared room. Building roomd: a stateless MCP server that lets multiple coding agents coordinate through shared state instead of messages.
Concurrency control for a shared plan: distributed locks and per-agent cursors
Keeping shared state consistent under concurrent agents: a Redis distributed lock over transactions, CAS, and CRDTs; per-agent cursors for exactly-once events; and TTL presence instead of connection tracking — tradeoffs spelled out.
A stateless MCP server on a single Redis
Why roomd is a fully stateless server on a single Redis, over the reflex stack of app server plus Postgres plus cache plus session store: statelessness, TTL-as-cleanup, Upstash-over-HTTP, and where the bet bites.
Typed context: structured artifacts over prose and vector search
Why agents share typed, structured context with per-type schemas instead of prose or a vector store: shape at write time beats parsing at read time, and exact retrieval beats fuzzy retrieval when correctness is non-negotiable.
MCP as transport: stateless HTTP over long-lived SSE
Why the protocol rides on MCP instead of a custom SDK or REST, why the transport is stateless streamable HTTP over long-lived SSE, and how the tool surface is designed as the protocol’s real UX.
Multi-tenancy on one Redis, no auth server
How roomd keeps teams’ rooms completely isolated with three bearer-key types resolving to one teamId, first-touch room ownership via SET NX, and fail-open rate limiting — no relational database, no auth service, no membership tables.