Agents working together

Hand work between agents, get the answer back, and see who sent what.

Two agents on two Workspaces are already useful without talking to each other. This page is about the next step: one agent hands a piece of work to another and gets the result back, without you carrying messages. You ask in plain words; the agents do the plumbing.

Mention one in a sentence

Type @ and the list offers agents as well as files: the other agents on this folder first, then agents on other folders with their folder in grey.

A mention is a reference, not an address. The message still goes to the agent you are talking to. You are naming somebody so it can be talked about:

@Hopper has the auth branch. Ask it to add the missing tests, and tell me what it concludes.

The agent you are talking to decides whether to do that. If it does, the message arrives in the other conversation with a prefix Kumo writes itself:

[from Curie · feat/auth · agent_id=…] Add the tests for the token refresh path

That prefix cannot be forged: the sender’s identity comes from the environment, not from the command line. And it is deliberately visible. What agents say to each other is shown to you, in the conversation, marked FROM Curie · feat/auth where YOU would be.

@ also takes a Workspace or a project, to say where: “open a Codex on @workspace:web/main and fix it there”, “make a new Workspace in @project:web called billing”. Again, the agent you are talking to does it.

Hand over a new agent

To have an agent start a helper with exactly the settings you want, choose New agent… at the end of the AGENTS group in the @ list, or type @new:Hopper. A card asks for the name, the agent, the model, the effort and the mode, with your default agent and its last settings already picked. Your draft gets one chip:

Have @new:Hopper write the tests and @new:Curie review them. Tell me when both are done.

On send, the agent you are talking to starts Hopper and Curie with those settings. Click inside a chip to change its settings before you send.

Getting the answer back

The right way to delegate is: send with --notify, then end the turn. With --notify, Kumo records that the sender is waiting. When the other agent stops (done, failed, or asking a question), Kumo puts its last reply into the sender’s own queue:

[from Hopper · feat/auth · agent_id=…] stopped: done … Last reply:
Added six tests around refresh expiry; two were already failing on main.

In the conversation that shows as a bubble marked FROM Hopper · feat/auth · done, with just the reply. It is a real prompt through the normal queue, so the sender wakes up if it was asleep and has to read it. An agent that tries to sit and wait instead is at the mercy of its own harness: some can suspend and resume, some just block, some say they are listening and are not.

kumo wait is the other half, and it is a poll, not a push: it checks the same status you see in the AGENTS list. Useful for a glance at progress, not the way to collect a result.

Related agents

When an agent sends work out, its composer grows a capsule, 2 out, with the most urgent one’s status. Click it, or Related agents in the right rail, for the list:

• SPAWNED: agents this one started.
• WAITING ON: agents it sent work to with --notify and is waiting for.

Click one to read its conversation right there in the panel, read-only, without leaving the agent you were on. Permission and question cards still work in the preview, so a helper stuck on a question can be let through. Open tab opens it beside the current pane to reply.

In the conversation itself, every time an agent works the workbench you get a ledger line rather than a folded tool call: Spawned Hopper, Sent to Curie · delivered, Filed #97, with the message it handed over under it. Click an agent’s name on a ledger line to open it in Related agents.

The kumo command

Agents reach the workbench through a small command-line tool inside the app, plus a skill that tells them how to use it. Both are installed with the app; there is nothing on npm to add. Outside Kumo the tool is not there and the skill switches itself off. You do not type these; they are what an agent does when you ask for something above.

kumo spawn without --backend uses your default agent. That makes “plan it yourself, then hand the build to Codex” one sentence.

Where things an agent makes end up

Exactly where they would if you had made them, minus the interruption:

• A new agent’s tab is added to the focused pane and marked unread, without taking focus.
• If it belongs to a different folder, it goes into that board’s layout, ready for when you switch.
• A new Workspace appears on the tree and is not selected.
• No notification, since the tab is right there. Later, when it needs you or finishes, it notifies as usual.

Closing a tab still closes the agent. If you close Hopper’s tab, the next kumo send to it fails and says so, which is right: a clear failure beats messages going to a ghost.

What agents are not given

No destructive actions. An agent cannot delete a Workspace, close another agent, interrupt someone else’s turn, change another agent’s model or mode, or commit and push on its behalf. There is also no limit on how many agents one can spawn; that is a deliberate choice to see how it goes, not an oversight.

Visibility is not fenced either: an agent can see agents in every project. These processes can already read your whole disk, so a fence there would be decoration.