When to fan out to many agents, and how to keep the result correct

When should you fan out to many agents, and how do you keep the result correct? At Bigcircle a fit test decides whether to spawn anyone, and each worker gets a contract. A verification gate, with Jev as the decision layer, has to pass before a result is merged. Budgets and caps are shared across that run, so a child cannot open a fresh counter and keep spending.

Key facts

Definition

Bigcircle fans work out only after a fit test, binds each worker to a contract, and merges a return only when a verification gate passes, with Jev as the decision layer and a shared cap on the run.

How Bigcircle does it

Bigcircle writes each worker's objective, return shape, tools, and slice boundary into a contract the application checks again at spawn.
Bigcircle sends each return through a verification gate, with Jev as the decision layer, and merges it only when a separate read matches the expected state.
Bigcircle counts workers, turns, tool calls, and retries on one shared cap, and ends the run when that cap breaks.

Comparison

A lead that pastes worker replies into one answer treats a confident return as finished, while Bigcircle refuses the merge until a separate read matches the expected state.

A fan-out is several workers on one task. Multi-agent orchestration is the name for that split when the workers run side by side and only the lead sees every return. Each worker has its own context and returns only the slice the lead is supposed to combine.

The split helps when the slices are independent and the evidence would bury the lead's context window. It hurts when the next slice needs a decision the previous slice has not finished. The workers cannot see each other's choices, so the merge has to guess at an agreement they never made.

The sections below follow that order: the fit test says whether to spawn anyone, and the contract says what each worker may do. The gate says what may be merged, and the cap says when the run stops. The last section says how to test the merge before another team depends on it.

When does the fit test allow a fan-out?

A task earns a fan-out when the slices can return without reading each other, and when a person could not list those slices before the lead looked. If the steps and the branches are already known, a workflow walks them, and a second agent only adds a second place for the same mistake. When not to build an AI agent is that earlier cut. This guide starts after that cut, once someone has already decided an AI agent is warranted.

Anthropic draws a matching line between two patterns in Building effective agents, published 19 December 2024. Parallelization runs subtasks you can already name, side by side. Orchestrator-workers is the case where the lead has to decide the subtasks from the input. You cannot say in advance how many files will change, or which sources will matter. We use that distinction as the first question in the fit test, and we still refuse the fan-out when the slices share decisions.

A plan and execute loop can fan tool calls out inside one agent. That loop still shares one context, so it is not this split.

Their research system, described in How we built our multi-agent research system on 13 June 2025, is the breadth-first case. A setup with Claude Opus 4 as the lead and Claude Sonnet 4 workers outperformed a single Opus 4 agent by 90.2% on Anthropic's internal research eval. The gain they describe sits on queries with many independent directions, such as listing board members across a set of companies. One agent searches those companies in sequence and runs out of room.

They also say the shape is a poor fit when every agent needs the same context, or when the steps depend on each other. Most coding tasks, in that account, have fewer truly parallel pieces than research does.

Token use belongs in the same test. In their data, a single agent uses about 4 times the tokens of a chat, and a multi-agent system uses about 15 times. A task that is not worth that spend should stay on one agent, even when the slices look independent. We do not treat 90.2% as a number you should expect on your own work, because it is their measurement on their eval for research.

The table is the fit test we apply before a lead is allowed to spawn anyone, and the figure repeats it as a framework for placing a task. The drawing is an illustrative model, and it is not survey data.

Question	Keep one agent	Allow a fan-out
Can the slices return alone?	The next step uses a decision this step has not finished.	Each slice can return without reading the others.
Could you list the slices first?	The steps are known, so a workflow or one agent walks them.	The lead learns the slices from what it just found.
Does one window hold the evidence?	The pages, files, or rows fit the lead's context.	Leaving every page in the lead's window buries the question.
Can a separate read prove the end?	Nobody can name the state a later read would check.	The gate can check each return against that state.

This figure is a framework and an illustrative model of the four questions we ask before a fan-out, and it states no rates and no shares of tasks. On a narrow screen the drawing scrolls sideways inside the column, while the table above carries the same questions.

What does each worker contract have to name?

Each worker receives a contract the application wrote, rather than a sentence the lead improvised in the prompt. Anthropic's research write-up names the fields that kept their workers from duplicating a search. The fields are an objective, an output format, the tools and sources to use, and the boundary of the slice. A short instruction such as "research the semiconductor shortage" sent one worker into the 2021 automotive chip crisis and two others into the same 2025 supply chain. We keep those four fields, and we store them in the application, where the worker cannot edit them.

The objective is the question for this slice, still inside the task the principal asked for. A worker that adds a new verb, a new recipient, or a new system is no longer on the slice, and the application refuses that spawn. Stopping prompt injection from spreading between agents is the hop this contract sits on. The parent's message stays data. The contract is the task.

The return shape is structured output, the fields the gate will read, with no extra prose the merge would have to interpret. Tools are an allowlist for this worker, narrower than the lead's, and the credential dies with the slice. Tool calling is how the worker reaches that allowlist. The boundary says what the worker must not cover, so two workers do not both return the same half and leave the other half empty.

A contract the lead can rewrite on the next turn is only a suggestion. We check the four fields again when the worker is spawned, and a worker that asks for a tool outside the allowlist gets a typed refusal it can repeat. The lead may propose a narrower slice, and it cannot widen one.

How does the verification gate decide the merge?

