A lead agent that delegates

Draw an arrow from one agent to another. The first becomes the lead, the second its helper. The lead can now send the helper a task, wait for it to finish, and read the answer.

A lead can have several helpers, and a helper can lead helpers of its own.

Let the lead build the team

A lead can also create its helpers itself — and choose what each one runs on. Ask it something like “Plan this project for a team of four developers: pick a harness and a model for each and create them.” The lead then:

• sees which agents are installed on this computer — it cannot create one you don’t have;
• sees each agent’s own models (for example opus or sonnet for Claude Code) and, if you connected OpenRouter, that it may use OpenRouter models, with their prices and context size — it never sees your key;
• sees your own servers (LM Studio, Ollama, llama.cpp, vLLM…) by name, the models each one serves and which agents can use it — never their keys or addresses;
• creates each helper with its harness, model, a role and a first task, already connected to it by an arrow.

A helper’s model shows on its card and on the Squad board.

Switch a helper’s model or agent

A lead can also move a helper to another model or provider — its own subscription, OpenRouter or one of your servers — or to another agent CLI altogether (Claude Code → Codex, OpenCode → Claude Code…), in the middle of the work. Ask it something like “the tests helper is stuck — put it on a bigger model” or “move the reviewer to Codex”.

• The conversation is kept. A new model relaunches the same agent with the same session; a new agent CLI is a switch in place, as with the card’s Switch harness…: same card, arrows and name, with the conversation so far handed to the new CLI, and switching back later resumes the original session.
• It waits for the turn to end. A helper in the middle of a turn switches when that turn is over, unless the lead asks for it right away — then the turn is interrupted first. A lead can change its own model too, always after its own turn.
• You see it. A notice in the corner says who changed which card to what, the arrow shows the change and keeps it in its arrow log, and the card shows its new model.
• Only along an arrow. A lead changes only the agents it leads (an arrow from it to them) and itself — never an agent it isn’t connected to, never its own lead. Nothing changes while the workspace budget is paused.

Give helpers the cards they need

A helper only sees the cards connected to its own card — not the lead’s. So when the lead hands out work that needs a card (a note with the brief, a terminal, a browser, a task board), it wires the helper to that card itself: it can create a helper already connected to your note, or draw an arrow from an existing helper to it in the middle of the work. The new arrow appears on the canvas, shows who drew it for a moment, and stays in the arrow log. A helper that is already running gets the new abilities straight away.

What a lead may wire is limited on purpose, because an arrow hands out abilities:

• only cards of the same workspace;
• without canvas mode, one end of the arrow must be the lead itself or a card it created; with canvas mode, any two cards;
• a terminal, browser, MCP server, Telegram or custom card that you set up is passed on only if you connected it to the lead first — the lead cannot reach your own terminal on its own;
• a helper cannot take over its own lead, and cannot cut the arrow its lead reaches it by;
• no wiring while the workspace budget is paused, and at most 30 arrow changes a minute per agent.

Leads never delete cards this way — removing an arrow leaves both cards where they are.

Leads equip themselves too

Besides helpers, a lead can give itself what the work needs — long-term memory, current library docs, a code graph, a skill or an MCP server you installed — with one tool call; installing anything new still waits for your approval. See Agents equip themselves.