A team asks an agent to review a security-sensitive change. The workflow creates a researcher, an architect, a critic, a tester, and a release manager. All five workers use the same model, read the same incomplete design note, and trust the same weak judge. They agree quickly and recommend the same unsafe change.
The workflow has more roles. It does not necessarily have more independent evidence. That is the central problem in multi-agent coordination: adding roles is cheap, while independent, checkable work is not.
Multi-agent coordination is the design of how several agent runs share work, state, authority, and decisions. An agent is software that uses a model and tools to pursue a task. A role is a contract for one responsibility inside the workflow. A persona is the language that describes how a role should behave. A runtime is the software that starts workers, dispatches tools, tracks budgets, and ends the run. A trace is the record of each branch, input, action, artifact, check, and decision. An evaluation is a repeatable test of the final task outcome. A baseline is the single-agent or simpler system used for comparison. A candidate is the proposed multi-agent workflow being tested. A judge is a scorer for qualities that deterministic checks cannot fully capture. A sandbox is an isolated execution boundary that limits files, networks, credentials, or processes.
Personas are instructions. Coordination is executable structure.
Five names do not make five agents
Consider this prompt:
You are the supervisor.
Ask the researcher, architect, critic, tester, and release manager
to collaborate and return the safest patch.That prompt may produce a convincing transcript. It does not say whether five workers started, whether their contexts were independent, whether one worker could override another, or whether a failed test could block release.
A role becomes operational when the system can answer:
| Role question | What must be explicit |
|---|---|
| What does the role receive? | Input schema and allowed context |
| What does it return? | Artifact, evidence, and failure shape |
| What can it do? | Tools, permissions, and budget |
| Who sees its result? | Handoff and context policy |
| What can stop it? | Deadline, cancellation, or escalation |
| Who decides whether it passed? | Independent check or human owner |
The same model can perform several roles. The contracts still need to remain separate. A reviewer that writes the patch can rationalize its own change. A judge that sees the hidden answer key can leak the evaluation. A coordinator that cannot see child traces is guessing about the work it merges.
Coordination is controlled disagreement
More workers help only when their errors are not perfectly correlated. Useful diversity can come from different evidence, tools, models, skills, task decompositions, or branch states. Role names alone do not create diversity.
If each worker sees the same model, prompt, examples, context, tool set, and evaluator, then the ensemble may be five samples from one blind spot.
If qᵢ is worker i’s success probability, the simple independent-success calculation is:
probability(at least one success) = 1 - product(1 - qᵢ)The formula assumes independence that real language-model workers rarely provide. The practical quantity is the measured gain over a strong single-agent or best-of-N baseline at the same budget.
For an artifact task, also ask whether the final merge preserved disagreement. If the coordinator smooths conflicting findings into a confident paragraph, the workflow may lose its most valuable signal.
Role contracts need an artifact
The following contract is more useful than a cast list:
worker:
input: task, scoped context, allowed tools, budget
output: artifact, assumptions, evidence, unresolved risks
stop: artifact complete or budget exhausted
reviewer:
input: artifact, task contract, independent evidence
output: defects, severity, required changes, pass or fail
authority: can block release but cannot silently edit the artifact
coordinator:
input: child artifacts, traces, costs, decisions
output: merged artifact, lineage, unresolved disagreement
authority: allocate work and request another roundThe artifact makes roles testable. The reviewer’s pass or fail can be checked. The coordinator’s merge can be audited. The worker’s assumptions can be compared with the evidence it received.
Common coordination shapes
Best-of-N runs several attempts and returns the highest-scoring valid result. It works when outputs are cheap and easy to check. It fails when the score is subjective or all attempts share one missing fact.
Self-consistency samples multiple reasoning paths and chooses a stable answer. It is useful for tasks with a clear correct answer. It is weaker for open-ended artifacts where agreement can reflect shared convention rather than correctness.
Parallel research assigns independent questions to workers and merges cited evidence. It works when the subtasks do not depend on one another. It fails when workers need a shared evolving state or when the merge loses source lineage.
Debate gives workers a proposal, critique, and response cycle. It can expose assumptions. It can also reward rhetoric, anchoring, and confidence unless a check examines the underlying artifact.
Supervisor and workers give one coordinator authority to assign tasks, collect results, and decide whether another round is needed. The supervisor needs child traces, budget control, and a merge rule. Otherwise it is a narrator.
Handoff transfers control to a specialist that owns the next part of the task. It is useful when the next role should speak directly or use a narrower context. It is dangerous when history, permissions, and unresolved risks cross the boundary implicitly.
Shared workspace lets workers improve one artifact. It fits code and long documents. It requires locking, provenance, conflict handling, and an owner for the final merge.
The pattern should follow the information flow, not a fashionable architecture diagram. Anthropic’s public guidance on building effective agents recommends simple composable workflows before adding autonomous complexity. OpenAI’s Agents SDK orchestration guide distinguishes manager-style agents-as-tools from handoffs and from code-driven orchestration. Both are useful because they describe a decision boundary, not a requirement to use more agents.
A manager and a handoff are different
OpenAI’s public SDK uses two clear patterns. In manager-style orchestration, one agent keeps control and calls specialists as tools. In a handoff, a triage agent transfers control to a specialist that continues the conversation.
The distinction changes the final owner:
| Pattern | Final conversation owner | Useful when |
|---|---|---|
| Agents as tools | Central manager | One agent must combine specialist results and enforce shared policy |
| Handoff | Chosen specialist | The specialist should own the next interaction and keep its context focused |
| Code-driven chain | Application code | Order, budgets, and branching need predictable behavior |
Do not treat these as semantic synonyms. A specialist called as a tool can return an artifact without taking over the user-facing thread. A handoff can transfer conversation history and authority. The runtime should record which occurred.
Budget is the coordination contract
In this sample, a single worker uses 10,000 output tokens and two minutes. The sample five-worker workflow that uses 50,000 tokens and ten minutes may be the right service tier. It has not yet shown a coordination gain.
Record:
- Worker count and maximum concurrency.
- Model calls, tool calls, and retries.
- Input and output tokens.
- Wall time and queue time.
- Sandbox or browser time.
- Failed, timed-out, and cancelled branches.
- Human review time.
- Final quality and protected failure classes.
Then compare:
| Claim | Baseline |
|---|---|
| Better quality | Best single-agent or best-of-N at equal spend |
| Lower cost | Current quality at lower spend |
| Lower latency | Current quality at equal reliability |
| Better safety | Same task success with fewer policy and permission failures |
The test-time compute article explains why extra branches are an inference budget before they are an intelligence claim. The evaluation gates article gives the protected comparison rule.
A public Tangle coordination shape
The public Tangle agent-runtime repository documents a supervise call for one agent to steer a team toward a goal. The public README shows the shape:
import { supervise } from '@tangle-network/agent-runtime/kernel'
const result = await supervise(
{
name: 'supervisor',
harness: 'cli-base',
prompt: {
systemPrompt: 'Delegate to workers; do not solve the task yourself.',
},
},
'Implement the feature and make the tests pass.',
{ budget, router, backend },
)This is an illustrative public API example, but the application still supplies the budget, model backend, and worker environment. The call does not prove that the resulting team is better. It gives the runtime a place to record assignments, stopping, and cost so an evaluation can test the claim.
Tangle’s network terms describe the outer service boundary. A Blueprint is a template for a service’s runnable artifact and jobs. A Service is a live instance created from that Blueprint. An operator runs a live Service made from that Blueprint. A Router in the Blueprint Runner sends a job identifier to its handler. The agent runtime inside that handler can use a different internal graph of workers and checks.
If the job is called over x402, x402 is an optional payment-gated HTTP ingress path. Payment authorization can decide whether work enters the queue. It does not decide whether the multi-agent merge is correct.
If a worker runs in a trusted execution environment, an attestation is signed evidence about the loaded code and hardware state. It can support an execution-boundary claim. It does not prove that the worker’s reasoning or final artifact is correct.
Context boundaries are part of coordination
Sharing context can help or hurt. A researcher may need the original question and source list. A critic may need the draft but not the researcher’s private rationale. A judge may need the artifact and task contract but not the hidden reference answer or optimizer notes.
Define context transfer explicitly:
| Boundary | Decision |
|---|---|
| Worker to coordinator | Return artifact, sources, assumptions, and unresolved issues |
| Worker to worker | Share only approved artifacts or selected evidence |
| Coordinator to reviewer | Include lineage and task contract, not untrusted instructions as policy |
| Candidate to judge | Include output and allowed trace fields, not hidden rubric state |
Tool output is untrusted input. A web page, issue, document, or child response can contain instructions that try to redirect the agent. The runtime should preserve the distinction between trusted policy, untrusted observations, proposed actions, and approved side effects.
The governance article covers authority and prompt-injection boundaries in more depth.
The trace must explain the merge
A final answer is not enough to evaluate coordination. The trace should show:
- Which roles were created.
- What each role received.
- Which tools and permissions each role used.
- Which state was shared or isolated.
- What each role produced.
- Which checks ran.
- Which branch or evidence won.
- Which branches were rejected or cancelled.
- What the merge removed or changed.
- What the workflow cost.
If a coordinator returns a smooth summary but cannot show the rejected evidence, the system has hidden disagreement. Artifact lineage is the chain linking each merged result to the branch and evidence that produced it. If the judge sees only the final text, it may reward the merge’s confidence rather than the child artifacts’ correctness. If a child failed because of missing credentials, that should not become a model-quality failure.
The trace systems article describes the record needed for this kind of analysis.
Ablations reveal whether coordination did work
An ablation removes one mechanism while holding the rest fixed. For a multi-agent workflow, run at least:
| Ablation | Question |
|---|---|
| Remove debate | Did debate resolve errors or add words? |
| Remove shared context | Was diversity coming from independent evidence? |
| Use one model and prompt | Did heterogeneity matter? |
| Replace the learned winner rule | Did the rule choose correctness or style? |
| Disable parallelism | Was the gain quality or scheduling? |
| Reduce the worker budget | Does the pattern still work at the target tier? |
The most revealing ablation is often the simple baseline. If the multi-agent system performs the same with one worker and the same budget, the added roles may be documentation rather than mechanism.
Why coordination makes results worse
Correlated blind spots make multiple agents agree on the same missing fact.
Consensus collapse makes the first plausible answer dominate later evidence.
Context contamination lets one candidate copy another and disguises dependent attempts as independent work.
Merge loss drops provenance, uncertainty, or unresolved contradictions.
Authority confusion makes a blocking review advisory.
Unpriced compute makes a team appear better only because it spends more.
Trace gaps hide which branch produced the final result.
Winner-rule overfit makes the winner rule prefer fluent, long, or rubric-shaped answers.
The remedy is not always fewer workers. It is a role contract, a context boundary, a check, a budget, and evidence that the role changed the outcome.
Choose coordination when the task earns it
Use multiple agents when the work needs independent evidence, heterogeneous tools, real parallelism, adversarial review, branch search, specialist handoff, or an artifact merge with provenance.
Use one agent when the task is short, sequential, stateful, or difficult to score across branches. Use a fixed workflow when the steps are known and predictability matters more than model-directed routing. Use a team when the coordination contract is explicit and its gain survives a compute-matched comparison.
The decision test is concrete:
why did this role exist?
what information did it receive?
what did it produce?
which check assessed it?
how did its result change the final artifact?
what did it cost?If the system cannot answer those questions, it has a richer cast list, not yet a reliable multi-agent system.
What is multi-agent coordination?
It is the executable design of how multiple agent runs divide work, share context, use tools, respect authority limits, produce artifacts, and combine decisions.
Are different personas enough?
No. Personas change instructions. Coordination requires runtime contracts, state boundaries, permissions, budgets, checks, and traces.
Why can more agents make a result worse?
They can duplicate one blind spot, contaminate one another’s context, hide failed branches, spend more compute, and let a weak merge rule reward confidence over correctness.
What should be optimized first?
First make the runtime shape executable and observable. Then compare it with a strong single-agent or best-of-N baseline at equal budget. Only after that tune role wording or skills.
Does a paid job prove the team worked?
No. An x402 payment can authorize and enqueue a job. The trace and task evaluation still need to show that the team executed and produced an acceptable result.