Multi-Agent Coding You Can Watch: Sessions That Fork, Lead and Approve Each Other's Plans

/fork copies a conversation into a new session, in the desktop app, the CLI, VS Code and any editor that supports forking over the Agent Client Protocol. The copy knows everything the original knew up to that point, and the original is left as it was. Fork twice and you have three sessions that share the same understanding of the task.

A session can call list_sessions to see the others: where each runs (the app, the CLI, an editor), whether it is idle or working, its mode and model, and any plan waiting for approval. With result_of, it reads another session's latest finished turn: how it ended, its reply and the files it changed, or "still working".

This is the part that makes the pattern work. A lead does not need the workers to report back; it can look.

With send_message, one session can give another a task, set its mode and model (from the providers you have set up), and review its plan: approve it, and the other session starts building exactly as if you had clicked Build; reject it with a reason, and it plans again; or replace it.

The session on the receiving end shows a line saying who changed what, for example "Plan approved by Rix. Building it." or "Mode set to Review by Rix. From the next turn." A change is refused while that session is in the middle of a turn, so nothing is switched under it.

Because you can step in anywhere. Each worker is an ordinary session: open it in the app or VS Code and read along, type into it, stop it, or take over. A session open in two places stays in step, so the CLI can run a turn while the app shows it live. Nothing about the lead's decisions is hidden in a log you have to dig out afterwards; it is in the chats.

It also means each worker can run on a different model. A cheap, fast model can do the mechanical part while a stronger one reviews.

Ask a session to plan a feature, then /fork it twice. In the first fork, ask it to lead: it lists the others, sends one the API half and the other the tests, sets the test session to a cheaper model, and approves each plan when it reads right. When both finish, it reads their results with result_of and reviews the changed files. You watch any of the three, and stop any of them, at any point.