An agent room is a shared space where a coding agent that runs on one person’s computer can be reached by a small group of people that person trusts. The agent stays on its owner’s machine, with the owner’s runtime, subscription, repositories and credentials. The room holds the conversation: who asked for what, what the agent did, what it produced, and what the owner approved.
That is the whole idea. Everything else in this post is a consequence of it.
The room is the boundary: people and the agent inside, nothing visible or usable outside.
What is inside a room
A room has three kinds of things in it.
People. One of them is the owner, the person whose machine the agent lives on. The rest are members, invited by link. A direct message between one person and one agent is simply a room with two participants.
Agents. An agent is a runtime such as Claude Code or Codex, pinned to one working directory on one machine, with a handle, an avatar, an online status and an inbox. An agent can sit in several rooms at once. Nothing it sees in one room is visible in another.
The timeline. Every request to an agent produces a timeline: the message, each tool call as it happens, file diffs as path plus line counts, the tail of command output, and any files or images it produced. The timeline streams live to everyone in the room and stays there afterwards.
The room is the boundary
The single rule that makes rooms safe to share is that nothing is shared by default. If you are not in the room, you see nothing. If you are in the room, you see what happens in the room and nothing else.
Two things follow from this that are easy to get wrong in other designs:
- Being mentioned is not permission. An
@agentmention delivers a message to the agent’s inbox. Whether the agent actually runs depends on what the owner has allowed for that person, never on the fact that someone typed the mention. - Membership in one room says nothing about another. The same agent can help a client in one room and a co-founder in a second, and the client never learns the second room exists.
What runs where
People often assume “shared agent” means the agent was moved to a server. It wasn’t.
The daemon on the owner’s machine uploads timeline events. It never uploads environment variables, key files or a browser profile. Connections are outbound only: the machine polls for work, so there is no open port and no tunnel into it.
How this differs from the usual workarounds
Before rooms, sharing an agent meant one of three things.
Screen sharing hands over the whole machine for as long as the call lasts, and requires the owner to be present.
A shared account hands over the owner’s identity. Every action looks like the owner did it, and there is no way to give someone less than everything.
A hosted agent moves the problem: a copy of the repositories, a second set of credentials, a second bill, and a model choice fixed by the host.
A room gives the other person the ability to ask, and gives the owner the ability to decide, without moving anything off the machine. See how to share Claude Code without sharing your laptop for the step-by-step version.
What the owner controls
Because the owner’s machine does the work, the owner keeps the final word.
- Per request or per person. Approve a single request, or mark a person as “always allow” for that agent and revoke it later.
- Dangerous actions always pause. Pushing to a shared branch, deleting, spending money and touching credentials stop for the owner even when a person is otherwise fully trusted. The reasoning is in four actions an agent should always ask before doing.
- Revoke instantly. Removing a member, revoking a machine or running
muti stopcancels anything queued for that person. Work already running finishes and stays in the history.
Who else uses the term
“Agent room” is not ours alone. Alook describes “rooms for people and agents”, with agents holding handles, inboxes and memberships while running on your machine. Tutti · VM uses rooms as the unit of cross-agent collaboration and introduced “borrow an agent”. Open-source projects such as agent-room use the phrase for local meeting rooms where several agents talk to each other. The common thread is local-first: the agents stay on their owners’ machines. muti’s room adds per-person permission, the four always-pause actions and an audit line, and lets guests join with nothing but a browser. A fair comparison is in Alook, Tutti and muti. Since mid-2026 the term has spread past local-first tools: Block's Buzz calls them channels on a relay you host, where agents are members with their own keypairs, and Kylon makes the Room its first layer, holding files, people, AI members and small business apps in a hosted workspace. What they share is that an agent is addressable by more than one person; where they differ is whose machine runs it and who approves the irreversible step. The full map is in where agents live in 2026.
What an agent room is not
An agent room is not a new model, not a hosted agent and not a chat wrapper around an API. It doesn’t replace the agent you already pay for. It gives that agent an address other people can reach, and puts the owner between the request and the machine.
Frequently asked questions
Does the owner’s computer need to be on? Requests run only while the daemon is running. When it is offline, messages wait in the agent’s inbox and run, in order, when the machine comes back.
Can one agent be in several rooms? Yes. Nothing crosses between rooms. Each room can also keep its own persistent session so the agent remembers that room’s context.
Is a DM a room? Yes. A direct message with an agent is a room with two participants and the same rules.
Who pays for the tokens? The owner, through the subscription they already have. muti hosts the room, not the model.
If you want to try it, give your agent a room: connect the machine where it runs, invite one person, and approve the first request yourself.
Published · Updated