One Atlarix session can talk to another. Not through a shared file or a database — through direct messaging, with the sender knowing who received it and when. Here is how peer messaging works, what it can do, and why it matters for workflows where more than one agent is working at once.
What peer messaging is
Every Atlarix session — in the desktop app, the CLI, VS Code or any ACP editor — can see the other sessions running on the same machine. list_sessions shows them: their name, their workspace, whether they are busy, and what model they are using. send_message sends a message to one of them, and the message arrives as a peer message in that session's conversation, attributed to the sender.
What a session can send
A message can be plain text — a task, a question, a piece of context. It can also carry control: set the target's mode (Build, Explore, Plan, Debug, Review), set its model, or answer its pending plan (approve, reject with a reason, or replace it entirely). The target shows a line saying who changed what, so nothing happens silently.
Knowing when it finishes
send_message with notify_when_done: true delivers one notice to the sender when the target's turn ends — how it ended, and the same summary result_of would show. So a session that delegates work does not have to poll; it gets told. The notice arrives as a peer message in the sender's conversation.
Reading another session's results
list_sessions with result_of shows another session's latest finished turn: how it ended (with the error kind if it failed), its reply (long replies are cut, with how to ask for the rest), and the files it changed. A session that sent a task can read the outcome without opening the target.
Where it works
Peer messaging works across every surface: the desktop app, the CLI, VS Code, Cursor, Kiro, Windsurf, Zed and JetBrains IDEs. A CLI session can message an app session; a VS Code session can message a Zed session. The only requirement is that both are running on the same machine, signed into the same account.
What it does not do
Peer messaging is not a shared context. Each session has its own conversation, its own memory, its own model. A message is a message, not a merge. The sender does not see the target's full history, and the target does not inherit the sender's context. That is deliberate: it keeps each session's work isolated and auditable.
Peer messaging shipped in Atlarix 15.10, with mode and model control and plan approval added in 15.11. For the full multi-agent workflow — fork, lead, approve — see multi-agent coding.
FAQ
Can Atlarix sessions communicate with each other?
Yes. One session can list the others, send them messages, set their mode and model, approve their plans, and get notified when they finish.
Does peer messaging work across different Atlarix surfaces?
Yes. A CLI session can message an app session, a VS Code session can message a Zed session, and so on. All surfaces on the same machine share the same peer network.
Top comments (0)