One agent leads. The rest get to work.

Why this exists

Running three agents is easy. Being the person between them is not. You decide who does what, you carry what one of them found over to another, and you check each one in turn to see who has finished and who has been waiting on a yes for a quarter of an hour. The agents are fast. The coordination is you, and you are the slow part.

The vendors have noticed. Claude Code can delegate to subagents and, experimentally, run a team of its own sessions. Those are good, and they have two edges: they only work with that one vendor's agent, and everything they coordinated lives in the session that started it.

Squad is the same idea without those edges. The lead can be any agent, the helpers can be any others, and the plan is written somewhere that is still there after every one of those sessions has ended.

How it works

Squad is a setting on a Thread, which is the place one job's folders, notes, keys and board live. Switching it on affects that job and nothing else on your machine.

1. Say what the job is. Write the goal on the Thread's board. That sentence is what the lead plans against and what every helper can read.
2. Start one agent and tell it to lead. It reads the code, splits the goal into tasks on the board, and decides which of them can run side by side.
3. The lead calls in helpers. Each helper is its own session with nothing in its context but the task, the notes that go with it and the files it opens. It claims one task, and the claim shows on the board so nobody else picks it up.
4. Helpers report to the board, not to you. Progress, blockers and what they decided are written down as they go. A helper that needs an answer flags you, with a notification, instead of sitting silent.
5. You accept the work. A helper can say a task is finished. That puts it in front of you. It is done when you say so, and not before.

Any agent you already run

A helper is three things: a name, the command that starts it, and one line saying what it is good for. That is all, which is why nearly anything qualifies. Forkbench comes with Claude Code on two models, Codex, Cursor, Antigravity and Gemini ready to call, and you add your own in a minute.

The one line matters more than it looks. It is shown to the other agents, so the lead knows that one helper is the strong, careful one and another is the fast, cheap one, and picks accordingly. A command can pin a model, so the familiar rule of a strong model planning and a cheaper one doing the bounded work is just two helpers with different commands.

Mixing vendors is ordinary. A Claude lead can hand the test suite to Codex, because nothing on a task records which agent wrote it or which one may finish it.

A lead that wants an agent you have not added can suggest one. The suggestion sits there until you approve it. An agent cannot add to its own squad.

What you see while it runs

A helper that speaks the Agent Client Protocol runs in the background. You get a live feed of what it is doing, a card to answer when it wants permission for something, and its messages, without another window to manage. Any other agent runs in a terminal of its own.

Either way the helpers sit as a row of chips on the lead's tab, so one glance tells you how many are working. Each agent's tab carries a live pulse that quickens as it works harder, and the task it claimed is shown beside it. When one is blocked it turns red and the Thread counts how many are waiting for you.

And the board is the record. It is written to disk as it changes, so a compacted context, a closed pane, quitting the app or restarting the machine leaves the plan, the notes and the open questions exactly where they were.

You stay the one who decides

Squad is off for a Thread until you allow at least one helper in it. Off means off: agents there coordinate through the board as they always have, and every squad action is refused. On, they may address each other, hand a named peer a task, and ask for hands, which starts one of the helpers you allowed for that job and no others.

The authority never moves. No agent can accept its own work. You can make an agent a reviewer of other agents' work, and it still cannot review its own, and no tool lets an agent promote itself. If two agents disagree, that becomes a discussion on the task, and the task cannot close while the discussion is open.

Whether a Thread's agents may reach your other machines is a separate switch, off until you turn it on.

Squad and an agent's own subagents

They are not rivals, and plenty of people use both: a helper in a squad is free to use its own subagents inside its task. The difference is what each one is the right size for.

Where it stops

• It costs tokens. Several agents use several times what one does. Anthropic measured multi-agent systems at about fifteen times the tokens of a chat. A squad earns that on work that splits into independent pieces, and loses it on one tightly coupled change, where one agent is the right call.
• Helpers share the checkout unless you separate them. A squad decides who does which task. It does not give each helper its own copy of the code. Have the lead split the work so helpers do not edit the same files, or give them a git worktree each, which is one click from the git panel.
• Acceptance is a review, not a proof. A person signing off stops an agent grading its own homework. It does not make the work correct. Read the diff.
• It does not choose models or budgets for you. A helper runs whatever its command says, on your own subscription with its own limits. Forkbench does not route models, meter tokens or cap spend.