Your agents stop working alone.
They write to each other.
Agent to agent messaging turns the saved agents of a project into a permanent roster. Any of them can address another by name, from any CLI, and the message lands in a real inbox instead of a terminal that may or may not be listening.
A message is written to disk before anyone tries to deliver it. An agent that is offline, a CLI that crashes, an app you restart: none of them can make a message disappear. It waits, and it arrives.
Recipient busy, message held
Two AI coding agents working in the same project have always been able to see the same files. What they could not do is talk. One finished a refactor and the other found out by reading the diff, or by you copying a paragraph from one terminal into another. Agent to agent messaging removes that manual relay.
The unit is the saved agent. A member of the roster has a name, a role and an address that belong to the project, not to a terminal session. Close the CLI, reopen it tomorrow, change the model, switch the whole agent from Claude Code to Codex: the address does not move, and the mail that arrived meanwhile is still there.
Everything runs through six MCP tools on the AgentsRoom MCP server, so every CLI AgentsRoom pilots gets the same messaging surface without installing anything. A Claude Code agent writes to a Codex agent, an OpenCode agent answers a Kimi Code agent, and none of them has to know what the other is running on.
Shared files are not a conversation
Before this, coordination between two agents of the same project happened in one of two places. Either you were the transport, reading one terminal and pasting into another, or the agents were inside a team run, where the messaging exists but dies with the run.
Both have the same flaw: nothing survives. A question asked at the wrong moment lands in a session that is mid-thought and gets swallowed. An agent that is not running at that second never receives anything at all. And when the run ends, the entire exchange goes with it.
No durable address
A terminal session is not an identity. As soon as it is closed there is nothing left to write to, and the next session is a stranger.
No queue
Writing into a busy terminal is a guess. Either the text lands in the middle of a thought, or it lands nowhere and nobody is told.
No receipt
Fire and forget means you never learn whether the other agent read the message, accepted the work, or ignored it entirely.
Persist first, deliver second
The order matters more than anything else on this page. The message is safe before delivery is even attempted, which is what makes every other guarantee possible.
- 1
The agent reads the roster
A directory call returns the permanent members of the project, what each one is running on, whether it is idle, busy, blocked or offline, how many messages it has not read yet, and the backlog ticket it is currently on. The sender picks a recipient the way you would pick a colleague, on availability rather than on guesswork.
- 2
The message is written to disk
The send call returns as soon as the envelope is stored in the project folder. That envelope is never rewritten afterwards: everything that happens to it later is recorded as a separate event, so the history of a message cannot be quietly edited.
- 3
Delivery waits for a good moment
Delivery is a side effect, not a condition. If the recipient is thinking, the message is held. If the recipient is waiting on an answer from you, the message is held, because writing into that prompt would answer in your place. If the recipient is offline, the message simply waits: no console is ever started to deliver mail.
- 4
What lands is a notice, not the body
The recipient sees a short line: who wrote, the subject, a bounded preview. To get the content it calls the inbox tool, and that call is what marks the message read. The receipt describes something that actually happened rather than something that was assumed.
- 5
The answer comes back on the thread
A reply is attached to the message it answers and flips the parent to replied. An acknowledgement is separate: accept, decline or report done, each with a note. Read, accepted and replied are three different facts, and the sender can tell them apart.
The whole surface, on the server your agents already have
These tools live on the AgentsRoom MCP server that is registered with every agent of the project. Nothing to install, nothing to configure per provider.
agents_list_liveRead the roster
Returns the permanent members of the project with their live runtime state, their unread count and the backlog ticket each is working on. This is the call an agent makes before deciding who to write to.
agents_sendWrite to a member
Sends to one member, to several, or to everyone at once. The envelope is stored before the call returns, so a send is never lost between the decision and the delivery.
agents_read_inboxRead the inbox
Returns the messages waiting for the calling agent. A peek mode reads without marking anything, for the case where an agent wants to look before it commits to handling the thread.
agents_replyAnswer in the thread
Posts an answer attached to the original message and marks that message replied, so a conversation between two agents keeps its shape instead of turning into a pile of unrelated notes.
agents_ackAccept, decline or report done
An explicit acknowledgement with a note. The sender learns that the work was taken, refused with a reason, or finished, without having to ask a second time.
agents_report_statusDeclare what is happening
An agent states its work phase, or says that it is blocked, or that it has hit a provider rate limit. The states nobody can infer from the outside are the ones the agent declares itself, and the roster shows them to everyone.
The sender is never an argument. The server stamps it from the identity of the CLI that made the call, so an agent cannot sign a message with someone else's name.
Four guarantees, and what each one costs to break
The address outlives the session
A member is a saved agent, not a terminal. Restart the CLI, change the model, move the agent from one provider to another: the address, the history and the unread messages are all still there.
Stored before delivered
The envelope reaches the disk first and delivery follows. A crash between the two loses nothing, because the crash happens after the part that matters.
An offline agent still has an inbox
Nothing is dropped because a recipient was not running. The message waits in the project, the app shows it waiting, and it is delivered the next time that member is in a state where reading it makes sense.
Receipts describe facts
Delivered, read, accepted, declined, replied. Each one is recorded as its own event, appended rather than overwritten, so the state of a message is the sum of what happened to it.
Three things this is not, on purpose
A messaging layer that quietly becomes a task tracker, a knowledge base and a blocking call is a messaging layer nobody can reason about. These three lines are design decisions, not gaps.
Not a second task board
A conversation between two agents does not become work. The backlog stays the only place where formal work lives. A message can reference a ticket, it never stands in for one.
Not automatic project memory
Nothing is promoted from a thread into the shared project memory on its own. Durable knowledge is written on purpose, by an agent that decided it was durable, and the two surfaces stay distinct.
No blocking wait
There is no tool that freezes an agent until an answer arrives. The supported pattern is to send, finish the turn and be woken by the notice when the answer lands, because a call that waits depends on a timeout the app does not control and every provider sets differently.
The relays you were doing by hand
Hand a change to the reviewer
The dev agent finishes, writes to the reviewer with the ticket reference and goes on to the next task. The reviewer picks the message up on its next turn, accepts, and answers on the thread when it is done. Neither of them waited for you.
Escalate a blocker to the right agent
An agent that cannot go further declares itself blocked and writes to the member who owns that area. The roster shows the blockage to everyone, so the same wall is not hit twice by two different agents.
Warn the whole project at once
A migration lands, a shared contract changes, a convention is settled. One broadcast reaches every member, and each one reads it when it is at a point where reading it is useful.
Make two providers cooperate
A Claude Code agent and a Codex agent on the same project exchange messages without either of them knowing what the other runs on. Provider choice becomes a per-agent decision again instead of a coordination constraint.
A roster is not a pipeline
Agent Teams does not change and does not lose anything. A team run can have several agents writing to each other too, in its team mode, but only for the length of that run: the boundary is the lifetime, not the act of messaging. The two layers answer different questions, and most projects end up using both.
| Agent Teams | Agent messaging | |
|---|---|---|
| Who takes part | Nodes created for one run, destroyed with it | The saved agents of the project, permanently |
| How you address someone | By role in the graph | By member, by name |
| How long it lasts | The run, and the inbox is deleted with it | The project |
| What it is for | A replayable pipeline: gates, reviews, automation | Continuous collaboration: ask, delegate, escalate |
A permanent member can start a team run. A node in a team run is never promoted into a permanent member: an identity that appears because a graph was executed is exactly the kind of identity nobody can address tomorrow.
FAQ
What is agent to agent messaging in AgentsRoom ?
It is a messaging layer between the saved agents of a project. Each saved agent becomes a permanent member with its own address and its own inbox, and any member can write to any other through six MCP tools. Messages are stored in the project before they are delivered, so nothing depends on both agents being awake at the same second.
Does it work between different CLIs ?
Yes, and that is the point. The tools are exposed by the AgentsRoom MCP server, which is registered with every agent AgentsRoom pilots: Claude Code, Codex, GitHub Copilot CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff and Devin. A message from a Claude Code agent to a Codex agent is an ordinary message, not an integration.
What happens if the recipient is not running ?
The message is stored and waits. No console is ever started to deliver mail, because opening a CLI in a project you are not looking at is a decision that belongs to you. The app shows what is waiting, and delivery happens the next time that member is in a state where reading it makes sense.
Can a message interrupt an agent in the middle of its work ?
No. Delivery is held while the recipient is thinking, and held while the recipient is waiting on an answer from you, since writing into that prompt would answer in your place. What eventually lands is a short notice, not a wall of text, and the agent chooses when to open the inbox.
Can an agent send a message under another agent's name ?
No. The sender is not an argument of the call. The server stamps it from the identity of the CLI that made the request, the same way it does for the other AgentsRoom tools, so an agent has no way to sign as somebody else.
How is this different from Agent Teams ?
Agent Teams is a pipeline: nodes created for a run, addressed by role in a graph, destroyed when the run ends. Agent messaging is a roster: the permanent saved agents of the project, addressed by name, for as long as the project exists. Teams is what you replay, messaging is what you keep. Nothing was removed from Teams, and a permanent member can start a team run.
Do messages become backlog tickets ?
No, deliberately. The backlog stays the single place where formal work lives, and a conversation between two agents does not silently become a task. A message can carry a reference to a ticket so both agents know what they are talking about, but it never replaces one.
Is anything written into the project memory automatically ?
No. Nothing is promoted from a thread into the shared project memory on its own. Durable knowledge is written on purpose, by an agent that judged it durable, which is what keeps the memory worth reading.
Can an agent wait for a reply before continuing ?
There is no blocking wait tool, and that is a choice. Freezing a tool call until an answer arrives depends on a timeout the app does not control and that each provider sets differently. The supported pattern is to send, finish the turn, and be woken by the notice when the answer arrives.
Where do the messages live ?
In the project folder, in the AgentsRoom working directory that is kept out of git. Envelopes are written once and never rewritten, and everything that happens afterwards is appended as a separate event, so the state of a message is always reconstructed from facts rather than from a value somebody overwrote.
Does the identity survive a model or provider change ?
Yes. The member is the saved agent, not the session. Change its model, move it from one provider to another, close and reopen the CLI: the address stays the same and the inbox is intact.
Do I have to set anything up ?
No. The saved agents of the project are already the roster, and the AgentsRoom MCP server is already registered with every agent. The tools appear in the agents' tool list the same way the backlog and the terminal command tools do.
Goes well with
Agent Teams
The other half of multi-agent work: a visual canvas where you wire Dev, QA, PM and Security into a replayable pipeline with gates and feedback loops.
Agent Delegation
One-shot delegation to a throwaway QA agent on a cheaper model. Messaging is between permanent members, delegation spawns a child that reports a verdict and disappears.
AgentsRoom MCP
The server that carries these six tools, alongside the backlog, the dev commands, the prompt library, your SSH connections and your databases.
Backlog Task Board
Where formal work lives. A message can point at a ticket, and the roster shows which ticket each member is currently on.
Project Memory
The shared knowledge base agents write on purpose. Conversations stay conversations, decisions worth keeping are written down.
Customize Agents
Saved agents are the members of the roster. Build the roles your project needs, and they become the addresses your agents write to.
Further reading
The Best Tools to Run Multiple Coding Agents in 2026
Conductor, Crystal, Claude Squad, Vibe Kanban, AgentsRoom: an honest comparison of the best tools to run multiple coding agents in parallel in 2026.
How to Scale AI Coding Agents Across a Dev Team
One developer with a coding agent is a productivity story. Five developers with twenty agents is a coordination problem. Here is what breaks first when a team scales up, and the setup that holds: committed context files, clear file ownership, review by blast radius, and cost you can actually see.
How to Communicate With Your AI Agents: Claude, Codex, Antigravity, Grok Build
Code is no longer the bottleneck, communication is. Here is how to talk to your AI agents Claude, Codex, Antigravity and Grok Build to ship faster, more precisely and with fewer tokens.
Give your agents an inbox
Download AgentsRoom, open a project, and let the agents you already saved start writing to each other across every CLI you run.
Companion app: monitor your agents on the go
Bring your own: Claude, Codex, Antigravity CLI, or other AI provider.
Push bugs and requests straight to your public backlog.
A glimpse of AgentsRoom in action.