How it works
A coordination budget makes the cost of decomposition explicit before a harness creates more agents. The budget is not just a token or latency ceiling. It is an inventory of the obligations introduced whenever one execution path becomes several independently acting paths.
For each proposed agent boundary, estimate or constrain:
- what context must cross the boundary, in what form, and with what provenance
- who owns authoritative workflow state after delegation
- which permissions and credentials the receiving agent needs
- how completion, rejection, timeout, and unknown outcomes are represented
- what evidence the parent needs to accept the result
- how retries, duplicate work, and partial effects are contained
- whether recovery requires replay, compensation, or operator intervention
The harness then compares those obligations with the expected benefit of decomposition. A separate agent may earn its place by isolating failure, applying a distinct permission scope, running independent verification, or handling work that can proceed concurrently. If the boundary only changes who produces the next text response, it may add coordination without adding control.
The budget should be enforced through concrete limits and contracts. Examples include a maximum number of handoffs, typed result artifacts, deadlines, bounded retries, explicit state ownership, and acceptance checks at join points. Exceeding the budget should produce a visible failure or redesign decision, not silent simplification.
Why it matters in an agent harness
Multi-agent designs move complexity out of one agent loop and into the relationships between loops. That complexity remains part of the system. It appears as context assembly, message delivery, permission delegation, state reconciliation, result evaluation, and recovery from incomplete work.
A coordination budget forces the designer to account for those surfaces. Without one, a harness can look modular while becoming harder to operate. An agent may receive stale context, two workers may act on the same resource, or an orchestrator may accept a plausible result without the evidence needed to verify it. When a worker times out after invoking a tool, the parent may not know whether retrying is safe. These are coordination failures, not model-quality failures.
Budgeting also improves reversibility. A handoff with explicit inputs, authority, side-effect limits, and a durable result can be inspected or retried. A conversational delegation with implicit state cannot be recovered as cleanly because the actual contract is scattered across transcripts and assumptions.
The same reasoning applies to observability. Every additional worker creates another execution trajectory that must be attributed to the initiating run. Logs alone are insufficient if they cannot show which state version the worker received, which permissions it exercised, and why its output was accepted. The coordination budget therefore includes the cost of making each branch legible.
The objective is not to minimize the number of agents. It is to spend coordination where it buys a useful system property. Parallel research may justify several bounded workers because failures are isolated and outputs can be independently checked. A sequence of agents that repeatedly rewrites the same artifact may not justify its handoffs, especially when each transition loses context or weakens ownership.
Coordination Budget vs Coordination Cost
The distinction changes when the concept is applied. Coordination cost describes what the architecture consumes. A coordination budget is the limit and decision rule used to govern that consumption.
| Axis | Coordination budget | Coordination cost |
|---|---|---|
| Role | Prospective design control | Observed or estimated burden |
| Main question | How much coordination will we permit, and for what benefit? | What does this decomposition require to operate? |
| Typical expression | Limits, contracts, and acceptance thresholds | Latency, context transfer, verification work, and recovery effort |
| Response to excess | Reject, simplify, or redesign the decomposition | Measure and report the burden |
A cost can exist without a budget. In that case, the team may notice growing latency or operational friction but have no declared point at which the architecture should change. A useful budget connects the measured cost to an action.
The Rifty take
We treat every agent boundary as an operational liability that must purchase a specific benefit, such as failure isolation, narrower authority, independent evaluation, or meaningful concurrency. We accept some coordination overhead when it makes execution more controllable or recoverable. We do not accept decomposition whose only benefit is a more elaborate agent diagram.
Implementation checks
- Name the authoritative owner of workflow state before and after every handoff.
- Define the worker's input, permitted actions, completion artifact, and stop conditions.
- Record which context version and permission scope each worker received.
- Put acceptance checks at join points instead of trusting a worker's success message.
- Make timeouts and unknown outcomes distinct from confirmed failure.
- Decide whether retries are idempotent or require a compensating action.
- Cap fan-out, handoff depth, retries, and concurrent side effects.
- Test partial completion, duplicate delivery, stale context, and parent-process failure.
- Remove an agent boundary when its control benefit does not repay its coordination burden.
Frequently asked questions
How do you set a coordination budget before measurements exist?
Start with structural limits rather than invented numeric precision. Cap handoff depth, fan-out, retries, permission expansion, and unresolved outcomes. Require an explicit benefit for every boundary. After representative runs, measure latency, context transfer, verification work, and recovery incidents, then tighten or relax the limits using observed behavior.
Is a coordination budget the same as a token budget?
No. A token budget limits model input or output consumption, while a coordination budget governs the operating burden created by multiple execution paths. Tokens are one component. State transfer, permissions, result verification, duplicate effects, timeouts, tracing, and recovery can dominate even when message sizes remain small.
When does another agent justify its coordination cost?
Another agent is justified when the boundary buys a concrete property that is difficult to obtain inside one loop. Good reasons include narrower permissions, failure isolation, independent evaluation, specialized context, or useful concurrency. A role label or an extra rewrite step is not, by itself, enough.
What should happen when a run exceeds its coordination budget?
The harness should surface the breach and follow a declared policy: stop new fan-out, fail the stage, reduce scope through a recorded path, or request operator action. It should not silently omit verification, broaden permissions, or discard state merely to let the run report success.