Workers finish their own call and report the slice as done, which is the failure why AI agents report unfinished work as done walks through for a single action. A successful tool result or a confident summary is the worker's view of its own slice. The merge needs a separate read of the expected state, and the worker's claim is not that read.

On the systems we ship, Jev is the decision layer at that gate. Introducing Jev into agentic workflows keeps the question text fixed and puts model output in named fields, and the same cut applies to a fan-out. Code places each worker's return, the contract, and the separate read into named fields.

Jev answers a fixed question about whether the return matches the contract and whether the slice is complete against the read. Application code still merges, refuses, or asks for the slice again. Jev does not write the merged result, and it does not run the worker.

A missing field, a slice that covers another worker's boundary, or a read that disagrees with the return is a refusal. We do not fold a refused slice into the answer and hope the rest covers the gap. The lead may spawn a replacement inside the same contract, until the cap says the run is over. A merge that proceeds because most workers sounded finished will ship the gap the refused worker was holding.

The figure shows the path a result takes, as a framework and an illustrative model, and it is not a trace from a run.

This figure is a framework and an illustrative model of four stages: the lead proposes slices, and each worker is bound to a contract. The verification gate, with Jev as the decision layer, judges named fields against a separate read, and code merges only what passed. A shared cap sits on the whole run, and the drawing states no rates and no token totals.

How do budgets and caps bound the same run?

Fan-out spends the parent's budget once for every worker, and a child that starts its own counter will spend it again. What a production AI agent costs to build and run puts turns, tool calls, and fan-out under one cap in the request path. A breach ends the run before the next paid call. We use that same cap here, and the workers share it. A fresh counter on a child is how the fan-out pays for the same mistake several times over.

The research agents Anthropic describes spawned 50 subagents for simple queries in an early version. Later prompts tried to scale the effort, with one agent for a simple fact and more workers only when the question actually splits. A prompt rule is not a stop. The model that is over-spawning is the model reading the rule.

The cap has to live in the application, counted across the lead and every worker, including retries and a worker that stalled and was started again. Those caps are the guardrails on the run, and a line in the prompt is not one of them.

Claude Code documents its own ceilings in the workflows guide, and we read them as that product's choice. A run may spawn up to 1,000 agents in total. The product warns when a workflow schedules more than 25 agents, or when its projected tokens pass 1.5 million. The page says that warning does not pause or limit the run. On a system we ship, past the cap, the next spawn does not leave.

Dual-layer production agent ops is how you see which worker spent the cap. The trace has to carry the worker id, the contract it was given, the gate's answer, and whether the result was merged. Observability that only records the lead will show a finished run while a refused worker is missing from the answer. A success status on the lead, with one worker refused and the others unread, is the blank reply that the ops guide already describes, now spread across a fan-out.

How do you test the merge before another team depends on it?

Two runs of the same task can take different valid paths. A test that demands one sequence of workers will fail a correct merge, and it will pass a wrong one that happened to follow the script. The same write-up makes that point for their own system. Judge the outcome, and check that the process was reasonable, because you often cannot prescribe the steps in advance.

We score the merged result against the expected state. We also keep a check that the lead did not fan out on a task the fit test should have held to one agent.

How to build LLM evals is where the rubric for that set is built, and evals here means those cases rather than a score on a public benchmark. The cases we add for a fan-out are narrow, and a task whose slices share decisions must stay on one agent. A worker that returns a confident slice with a missing field must be refused at the gate. A cap breach must end the run before another worker starts. The first two need a model, because a model chooses the spawn and the return. The cap is a contract test with no model in the loop, the same split as testing MCP servers before agents depend on them. A demo that stayed inside the budget cannot hide a counter that resets for each child.

We run the set when the contract fields change, and again on a schedule, because a model swap can make the lead spawn workers the last green run never tried. A single happy path, with tidy slices and a polite merge, does not exercise the refusal.

Common questions

When should you fan out to many agents?#

Fan out when the fit test passes. The slices can return without reading each other, and the lead has to discover those slices rather than follow a list you already wrote. One window cannot hold the evidence, and a separate read can prove the end state. If the steps are known, use a workflow or one agent. If the next slice needs a decision the previous slice has not finished, keep a single context.

What belongs in a worker contract?#

Name the objective, the return shape, the tools and sources this worker may use, and the boundary of the slice. Store those fields in the application and check them again at spawn. A sentence the lead writes in the prompt can be rewritten by the next page the lead reads, and that sentence is not a contract.

How do you keep a merged result correct?#

Do not merge on the worker's claim that its slice is done. Put the return, the contract, and a separate read of the expected state into named fields. Let Jev answer a fixed question about whether they match, and let application code merge, refuse, or send the slice back. A missing field stays missing, and it is not folded into the other slices.

Why do budgets and caps have to be shared?#

Each worker spends the same run, so a child that opens a fresh counter can pass its own limit while the parent is already over the budget you set. Count turns, tool calls, retries, and workers on one cap, and end the run when that cap breaks, before the next paid call.

How is this different from one agent with a plan?#

A plan inside one agent still shares one context, so later steps can see earlier decisions. A fan-out gives each worker a clean window and takes that shared view away. Use the fan-out for independent slices, and use one agent, or a workflow, when the decisions have to travel with the work.

How do you test a fan-out before you trust it?#

Score the merged result against the expected state, not against one scripted list of workers, because two correct runs can split the work differently. Add a case where the lead should have stayed single, a case where a confident return is missing a field, and a contract test where a child counter cannot reset the shared cap.