Several agents in one session

To run multiple agents in one session, open one agent view per agent. Every session gets your whole roster, and every agent view is its own conversation with one agent, so a session with three agent views is three independent harness sessions working in the same sandbox, on the same session/<id> branch, over the same /workspace. Views are described on views: terminal, code, files, web, agent.

Every agent gets its own conversation

The agents do not share a chat. Each one is told so in its base prompt: it is one of several independent agents on this workspace, each conversation is separate, and it must never assume another agent reads its thread. Each agent also has its own memory note and its own HOME under /workspace/.isolation/agents/<agentId>/, as described on memory and conversations. What they do share is the working tree and the git branch, which is exactly the point: one agent's edit is visible to the next agent's tool call the moment it lands on disk.

How they coordinate

Two channels exist, and the agents are instructed to use only these:

• The files. /workspace is one tree on one branch. Commits, test results and build output are visible to everyone in the sandbox.
• thread_send. An in-sandbox tool that sends a message to another agent's thread, by agent name or agent view id, and waits for the reply. It is how one agent delegates or asks.

Nothing is broadcast. A message reaches an agent only when someone, a person or another agent, addresses it.

Handing work between them

The simplest pattern is two views and you in the middle: ask Isla to implement, then paste the diff summary to Reviewer, or just ask Reviewer to look at the branch. Both read the same files, so there is nothing to transfer.

The second pattern is delegation. Tell Isla to implement the change and have Reviewer check it when done. Isla does the work, calls thread_send to Reviewer with what to look at, waits for the reply, and reports back to you in her own thread, review included. Reviewer's thread shows the exchange too, so you can continue it there.

The third pattern is a router. Put one agent in a chat and let it take everything; its instructions say who does what, and it hands work out with thread_send. The dispatcher is then an agent you wrote, with a prompt you control, rather than a model Isolation would have to run on every message.

Agents in a connected chat

When a Slack or Teams channel is connected to the session, every agent of the session is in the room, but the app gives Isolation exactly one bot identity. So a thread has an interlocutor: the agent you are talking to. You pick once, then type normally.

Picking costs nothing: it is answered by Isolation itself, in milliseconds, without touching a sandbox. Nothing is inferred from a sentence, so /etc/hosts is wrong is a message, not a command, and an agent's name inside a sentence does not summon it. A message in a room with several agents and no interlocutor yet gets the question once, with buttons; a room with exactly one agent needs no choosing at all. Every reply wears the agent's own name, so a thread with three agents reads as a conversation with three colleagues. The full grammar is on the commands reference.

Buzz is the one app where none of this is needed: every agent there has its own key and its own membership, so an @mention is the address. That model is on Nostr and Buzz.

Agents talking to each other in a chat

Each agent also has the chat tools of the thread it was mentioned in: chat_context, chat_history, chat_members, chat_reply, chat_post. An agent can read what was said before it was brought in, answer inside the thread, or post to the channel when a build finishes. Combined with thread_send, this is enough for one agent to be asked in Slack, delegate a piece to another in the sandbox, and post the combined result under its own name.