Orchestrate: Claude Code orchestration skill for subagents

Orchestrate is a Claude Code orchestration skill, written at AR Labs, for running several AI agents (language models run in a loop with tools, so they can act) as subagents on one piece of work. It is for anyone directing a fleet of agents from one coding session: load it when a task spans independent areas and you are about to fan it out. It turns the lead session into an orchestrator whose job is to plan, delegate and synthesise rather than do the work itself, and it covers the decisions that go wrong most often: launching a fleet when one agent would do, briefing workers too vaguely, running simple extraction on the most expensive model, losing results when a run is interrupted, and trusting a worker's summary without checking it.

We wrote the skill. Its fleet sizes and its emphasis on detailed briefs come from Anthropic's engineering post How we built our multi-agent research system; the routing, pricing and recovery rules come from our own logs of how our agents were used. The wider practice is described in multi-agent orchestration.

How it works

Stage 0, the gate. A gate is a point work cannot pass until a condition is met; here the condition is that the work needs a fleet. If one agent, or the lead session itself, can do the job in fewer than about ten tool calls, there is no fleet. Subtasks fan out only when they are independent; a subtask that needs a human decision part-way stays in the main thread; and anything a script can do (a search sweep, a link check, an extraction) is scripted rather than delegated. The fleet size and each agent's slice are stated before anything is launched, using Anthropic's calibration: one agent for a fact-find, two to four for a comparison, up to ten in waves of three to five for complex research or an audit.

Stage 1, route and price. Each kind of work goes to a matching agent type and model tier: a cheap fast model for codebase surveys and extraction, a stronger model for research, implementation and adversarial review. Every launch names its model explicitly, because an unstated model inherits the session's, which is usually the most expensive. The rule comes from our logs: over six weeks, 302 of 313 agent launches named no model and ran at the session's rate. A worker may drop one tier when three things hold: the lead wrote a tight brief, the result will be cross-checked, and a weak result would be visible and re-runnable. It never drops for unattended runs, for single-worker research where choosing the sources is the output, or for implementation whose small decisions end up in merged code.

Stage 2, the brief. Every worker gets four fields, written for a reader who has not seen the conversation:

• Objective: a deliverable, not a direction to explore.
• Context: everything that exists only in this conversation: paths, errors, decisions already made, constraints.
• Boundary: what is not this agent's job, and which neighbouring agent owns it.
• Return: an explicit output schema, with raw evidence (a URL, a verbatim quote, a file and line) beside every summary, and "unable to determine" plus a reason in place of any missing field.

Stage 3, checkpoint to files. For fleets of three or more, each worker writes its result to a file as well as returning it. If the run is interrupted, recovery means reading the files and launching agents only for the missing slices. The rule exists because one interrupted four-agent fleet, whose results lived only in the conversation, needed eight replacement launches to recover.

Stage 4, synthesise, then verify. Synthesis is a separate pass, not concatenation: conflicts between workers are resolved or surfaced, claims are attributed to the evidence behind them, and coverage gaps are named. Verification scales with the stakes: claims checked against the raw evidence fields for ordinary work, a fresh agent told to refute each finding (and to default to refuted when unsure) for high-stakes findings, and a judge with written criteria, never a bare "evaluate the quality", for questions of quality.

The judgement it encodes

Never let the agent that produced a claim be its only verifier. The check comes from a fresh context, framed to refute.

A second bounded wave beats one oversized first wave. Launch against named gaps, not "as many as needed".

Background workers fail silently on permission prompts. A background agent whose shell command needs approval has no one to approve it, so it stalls until a watchdog stops it, and from outside this looks like "agent stalled", not "permission denied". Compound commands joined with && are the usual trigger. Before a shell-heavy background fleet, the lead allows the exact commands the workers need, and treats a stalled worker's first suspected cause as a blocked command rather than a model failure.

Script what can be scripted. A search sweep, a link check or an extraction is a script, not an agent.

Writing workers share a stable workspace. A worker that edits code works on its own branch in the project's long-lived worktree (a separate checkout of the repository, so each task is built in isolation), not in a throwaway copy that reinstalls every dependency each time.

Read-only work gets read-only agents. That avoids permission deadlocks and accidental edits.

What exists today

The skill is in use in our own sessions for audits, surveys and research fleets; it is not released. Our coding pipeline has its own orchestration, but the routing and briefing rules here apply to every agent that pipeline launches. For plain web research, our research skill has fixed fleet sizes of its own.

Example

Illustrative example. A brief for one of three agents auditing a website's documentation:

[OBJECTIVE] List every page under docs/ whose code samples no longer
match the current API, with the mismatch for each.
[CONTEXT] The API changed in the last release: `connect()` now takes
an options object. The changelog is in CHANGELOG.md. Do not edit files.
[BOUNDARY] You cover docs/guides/. Agent 2 covers docs/reference/;
Agent 3 covers README files. Note any cross-links into their areas.
[RETURN] JSON array: {page, line, sample_excerpt, expected_call,
actual_call}. Write it to audit/guides.json and return it. If a page
cannot be checked, return {page, status: "UNABLE_TO_DETERMINE",
reason}.