18 Multi-Agent Coordination

Purpose

Agent stack focus for this chapter.

Why can splitting a task across several agents cost more and deliver less than giving one agent the same resources?

Splitting a task across several agents looks like the natural answer when the work is wide, since each worker can hold a smaller context and pursue its piece in parallel. The split replaces nothing the single agent already had. A capable single controller already runs searches and tests concurrently, keeps its context lean through retrieval and compaction, and holds scoped grants, so delegation must be judged against that baseline rather than against a fragile loop. What delegation adds is a set of boundaries between separately managed trajectories, and each boundary must carry explicitly what one trajectory carried implicitly. A worker can build against an interface that changes before its edit lands, two patches can merge cleanly and still break each other, reviewers that share a model can agree on the same mistake, and a canceled child can leave a container running and a budget half spent. Coordination overhead grows with every worker added, while the serial part of the task caps any speedup the parallel part can buy. Whether to split is therefore a measured decision. A multi-agent design earns its place only when it delivers more accepted tasks per unit of cost, or finishes them sooner in a way the objective values, than a single controller given the same tools and budget. Every handoff multiplies horizon, state, and authority, and the runtime must keep each delegated obligation owned until it settles.

Learning Objectives

Estimate the speedup and useful worker count of a work partition from its serial fraction and coordination overhead
Calculate makespan bounds from a task’s dependency graph to decide whether added slots or shorter tasks pay
Design bounded receipts and credit windows that cap returned context and payload occupancy, and size mean residence under an explicit freshness policy
Apply shared-write collision estimates to justify private workspaces and dependency revalidation before publication
Calculate majority false approval under correlated reviewer errors to choose between more reviewers and a different check
Evaluate fan-out completion rules and hedging under deadline, capacity, and duplicate-effect constraints
Apply spawn limits, restart policies, attenuated grants, and atomic reservations to bound a delegation tree’s fan-out, authority, and spending
Evaluate delegation against a capable single-controller baseline using a declared objective and matched resource ceilings

18.1 Splitting the Repair Agent’s Work

The repair agent (Four lighthouse workloads) has so far fixed a connection-pool race, a change confined to one module that a single controller holds comfortably in one context. Its next assignment is wider: migrate an authentication module across a repository, a change that reaches every caller of the module’s interface and is exactly the kind of repair task that tempts a split. The task naturally splits into two coupled changes: revising an internal interface and updating its downstream callers. A single coordinator could retain the entire task, dispatching parallel searches and test runs to collect evidence before synthesizing a unified patch. Alternatively, it could partition the problem, assigning the interface update and caller modifications to separate workers. Each worker operates within a focused context window, editing candidate files and reacting to compiler diagnostics independently. This division introduces an immediate distributed consistency challenge: the caller modifications must remain compatible with the interface that ultimately lands, not merely the snapshot the caller worker read at dispatch.

A fleet multiplies horizon, state, and authority, so every handoff must preserve closure.

The runtime mechanisms established in earlier chapters govern a single execution trajectory at a time. Within that boundary, the harness checks each model and tool invocation against an assigned grant and token budget, durable execution logs one trajectory’s event history, failure recovery settles, repairs, or compensates the effects of that one trajectory, evaluation compares trials of one configuration against another, and curation and post-training improve the policy that drives it. Partitioning the migration preserves these local controls inside each individual worker, but it leaves the coordination space between them unmanaged. A single-agent runtime provides no mechanism to resolve which interface revision the caller worker targets, whether a clean textual merge of two patches preserves semantic correctness, or what consensus among five reviewer agents actually guarantees. Nor does it define who claims an orphaned test container after a coordinator cancels a subtask, or how a parent bounds the authority and compute budget delegated to a child. Without explicit systems controls, every such gap threatens to make the split cost far more than it buys.

Making delegation governable requires runtime controls, and deciding whether it pays requires an empirical framework. The required controls are state records and verification gates owned directly by the runtime rather than left to prompt instructions: enforceable task assignments, receipts that separate an agent’s self-reported claims from verified tool evidence, a publication barrier that revalidates cross-module dependencies before any candidate patch merges, clean cancellation paths that account for in-flight work, and authority grants that narrow monotonically at every delegation hop. These mechanisms pair with a measurement discipline that compares each multi-agent design against a single agent holding equivalent parallel tools and resource budgets, and that prices every token consumed by failed, retried, or canceled subtasks.

The migration carries the argument from the decision to split through the final accounting, and each control answers a hazard that the previous one exposes. A screen of serial work against coordination overhead first decides whether a partition can pay at all (section 18.2). Dependency, communication, and supervision structures then fix what may run concurrently and who owns each child (section 18.3), and typed envelopes and receipts fix what crosses each handoff (section 18.4). Once workers run in parallel, guarded publication keeps their edits consistent (section 18.5), and a joint error model shows what agreement among reviewers can and cannot certify (section 18.6). Cancellation, hedging, and credit windows bound the work still in flight (section 18.7), attenuated grants and atomic reservations bound authority and spending at every hop (section 18.8), and a matched comparison against a capable single controller decides whether the whole design earns its tax (section 18.9).

18.2 The Delegation Trade-Off

Handing the interface update and the caller update to dedicated workers differs from issuing concurrent model queries, and that difference defines the unit of delegation. A delegated worker owns a bounded child trajectory with its own context window, model-and-tool loop, task contract, and independent lifecycle. Several candidate samples dispatched by one controller, such as the self-consistency votes of test-time compute, are instead parallel calls inside one trajectory. They are the cheapest ensemble an agent can run and also the most correlated, because every sample shares the model, the prompt, and the input’s difficulty, a dependence that section 18.6 quantifies. The architectural shift lies in establishing explicit boundaries between separately managed trajectories, regardless of whether those workers execute on a single host or across a distributed cluster.

↩︎ Self-consistency, which samples several reasoning paths and returns the plurality answer, is established in Choosing a selection rule.

The point of comparison throughout this chapter is the capable baseline: the single-agent runtime developed in earlier chapters, which already manages its context window, reserves system resources, verifies proposed tool effects externally, and executes candidate searches and isolated tools concurrently. Delegation retains every one of those operational requirements while introducing new coordination boundaries. The systems question is whether dividing control and context improves a declared task objective enough to justify the overhead of managing them.

18.2.1 Motivations for delegation

When a single agent runs a wide repository migration inside one shared context and one broad authority grant, compiler diagnostics from one module crowd out the prompt needed for the next while every tool call carries permissions for the whole codebase. Context partitioning addresses the prompt growth directly: each worker retains only the material strictly necessary for its subtask. In the migration scenario, the interface worker maintains the target API contract and local unit tests without ingesting the intermediate compiler diagnostics of the caller worker, allowing each subsequent model invocation to process substantially fewer prompt tokens. However, the net token savings depend entirely on the structure of the decomposition. If both workers repeatedly require the full repository commit history, separate contexts duplicate prompt state rather than isolating it, a redundancy the single-agent baseline already avoids through retrieval and compaction.

Delegation also provides separate task ownership. Workers can pursue multi-turn exploratory investigations through iterative tool feedback and local reasoning loops while a central coordinator tracks inter-task dependencies and orchestrates final integration. Assigning task ownership, however, does not eliminate underlying data dependencies. A caller worker that generates code against an outdated interface must still reconcile its implementation once the interface worker finalizes the new contract. True operational independence derives from the causal graph of the task itself, never from cosmetic role descriptions in prompt templates.

Finally, decomposing work across workers enforces task-scoped authority, binding tools, execution capabilities, and resource budgets directly to individual subtasks. For example, a test-runner worker can be granted execution privileges in an isolated container without granting it credentials to publish pull requests or write to production databases. Even so, process isolation does not eliminate trust boundaries. A child worker’s textual output can still inject unvalidated claims or prompt injections into the parent coordinator’s context, and any external mutations it produces must still be verified and settled by the runtime. Table 1 separates these opportunities from capabilities already present in the baseline.

Table 1: What Delegation Adds: The comparison preserves the capable single-controller runtime and identifies the extra boundaries a coordinated design must justify.

Dimension	One controller already provides	Delegation adds
Parallel work	Concurrent candidate calls and tools	Independently managed, multi-turn subtask trajectories
Context	Retrieval, compaction, and selective observations	Separate working contexts and explicit return boundaries
Authority and isolation	Scoped grants and sandboxed execution	Descendant grants and lifecycle relationships to enforce
State and evidence	Versioned artifacts and checks on proposed changes	Cross-worker dependency validation and integrated-result assessment
Resource control	Admission, reservations, deadlines, and settlement	Aggregate obligations across descendants and their communication

18.2.2 The coordination tax

These organizational advantages carry concrete systems costs. Every delegation boundary incurs a coordination tax (principle 14).

Definition 18.1: Coordination tax

Coordination tax is the work and elapsed time a delegated design spends on handoffs rather than on the task: preparing and validating envelopes, delivering context, scheduling children, collecting receipts, and reconciling and integrating their results.

Significance: The tax enters both terms of the cost per accepted task, $\CostPerAcceptedTask$ (equation 1.2): its tokens and tool time raise $\mathbb{E}[\AttemptCost]$, and the part on the critical path lengthens every attempt against its deadline.
Distinction: While task decomposition aims to reduce makespan by distributing work concurrently, the coordination tax represents the unavoidable friction introduced by that distribution. This tax scales with worker count, communication frequency, and inter-task dependencies.
Common pitfall: Accounting only for the tokens and execution time of successful worker turns. Context re-ingestion, supervisor arbitration turns, failed retries, and abandoned speculative branches all consume model quota and execution budgets.

Coordination tax impacts systems along two distinct dimensions: aggregate resource consumption and end-to-end latency. Duplicated input prompt tokens, redundant tool invocations, and serialize-deserialize cycles increase the total operational cost. Meanwhile, user-perceived delay is governed by makespan, the wall-clock time elapsed from the arrival of a task to the completion and verification of its final artifact. Makespan depends strictly on the operations situated on the critical path. A straggling child worker delays synchronization at the join barrier, while subsequent arbitration and reconciliation turns further inflate the critical path before results can be accepted.

Amdahl’s fixed-work argument¹ gives the first screening model (Amdahl 1967). Let $\SerialReferenceTime$ be the time for a fixed set of operations executed serially, with fraction $\ParallelFraction$ perfectly divisible among $\WorkerCount$ equally fast workers and fraction $1-\ParallelFraction$ remaining serial. Assume enough resources for that division and let $\CoordinationOverhead(\WorkerCount)$ be the additional elapsed overhead, normalized by $\SerialReferenceTime$. Then

¹ Amdahl’s Argument: Amdahl’s 1967 conference paper contains no equation; it argues in prose that the serial housekeeping of a program limits what any number of parallel processors can deliver, and the familiar formula was written down by later authors. The lesson transfers intact to delegation, where planning, integration, and final assessment are the housekeeping that no added worker absorbs.

\[\text{Speedup}(\WorkerCount)=\frac{\SerialReferenceTime}{\Time(\WorkerCount)}=\frac{1}{(1-\ParallelFraction)+\ParallelFraction/\WorkerCount+\CoordinationOverhead(\WorkerCount)}. \tag{1}\]

With no coordination overhead, $\CoordinationOverhead(\WorkerCount)=0$, equation 1 reduces to Amdahl’s law, and the serial term alone caps speedup at $1/(1-\ParallelFraction)$ for any number of workers. The equation provides a preliminary screening model for a specified work partition. The baseline $\SerialReferenceTime$ reflects that partition executed sequentially on a single thread of execution, rather than the capable baseline runtime (which already pipelines tool executions and concurrent candidate samplings). In production, an empirical benchmark of the capable baseline must replace $\SerialReferenceTime$ before finalizing any worker allocation. Within this theoretical formulation, achieving any net speedup over the serial reference requires that:

\[\CoordinationOverhead(\WorkerCount)<\ParallelFraction\left(1-\frac{1}{\WorkerCount}\right).\]

The right-hand side represents the theoretical wall-clock time saved by distributing the parallelizable portion across $\WorkerCount$ workers. Whenever coordination overhead $\CoordinationOverhead(\WorkerCount)$ exceeds this threshold, the split task takes longer than serial execution. Furthermore, this inequality constrains execution time alone; task acceptance rates, token expenditures, and monetary costs enter the trade-off in section 18.9, which gives serializing work and pairwise reconciliation separate coefficients because their remedies differ (section 18.9.3).

Napkin Math 18.1: Screening a proposed work partition

Problem: A hypothetical fixed workload has $\ParallelFraction=$ 0.80 and assumed normalized overhead $\CoordinationOverhead(\WorkerCount)=\WorkerOverheadSlope(\WorkerCount-1)$ with $\WorkerOverheadSlope=$ 0.02. The resource ceiling permits at most 16 workers. Which integer count minimizes modeled elapsed time?

Math: Evaluating the denominator of equation 1 for each permitted count, four workers require 0.460 of the serial reference time. The minimum occurs at 6 workers, requiring 0.433, a 2.3× speedup; eight workers increase the ratio to 0.440, because the shrinking parallel term $\ParallelFraction/\WorkerCount$ no longer pays for the added overhead. Halving the overhead coefficient to 0.01 moves the optimum to 9 workers and the speedup to 2.7×.

Systems insight: The serial fraction sets the ceiling and the overhead sets the useful fleet size. No worker count beats $1/(1-\ParallelFraction)=$ 5× here, and the best count sits near $\sqrt{\ParallelFraction/\WorkerOverheadSlope}$, so halving the per-worker overhead $\WorkerOverheadSlope$ adds 3 workers but only 0.4 of speedup. Shrinking the serial planning and integration work is the larger lever.

A reduction in modeled makespan does not automatically justify a multi-agent architecture. Production systems optimize under varied constraints: one automated migration service may seek to maximize accepted pull requests prior to a nightly release window subject to a strict token budget, whereas another prioritizes minimizing the total cost per accepted migration. Trading latency for computational overhead is justified only against an explicit, pre-declared optimization objective, and the decision framework of section 18.9 charges that objective for retries and failed executions as well. Before sizing a worker pool, an engineer must map the causal dependency graph of the workload to see which subtasks can run concurrently and what evidence each downstream join requires. Those dependencies govern the coordination topology.

18.3 Coordination Topologies

Consider a codebase migration task (migration_task_01) where an interface worker and a caller worker concurrently inspect a repository (repo_base_01). Even though both agents run in parallel, the caller’s patch depends on the interface definitions that its peer is actively modifying. Routing both workers through a single supervisor does not eliminate that underlying causal dependency. A runtime architecture that naively treats the supervisor’s message-routing graph as the true dependency graph will prematurely accept and publish a caller patch built on stale interface assumptions.

To build reliable multi-agent systems, engineers must distinguish three separate structural graphs that govern execution:

The dependency graph defines causal precedence by recording which artifacts, decisions, or validation checks must complete before downstream work can safely proceed.
The communication topology defines the network paths, protocols, and message envelopes through which agents exchange information.
The supervision tree defines operational ownership over agent lifecycles, governing fault isolation, resource reservations, and cancellation cascades.

Because a supervisor frequently manages children whose outputs depend causally on one another, runtime engines must maintain these three structures independently. Conflating message delivery with causal dependency or lifecycle ownership leads directly to race conditions, orphaned processes, and corrupted state.

18.3.1 Coordination arrangements

How work crosses boundaries between agents determines how communication routing and supervision map onto underlying task dependencies (table 2). The most prevalent pattern is the supervisor-worker topology (frequently termed orchestrator-worker). In this model, a centralized coordinator decomposes an incoming task, dispatches subtasks to subordinate workers, and synthesizes their returned receipts. This design directly mirrors the contract net protocol² originally developed for distributed problem solving (Smith 1980). In production systems, these foundational topologies frequently compose. For example, a supervisor might dispatch parallel analytical investigations, stream their candidate patches through a staged validation pipeline, and persist intermediate progress within a shared task store.

² Contract Net Protocol: In Smith’s 1980 protocol, a manager node announces a task, idle contractor nodes submit bids, and the manager awards the contract to a chosen bidder, which may subcontract in turn. The award represents the conceptual ancestor of the typed task envelope: it fixes which agent owns the subtask and what structured receipt must return, eliminating the ambiguity inherent in prompt-level delegation.

Table 2: Coordination arrangements and runtime obligations: While routing patterns structure message handoffs, the execution runtime must enforce result validity, resource boundaries, and state consistency across agent boundaries.

Arrangement	How work crosses a boundary	Useful when	Obligation that remains
Supervisor–worker	A coordinator assigns subtasks and collects bounded receipts	A task has separable investigations and an explicit integration decision	Bound dispatch, returned context, and the coordinator’s own work
Pipeline	Each stage receives the artifacts and evidence its predecessor is required to provide	Later work depends on a sequence of transformations or checks	Preserve stage preconditions and bound queues between stages
Shared blackboard	Workers claim tasks and publish versioned artifacts through a shared store	Different workers can contribute as dependencies become available	Enforce claim ownership, publication rules, and dependency validity
Actor messaging	Workers hold local state and exchange addressed messages	Responsibilities require ongoing asynchronous interactions	Define delivery, duplicate handling, ordering, and bounded mailboxes

Each coordination topology makes different trade-offs regarding where state accumulates and where synchronization occurs. A supervisor concentrates integration logic and validation evidence at a single coordinator, requiring compact, structured receipts to prevent prompt context exhaustion. A pipeline structures execution as a sequence of discrete transformations, keeping each stage’s working context tightly focused while streaming items concurrently across stages. By contrast, a shared blackboard³ decouples agents entirely by externalizing coordination into a centralized artifact and task store (Erman et al. 1980). In an actor architecture, originally formulated by Hewitt, Bishop, and Steiger, agents maintain completely isolated private state and communicate exclusively via asynchronous message passing to explicit addresses (Hewitt et al. 1973). Both blackboards and actor meshes shift the coordination burden toward explicit conflict resolution, distributed ordering, and bounded mailbox management.

³ Blackboard Architecture: The Hearsay-II speech-understanding system of the 1970s coordinated independent knowledge sources that never communicated directly with one another, interacting solely by posting and reading hypotheses on a shared global data structure. Its central scheduling challenge, deciding which pending contribution to evaluate next, reappears whenever agent workers claim tasks from a shared operational store.

Message counts scale with the communication graph and its interaction protocol. If each of $\WorkerCount$ participants transmits an update to every other participant during an execution round, the network must handle $\WorkerCount(\WorkerCount-1)$ directed deliveries. With an average payload size of $\MeanDeliveryPayloadLength$ tokens per delivery, that single round consumes $\WorkerCount(\WorkerCount-1)\MeanDeliveryPayloadLength$ tokens across the system. In contrast, a supervisor managing $\WorkerCount$ workers requires only $2\WorkerCount$ deliveries per round (one dispatch envelope and one receipt per worker), consuming $2\WorkerCount{}\MeanDeliveryPayloadLength$ tokens. The full mesh thus scales quadratically, transmitting $(\WorkerCount-1)/2$ times more messages per round than the centralized coordinator.

Raw transmission volume measures network traffic, not what the receiving models must ingest. In a fully connected mesh where each agent appends every incoming peer message to its prompt history, ingested tokens per round grow as $\mathcal{O}(\WorkerCount^2)$, and the append-only re-send of equation 2.9 compounds that growth across rounds because each later prompt carries every earlier delivery. Even in a centralized topology, verbose receipts, iterative deliberation rounds, or frequent status polling against a blackboard store can exhaust context windows and inflate inference budgets. Across the four arrangements of figure 1, the supervisor’s round costs $2\WorkerCount$ deliveries and the actor mesh up to $\WorkerCount(\WorkerCount-1)$, while the pipeline and blackboard replace direct deliveries with bounded queues and versioned claims that the runtime must police. An arrangement therefore keeps context windows bounded only when each handoff carries the specific inputs and checks a subtask requires, and deciding when those handoffs may fire belongs to the dependency graph.

Figure 1: **Four Coordination Arrangements**: Each panel shows where work crosses a boundary. A supervisor sends envelopes down and collects receipts, a pipeline passes artifacts through bounded queues, a blackboard mediates claims and versioned publications through a shared store, and actors exchange addressed messages through mailboxes. One supervisor round costs $2\WorkerCount$ deliveries and a full mesh round $\WorkerCount(\WorkerCount-1)$. Each topology imposes specific runtime obligations for bounding queues, isolating concurrent state, and verifying result correctness.

18.3.2 Dependency graphs and concurrency

Dispatching subtasks before their prerequisites are verified wastes tokens on stale assumptions or stalls worker slots behind unfinished upstream steps. To schedule concurrent work safely, the runtime models task precedence as a directed acyclic graph (DAG), $(\DependencyGraphVertexSet,\DependencyGraphEdgeSet)$. Each vertex $\DependencyGraphVertex \in \DependencyGraphVertexSet$ represents a bounded unit of execution, either an autonomous agent trajectory or a deterministic runtime validation check. A directed edge $(\PredecessorGraphVertex,\DependencyGraphVertex) \in \DependencyGraphEdgeSet$ indicates that vertex $\DependencyGraphVertex$ requires a declared precondition satisfied by vertex $\PredecessorGraphVertex$, such as an emitted code artifact, a validated test report, or an explicit authorization token. A status message signaling task completion satisfies an incoming edge only when accompanied by verifiable output receipts.

A vertex becomes dependency-ready once every prerequisite predecessor condition has been verified. Dependency readiness alone does not trigger execution, however. The runtime dispatcher must additionally verify execution authority, allocate an active worker slot, and secure a bounded token and financial budget reservation. If a predecessor fails or emits invalid artifacts, the control plane either halts downstream successors or transitions execution to an explicit recovery branch. Loops and iterative refinement cycles enter the graph as unrolled, bounded attempts. Because graph acyclicity guarantees only the absence of logical dependency loops, the underlying runtime remains responsible for detecting dynamic deadlocks arising from shared resource locks, exhausted thread pools, or saturated queues.

To estimate the theoretical limits of parallel scheduling, assume each vertex $\DependencyGraphVertex$ occupies one interchangeable worker slot for a fixed duration $\VertexSlotTime(\DependencyGraphVertex)$, encompassing both model inference latency and external tool execution. Let $\WorkerCount$ represent the pool of available parallel worker slots. Under these assumptions, aggregate slot-work $\AggregateSlotWork$ totals every vertex’s duration, and critical-path duration $\CriticalPathDuration$ is the length of the longest dependency chain, the same critical path that trace analysis measures from recorded spans, here computed from assumed durations:

\[ \AggregateSlotWork=\sum_{\DependencyGraphVertex\in \DependencyGraphVertexSet}\VertexSlotTime(\DependencyGraphVertex),\qquad \CriticalPathDuration=\max_{\pi\in\operatorname{Paths}(\DependencyGraphVertexSet,\DependencyGraphEdgeSet)}\sum_{\DependencyGraphVertex\in\pi}\VertexSlotTime(\DependencyGraphVertex). \tag{2}\]

Any valid schedule’s total makespan $\ScheduleFinishTime$ must satisfy the dual lower bounds

\[ \ScheduleFinishTime\ge\max\left(\frac{\AggregateSlotWork}{\WorkerCount},\CriticalPathDuration\right). \tag{3}\]

The aggregate work bound $\AggregateSlotWork/\WorkerCount$ reflects the capacity constraint, since $\WorkerCount$ parallel worker slots cannot complete $\AggregateSlotWork$ total units of execution time in less than $\AggregateSlotWork/\WorkerCount$, regardless of schedule structure. The critical-path bound $\CriticalPathDuration$ reflects the causal precedence constraint, since sequential dependencies cannot be parallelized, and it establishes a lower bound on latency even with infinite worker slots.⁴ In production environments, resource contention, queuing overhead, payload serialization, and trajectory retries expand the overall makespan well beyond these theoretical minimums unless explicitly incorporated into vertex durations $\VertexSlotTime(\DependencyGraphVertex)$ and graph edges.

⁴ Greedy List Scheduling: Graham established that any list schedule which never leaves a worker slot idle while a dependency-ready vertex waits completes within a factor of $2-1/\WorkerCount$ of the optimal makespan. Graham also demonstrated that such schedules can suffer counterintuitive timing anomalies where adding worker slots or reducing individual task durations actually increases overall completion time (Graham 1969). A runtime dispatcher that greedily schedules ready work is therefore near-optimal relative to the theoretical bound in equation 3, and an observed latency regression after expanding worker pools does not necessarily indicate a scheduler implementation bug.

Graham, Ronald L. 1969. “Bounds on Multiprocessing Timing Anomalies.” SIAM Journal on Applied Mathematics 17 (2): 416–29. https://doi.org/10.1137/0117039.

↩︎ Trace-based measurement of the critical path is established in Span overlap and latency attribution.

Napkin Math 18.2: DAG scheduling in multi-agent execution

Problem: Consider an illustrative repository upgrade with 4 worker slots. Table 3 gives assumed durations for a single successful execution of each node. Each node occupies one slot; there are no additional dispatch delays, resource conflicts, retries, or transfer costs. How much can overlap?

Table 3: An idealized dependency schedule: Starts are the latest finish among required predecessors. The schedule assumes that each predecessor supplies the result required by its successor.

Work	Required predecessors	Slot duration	Earliest start	Earliest finish
$\DependencyGraphVertex_1$: prepare shared specification	None	20.5 s	0 s	20.5 s
$\DependencyGraphVertex_2,\DependencyGraphVertex_3,\DependencyGraphVertex_4$: refactor separate modules	$\DependencyGraphVertex_1$, for each	42 s each	20.5 s	62.5 s
$\DependencyGraphVertex_5$: assess the joint changes from two modules	$\DependencyGraphVertex_2,\DependencyGraphVertex_3$	43 s	62.5 s	105.5 s
$\DependencyGraphVertex_6$: prepare bindings for the remaining module	$\DependencyGraphVertex_4$	16.5 s	62.5 s	79 s
$\DependencyGraphVertex_7$: integrate and run required regression checks	$\DependencyGraphVertex_5,\DependencyGraphVertex_6$	69 s	105.5 s	174.5 s

Math: Summing the node durations as in equation 2 gives 275 s of aggregate slot-work. Dividing by the slot count gives the work term in equation 3, 68.75 s. The paths $\DependencyGraphVertex_1\to \DependencyGraphVertex_2\to \DependencyGraphVertex_5\to \DependencyGraphVertex_7$ and $\DependencyGraphVertex_1\to \DependencyGraphVertex_3\to \DependencyGraphVertex_5\to \DependencyGraphVertex_7$ tie for the critical path. The table’s schedule uses at most 3 slots, so it is feasible under the stated capacity and attains the path bound.

Result: Completion takes 174.5 s, a 1.58× speedup over executing these same nodes serially, and more slots cannot shorten the remaining chain.

Systems insight: Once a schedule attains the critical-path bound, as this one does, allocating worker slots beyond peak concurrency yields zero latency improvement. The off-critical branch through $\DependencyGraphVertex_4$ and $\DependencyGraphVertex_6$ finishes 26.5 s before $\DependencyGraphVertex_7$ can start, meaning optimizations on that branch do not affect overall makespan. In contrast, shortening $\DependencyGraphVertex_5$ or $\DependencyGraphVertex_7$ yields a direct second-for-second reduction in total makespan up to the available slack. Shortening $\DependencyGraphVertex_2$ in isolation provides no benefit because $\DependencyGraphVertex_3$ ties it on the critical path. Analyzing production agent traces requires distinguishing a dependency-limited schedule like this one from a capacity-limited schedule, where additional slots or reduced contention can still shorten makespan.

18.3.3 Static plans and dynamic spawning

When a coordinator fixes every subtask before execution begins, workers cannot branch when they uncover an undocumented dependency; conversely, letting a model spawn children at will can turn a simple query into dozens of redundant trajectories. A static plan resolves this trade-off toward predictability by specifying its stages, conditional branches, validation checkpoints, and retry bounds ahead of execution. Because all artifact dependencies and message routes are declared upfront, operators can inspect handoffs statically and verify safety invariants before dispatch. With enforced per-node work limits, bounded attempts, and stated service or deadline assumptions, the declared graph supports worst-case resource and execution bounds; a termination deadline does not guarantee accepted completion or immediate settlement of external work.

In contrast, dynamic spawning provisions child agents at runtime in response to intermediate observations. For example, during a repository migration, a worker analyzing call sites might uncover an undocumented dependency and request an isolated sub-investigation. While the model proposes this subtask dynamically, the runtime control plane must evaluate and admit it under the prevailing task contract. Dynamic spawning allows systems to adapt flexibly to open-ended workloads, but it introduces non-deterministic execution graphs. When an unconstrained model decides how many child agents to spawn and when to spawn them, combinatorial fan-out can quickly overwhelm system capacity and inflate execution costs.

War Story 18.1: Unbounded fan-out in a multi-agent research system (2025)

Context: Anthropic’s engineering team described building an autonomous research system where a lead orchestrator plans an investigation, spawns parallel subagents to search for evidence, and synthesizes their findings (Hadfield et al. 2025).

Mechanism: The lead agent possessed unconstrained authority to determine subagent fan-out. In early prototype versions, the model routinely spawned 50 subagents even for simple queries, searched endlessly for nonexistent sources, and allowed subagents to degrade coordination by flooding one another with excessive updates.

Impact: The engineering team reports that autonomous agents typically consume about 4× more tokens than standard conversational interactions, while multi-agent systems consume roughly 15× more. Although the multi-agent configuration outperformed a single agent by 90.2 percent on the team’s internal research evaluation, the unconstrained fan-out incurred disproportionate resource expenditure on straightforward tasks.

Fix: The team embedded explicit scaling heuristics into the orchestrator’s prompt, instructing the model to calibrate subagent allocation to query complexity, allocating a single agent for direct fact retrieval and scaling upward only for open-ended synthesis. Furthermore, the orchestrator was structured to wait synchronously for each dispatched subagent batch to conclude before initiating subsequent steps, simplifying state synchronization at the cost of pipeline parallelism.

Systems lesson: Dynamic fan-out is an architectural resource-allocation problem that cannot rely on model self-restraint alone. While prompt-based heuristics guide model proposals, the runtime control plane must enforce hard admission limits on tree breadth, recursion depth, and aggregate budget reservations, directly bounding the token consumption in the effective cost metric $\CostPerAcceptedTask$.

Uncontrolled fan-out illustrates the necessity of formal admission control in multi-agent architectures. Prompt instructions alone cannot curb subtask generation, because an unconstrained model can still propose redundant branches or trigger cascading worker requests. Simply allocating each child a budget fraction smaller than the parent’s remaining funds also fails to protect the system, as a burst of concurrent siblings can issue overlapping claims that collectively exceed available capacity. The runtime admission controller must atomically reserve each child’s maximum potential liability against the shared task budget before dispatching execution, an invariant that section 18.8 formalizes across hierarchical delegation trees. Production runtimes must independently enforce four distinct bounds: fan-out breadth (maximum children per parent), concurrent active slots (maximum parallel executions), recursion depth (maximum delegation layers), and absolute deadlines. A shallow tree can still exhaust resources through excessive breadth, while a strict concurrency cap can still permit an unbounded sequence of sequential worker allocations.

↩︎ Bounded-liability admission, which reserves an operation’s maximum charge before admitting it, is established in Reservation and settlement.

18.3.4 Supervision trees

Beyond resource management, dispatching a child agent establishes lifecycle ownership. A child’s running trajectory, pending tool invocations, and uncommitted side effects typically outlive the ephemeral model call that spawned it. The supervision tree defines how the runtime isolates faults and manages recovery when a child encounters an unrecoverable failure. Following the supervision trees of Erlang/OTP (Open Telecom Platform),⁵ systems formalize recovery through explicit, per-supervisor restart strategies (Armstrong 2003, 2007):

⁵ Erlang Supervision Trees: Erlang emerged from a telephone-switching research program initiated in 1981, established on the design principle that systems should allow failing processes to crash cleanly while a designated supervisor restores known-good state, rather than attempting defensive error handling locally (Armstrong 2003). In agentic systems, this principle is even more vital: allowing a confused agent trajectory to attempt local recovery within a contaminated context window frequently compounds its errors, whereas a supervisor restart provisions a clean execution context from recorded inputs.

Armstrong, Joe. 2003. “Making Reliable Distributed Systems in the Presence of Software Errors.” PhD thesis, Royal Institute of Technology (KTH).

Armstrong, Joe. 2007. “A History of Erlang.” Proceedings of the Third ACM SIGPLAN Conference on History of Programming Languages (HOPL III), 6-1-6-26. https://doi.org/10.1145/1238844.1238850.

Under a one_for_one policy, the supervisor restarts only the failed child agent while allowing sibling workers to continue uninterrupted. This strategy is ideal for embarrassingly parallel or loosely coupled subtasks, such as searching disjoint documentation sources, where workers share no mutable intermediate state.
Under a one_for_all policy, the failure of any single child triggers the supervisor to terminate and restart all sibling workers within that supervision group. This approach is essential for tightly coupled collaborative tasks where partial artifacts become invalid upon peer failure. For example, if an interface worker crashes and restarts with an altered API contract, any partial implementation generated by a concurrent caller worker is invalidated.

The two policies differ in blast radius (figure 2): one failure under one_for_one costs a single fresh attempt and its reservation, whereas under one_for_all it discards the progress of every coupled sibling and restarts the whole group from recorded inputs. To prevent degenerate retry storms under either policy, supervision trees enforce a restart intensity bound, the maximum number of restarts permitted within a sliding time window. When a child agent repeatedly fails and breaches this threshold, the supervisor ceases local restarts, aborts its remaining subordinates, and escalates the failure upward to its own parent supervisor. In an agentic system, a restart must never simply continue from the failed worker’s corrupted or circular context window. Instead, the runtime treats each restart as a freshly admitted attempt, provisioning a clean context initialized from recorded input artifacts and acquiring a fresh budget reservation, while invoking the structured cancellation and cleanup protocols of section 18.7 whenever it aborts sibling processes under one_for_all or escalation.

Figure 2: **Restart Policies in a Supervision Tree**: Under the one-for-one policy (a), only the failed worker restarts, as a newly admitted attempt with its own reservation, while its siblings continue. Under the one-for-all policy (b), the supervisor stops the coupled siblings through the cancellation protocol and restarts the whole group from recorded inputs, because the caller’s partial work has lost its meaning. Either supervisor that exceeds its declared restart intensity stops restarting and escalates the failure to its parent.

Checkpoint 18.1: Evaluating multi-agent coordination topologies

Dependency vs. routing: The interface and caller workers communicate only through their supervisor. Why can they still produce interdependent patches, and which of the three structures records that?
Critical-path estimate: Using the durations in table 3, estimate how much completion changes if $\DependencyGraphVertex_6$ takes 20 s less, and how much if $\DependencyGraphVertex_5$ takes 20 s less. Which node should an engineering team speed up?
Worker-count screen: With $\ParallelFraction=0.9$ and the notebook’s overhead $\WorkerOverheadSlope=$ 0.02 per extra worker, estimate the best worker count from $\sqrt{\ParallelFraction/\WorkerOverheadSlope}$ and the speedup ceiling $1/(1-\ParallelFraction)$. Is it worth halving $\WorkerOverheadSlope$ or halving $1-\ParallelFraction$?
Aggregate admission: Why can granting every child less than its parent’s remaining budget still oversubscribe the task? What must happen atomically?

A coordination topology fixes how work, messages, and lifecycle ownership cross agent boundaries, but routing and supervision alone do not specify what a child is allowed to do once it starts. Without an explicit contract on each handoff, a worker can still read stale inputs, touch files outside its scope, or return a long narrative in place of verifiable evidence. Every boundary crossing therefore requires a formal task envelope that states what artifacts the worker receives, what tools and tokens it may consume, and what typed receipt it must return.

18.4 Typed Task Envelopes

A message asking worker_caller_01 to “update the callers” leaves critical engineering boundaries unspecified: the target interface version, the files permitted to change, the resource budget, and the acceptance criteria for completion. If the worker fills those gaps from its own interpretation of the prompt, that interpretation becomes the de facto contract. While a workflow dependency edge dictates when a child task may begin, the task envelope defines what that child is permitted to read, modify, spend, and return. Delegation therefore requires a typed action contract (principle 7) that extends across the agent boundary, much like a typed interface in a classic remote procedure call establishes formal argument types, return values, and failure semantics before execution begins (Birrell and Nelson 1984).

Definition 18.2: Typed task envelope

A typed task envelope is a versioned assignment record binding a child task to identified inputs, a scoped authority grant, resource and lifecycle limits, completion requirements, and a bounded return format.

Significance: The runtime validates task boundaries before admitting work and verifies returned artifacts against required evidence. In addition, capping the return payload prevents runaway worker outputs from flooding the coordinator’s context window on subsequent execution turns.
Distinction: The envelope defines an operational, enforceable contract for execution and resources; the natural-language prompt merely describes the objective within those constraints.
Common pitfall: Mistaking a syntactically valid envelope for proof of authorization or successful execution. Both authorization and task completion require verification against authoritative state records maintained outside the worker’s control.

18.4.1 Task assignments

If a parent passes a subtask in free-form prose or embeds mutable budget numbers directly inside the child’s prompt, the child can misread its scope or rewrite its own limits. When delegating a subtask, the parent agent proposes the work, but the execution runtime authenticates the parent-child relationship, resolves the authority grant, and locks the resource reservation. In the task envelope shown in listing 1, field identifiers point to immutable registry records rather than embedding raw, unverified data. The referenced acceptance contract specifies expected caller behavior, exact test suite versions, the execution environment, and any required human reviews prior to final acceptance.

Listing 1: Bounded Child Assignment: The envelope identifies inputs, authority, resource ownership, acceptance requirements, and limits on the return.

{
  "task_id": "worker_caller_01",
  "parent_task_id": "migration_task_01",
  "envelope_version": "caller_assignment_v1",
  "dispatch_id": "caller_dispatch_01",
  "assignment": "Update the designated authentication callers.",
  "inputs": {"base_ref": "repo_base_01"},
  "authority": {"grant_ref": "caller_private_patch_grant_01"},
  "budget": {"reservation_ref": "caller_reservation_01"},
  "completion": {
    "contract_ref": "migration_accept_v1",
    "required_evidence": [
      "candidate_ref", "write_set_ref", "dependencies_ref",
      "check_report_ref", "usage_ref", "settlement_ref"
    ]
  },
  "return_limits": {
    "receipt_bytes": 8192,
    "optional_summary_tokens": 256,
    "artifact_references": 8
  }
}

In listing 1, the task and dispatch identifiers tie the assignment to its durable write-ahead log intent so that recovery can reconcile unresolved work before any permitted retry, while base_ref pins the immutable repository snapshot exposed to the worker (any reads beyond that snapshot, such as queries to external package registries, require their own versioned references). Within that snapshot, grant_ref restricts the worker to editing designated caller files in an isolated scratch workspace, reading approved paths, and running local verification commands; the capability gate enforces parameter-level constraints on each tool invocation and explicitly withholds publication rights to shared branches. Alongside that authority grant, reservation_ref establishes hard limits on consumable resources, including input and output tokens as well as tool execution counts. Because the runtime resolves all three references against authoritative registry state before dispatch, a worker cannot expand its privileges or budget by modifying envelope fields in its own context.

↩︎ Durable intent, the admitted request recorded before dispatch so recovery retains its identity and can resolve an uncertain outcome, is established in Durable Intent Before Dispatch.

The remaining two blocks in listing 1 govern how the child returns its work. Completion requirements name the evidence records the runtime must collect, such as candidate diffs, dependency manifests, check reports, and usage and settlement records, before the task can count as complete. Return limits cap the receipt size, optional summary tokens, and artifact references so bulky build outputs stay in external storage rather than flooding the coordinator’s context window, and the receipt described next records how the child met those rules.

18.4.2 Task receipts

When the child finishes or halts within those limits, the runtime packages the result into a receipt that mirrors the assignment envelope. The return payload in listing 2 describes a candidate change ready for integration review, one step short of an accepted modification, and strictly separates verified operational metadata from unverified model commentary: runtime services directly populate and authenticate every field under runtime, whereas assertions generated by the worker model remain isolated under worker_claims.

Listing 2: Bounded Child Receipt: Runtime records and a worker-authored explanation remain distinct; candidate readiness does not authorize publication.

{
  "task_id": "worker_caller_01",
  "envelope_version": "caller_assignment_v1",
  "dispatch_id": "caller_dispatch_01",
  "return_status": "complete",
  "runtime": {
    "status": "candidate_ready",
    "base_ref": "repo_base_01",
    "candidate_ref": "caller_candidate_01",
    "write_set_ref": "caller_writes_01",
    "dependencies_ref": "caller_dependencies_01",
    "check_report_ref": "caller_checks_01",
    "usage_ref": "caller_usage_01",
    "settlement_ref": "caller_settlement_01"
  },
  "worker_claims": {
    "summary": "Updated the designated callers for the migration."
  }
}

The write-set record reflects the diff actually produced in the isolated workspace rather than the worker’s conversational recollection of what it modified. Similarly, the dependency record captures observed file reads, loaded package versions, configuration files, and external environment flags, bounded by explicit tracing coverage. The checker report records the exact candidate hash, the test command, the container environment, and the exit status. This record carries the evidence-scope rule of the tool boundary across the delegation boundary. A single call’s observation confirmed only what that call measured; a check result here establishes an outcome for one identified candidate hash, checker, and environment, and authorizes nothing beyond it. If the runtime cannot produce or verify every piece of mandatory evidence, the return status transitions to evidence_unavailable rather than complete.

↩︎ The evidence-scope rule, under which an observation confirms only what its tool measured during that invocation, is established in Complete mediation.

The usage record accounts for charged and reserved work across tokens, wall-clock time, and tool invocations. The settlement record distinguishes a stop acknowledgment, confirmed resource release, and unresolved background operations with retained owners. A complete return and the final settlement of every operation are therefore distinct statuses. This separation becomes critical when the parent cancels an execution branch (section 18.7), ensuring that task termination does not leave orphaned background processes or dangling locks. Optional prose explanations may be shortened or omitted when space is constrained, with the omission explicitly recorded, while required identities, statuses, and evidence references pass intact. If the mandatory structural fields alone exceed receipt_bytes, the runtime generates an explicit payload-size failure rather than returning a truncated record.

18.4.3 Reference passing and selective reads

Instead of inlining an entire repository tree into a child task’s context prompt, the parent passes an immutable repository reference (base_ref). The worker then issues targeted read queries to fetch only the source files relevant to its assignment. However, this pass-by-reference pattern yields net token savings only when the child inspects a small fraction of the code base. If the worker iteratively fetches broad directory trees, the combined cost of reference overhead, tool invocation tokens, and repeated context re-reads across turns can quickly outstrip the cost of an upfront payload. Passing a shared base reference also amortizes KV-cache prefill across parallel workers, but only when their prompt prefixes align.

↩︎ Prompt prefix alignment and KV-cache prefill amortization are established in Preserving an exact prefix.

Napkin Math 18.3: Price the reads after the handoff

Problem: Each of 6 children receives either a 48,000-token repository slice or a 350-token reference envelope followed by 3,600 tokens of retrieved content. With all other inputs equal, no cache discount, and a hypothetical $3 per million input tokens, how much repository-delivery input does the reference save?

Math: Pasting costs 6 $\times$ 48,000 $=$ 288,000 tokens, or $0.864. The reference costs 6 $\times$ (350 $+$ 3,600) $=$ 23,700 tokens, or $0.071, a 12.2× reduction. If every child instead reads the full slice, the reference design consumes 290,100 tokens and loses its saving.

Systems insight: The efficiency of reference passing depends entirely on read selectivity rather than the pointer mechanism alone. In this configuration, each child inspects only 7.5 percent of the slice, keeping reference passing economical until reads exceed 47,650 tokens. Effective multi-agent system design therefore pairs pointer handoffs with precise task scoping and indexing.

Once execution concludes, the receipt hands the parent coordinator an isolated candidate, its base version, and runtime-recorded evidence. Those records, not the absence of overlapping files, decide whether candidates can merge safely. Two patches that touch disjoint files can still be incompatible, and making that judgment before anything publishes is the job of the next section.

18.5 Optimistic Concurrency Control

Consider an authentication migration where the runtime assigns worker_interface_01 to update an interface and worker_caller_01 to adapt a call site. Both workers branch from the same baseline commit, repo_base_01. When the interface worker finishes first, the integration service accepts its patch as repo_head_02. Because the caller worker modifies a different file, a standard three-way textual merge succeeds cleanly without merge conflicts. The caller’s patch, however, still targets the obsolete interface. Modifying separate files prevented a textual collision, but it left the semantic dependency behind the caller’s code unchecked.

Optimistic concurrency control (OCC) resolves this tension by letting each agent work privately against a snapshot and validating every publication prerequisite before the shared branch changes (Kung and Robinson 1981). A transaction runs a read phase against private copies, a validation phase that checks whether concurrent commits invalidated anything it read, and a write phase that commits only after validation succeeds; the expected-version check at the tool boundary is that validation applied to a single file. The scheme pays when conflicts are rare, because it trades lock waiting for occasional discarded work. A worker’s read phase, however, spans minutes of model generation and tool execution rather than the brief life of a database transaction, so a failed validation discards real inference spend, and its prerequisites include dependency freshness and acceptance evidence as well as unchanged files. Instead of holding a repository lock while an agent deliberates, the runtime decouples private execution from integration, which exposes parallelism and converts conflicts into the coordination tax of candidate revalidation and occasional discarded work.

↩︎ Conditional updates that commit only while the target still matches its expected version are established in Conditional updates.

18.5.1 Shared workspace hazards

Operating multiple agents within a single shared working directory introduces three immediate failure modes. A lost update occurs when two workers inspect the same file, deliberate over multiple inference turns, and serialize their writes back to disk. The later write silently replaces the earlier contribution, and the operating system reports no error because both writes were valid. A torn dependency read emerges when an agent executes tests while a peer is actively modifying related files, for example by evaluating code after a new interface has landed but before the caller has been updated. The test runner executes against an incoherent intermediate state that no agent ever intended to propose. Finally, tool-lock contention strikes when concurrent build tools or version-control commands collide on local metadata locks, such as Git’s .git/index.lock. One worker crashes on a locked index even when the underlying edits target entirely disjoint directories.

Shared writes pass even odds at five workers, long before a fleet feels large.

These collisions manifest surprisingly early as agent concurrency grows. Suppose a repository contains $\RepositoryFileCount$ files and each of $\WorkerCount$ workers modifies $\WorkerWrittenFileCount$ distinct files, chosen uniformly and independently at random. Worker $\EarlierWorkerCount+1$ avoids overlapping with all preceding workers only if it selects its $\WorkerWrittenFileCount$ files exclusively from the $\RepositoryFileCount-\EarlierWorkerCount \WorkerWrittenFileCount$ files that earlier workers left untouched. The probability that all $\WorkerCount$ write sets remain pairwise disjoint is therefore

\[ \Pr(\text{no shared write})=\prod_{k=1}^{\WorkerCount-1}\frac{\binom{\RepositoryFileCount-\EarlierWorkerCount \WorkerWrittenFileCount}{\WorkerWrittenFileCount}}{\binom{\RepositoryFileCount}{\WorkerWrittenFileCount}}\approx\exp\left(-\frac{\WorkerCount(\WorkerCount-1)\WorkerWrittenFileCount^2}{2\RepositoryFileCount}\right). \tag{4}\]

Equation 4 is the birthday bound⁶ generalized to multi-file write sets. Because the exponent scales quadratically with the number of worker pairs rather than linearly with worker count, collision odds mount rapidly. In a hypothetical repository of 1,000 files where each worker touches 10 files, even 2 concurrent workers collide with probability 9.6 percent. At 5 workers, a write collision becomes more likely than not, and scaling to 8 workers drives the collision probability to 94.4 percent. In practice, uniform random access is an illustrative baseline that can understate risk when writes cluster; actual agent modifications heavily cluster around package manifests, central routing tables, and shared configuration files. Rigorous workspace isolation is therefore an architectural prerequisite for multi-agent coordination, rather than a performance tuning knob reserved for massive worker pools.

⁶ Birthday Bound: The classical birthday problem calculates the number of people required before two share a birthday. The answer, twenty-three people for even odds across 365 days, often surprises newcomers because the number of potential pairs grows quadratically with group size. Systems designers exploit this same relation to size hash tables and cryptographic identifiers. In multi-agent execution, each worker represents an individual and the repository files represent the calendar, with collision probability amplified because each worker samples $\WorkerWrittenFileCount$ distinct files simultaneously rather than a single day.

Providing each worker with an isolated workspace establishes a stable snapshot baseline and an unshared scratchpad for local modifications, so when a worker finishes, the runtime receives an immutable candidate artifact (identified by a cryptographic commit hash) rather than a reference to a mutable filesystem directory. Runtimes implement this isolation through two main mechanisms: linked Git worktrees, which allocate a dedicated working tree, index, and HEAD pointer for each agent while sharing underlying object storage in .git/objects, and copy-on-write filesystems, which provide block-level cloning and zero-copy snapshots governed by runtime pooling lifecycles and reset contracts.

↩︎ Copy-on-write provisioning, which copies only what a task writes over a read-only base, is established in Copy-on-write provisioning.

Neither filesystem mechanism provides security on its own. If an agent executes arbitrary shell commands with unrestricted filesystem permissions, it can traverse parent directories, access peer worktrees, or corrupt the shared Git directory. A robust architecture therefore pairs workspace isolation with an external sandbox and a mediated tool gateway. The gateway confines filesystem writes to the assigned worktree, strips integration credentials, and allocates ephemeral ports and temporary directories for test suites. Furthermore, discarding a worktree cleanly recycles local ephemeral state, but it cannot revoke side effects that an external service has already accepted.

18.5.2 Dependency validation at integration

When a worker signals completion, the centralized integration service evaluates the returned execution receipt. The service resolves runtime.base_ref and runtime.candidate_ref, verifies cryptographic commit lineage, and independently derives the modified file paths rather than trusting a worker-reported write set. Beyond commit hashes, the service inspects runtime.dependencies_ref, which records the exact source versions, environmental flags, and file reads underpinning the candidate. Reliable dependency tracking requires runtime instrumentation of mediated filesystem calls, lockfiles, and configuration manifests; subjective, model-generated self-reports cannot be trusted for correctness. Furthermore, negative dependencies require careful tracking: an agent’s code generation may depend on the absence of a conflicting file, meaning that recording only positive file reads yields incomplete dependency graphs. Whenever dependency tracking is partial or ambiguous, the integration service treats an empty dependency manifest as unknown rather than disjoint, triggering a fresh revalidation of the candidate against the current branch head.

Let the commit content hashes $\WorkerBaseCommitHash$, $\WorkerCandidateCommitHash$, and $\IntegrationHeadCommitHash$ identify the worker’s base, its returned candidate, and the integration head captured for this attempt. The protocol has four steps, which listing 3 condenses into the control flow of an integration service.

Revalidate dependencies: Compare dependency versions between $\WorkerBaseCommitHash$ and $\IntegrationHeadCommitHash$. Pairwise disjoint file sets demonstrate only textual independence; if a referenced interface or schema changed on the main branch, the runtime must revise or regenerate the candidate before attempting integration.
Build the candidate: Construct an immutable integration candidate $\IntegrationCandidateCommitHash$. If $\IntegrationHeadCommitHash$ still matches $\WorkerBaseCommitHash$, the candidate is simply the worker’s own commit $\WorkerCandidateCommitHash$ (the fast-forward path). If the head advanced, the service stages a private merge commit combining $\IntegrationHeadCommitHash$ and $\WorkerCandidateCommitHash$. Should textual or structural conflicts arise, the service may dispatch a bounded reconciliation task to an agent; the resulting merge artifact is treated as a fresh candidate proposal, subject to the full validation pipeline.
Check the exact candidate: Every integration candidate must pass the scope and quality checks mandated by migration_accept_v1 within the protected assessment sandbox of Grader isolation. Under the evidence-scope rule, verification tests executed on the worker’s private branch do not validate the newly synthesized merge candidate. Acceptance criteria must be evaluated directly on the exact commit hash $\IntegrationCandidateCommitHash$.
Publish with an expected-head update: Advance the target ref if and only if the current branch pointer still equals the captured $\IntegrationHeadCommitHash$ and all publication guards remain satisfied. These guards verify active grant authorization, unrevoked task status, comprehensive dependency tracking, and fresh acceptance test evidence. In Git, the low-level update-ref command with an expected old object hash guarantees an atomic compare-and-swap. The runtime sequences authorization guards with this atomic ref update to eliminate race conditions between token revocation and publication, while external dependencies are anchored by their action-time version contracts.

If a concurrent writer advances the branch head before the atomic ref update executes, the integration attempt aborts. Rather than blindly retrying the update against the new head, the service loops back to step 1, revalidating all dependencies against the updated state. If the publication command returns an ambiguous network outcome or timeout, the service must query the authoritative repository log before attempting a retry, preventing duplicate commits. Figure 3 assembles the three ingredients—private worktrees over shared repository storage, a staged merge that is textually clean even though the caller relies on the interface as of $\WorkerBaseCommitHash$, and the four-step gate whose moved-head exit returns to revalidation—while table 4 follows the caller worker’s patch across each decision boundary.

Listing 3: Guarded Integration of a Worker Candidate: The service revalidates dependencies against the captured head, checks the exact candidate, and publishes with an expected-head update under the task’s publication guard.

def integrate(repo, task, receipt, contract, max_attempts):
    for attempt in range(max_attempts):
        head = repo.read_ref(TARGET)                          # h_head for this attempt
        stale = changed_dependencies(receipt.dependencies_ref, receipt.base_ref, head)
        if stale:
            return request_revision(task, stale, head)        # regenerate, then return
        if head == receipt.base_ref:
            candidate = receipt.candidate_ref                 # fast-forward case
        else:
            candidate = stage_merge(head, receipt.candidate_ref)
            if candidate is None:
                return request_reconciliation(task, head)     # another proposal
        evidence = run_protected_checks(contract, candidate)  # binds this exact candidate
        if not evidence.accepted:
            return reject(task, candidate, evidence)
        with publication_guard(task) as guard:                # cancellation, grants, lineage
            if not guard.eligible:
                return withdrawn(task)
            outcome = repo.update_ref(TARGET, candidate, expected=head)
        if outcome.uncertain:
            return reconcile_publication(task, candidate)     # never blind-retry the effect
        if outcome.applied:
            return published(task, candidate, evidence)
        # head moved: loop back to dependency validation for the new head
    return unresolved(task, reason="integration_attempts_exhausted")

Figure 3: **Private Workspaces and Guarded Publication**: Linked worktrees (a) give each worker its own files, index, and HEAD while sharing repository storage; the sandbox around each one, not the worktree, scopes its writes. The caller edits files the interface change never touched (b), so the staged merge is textually clean even though the caller relies on the interface as of $\WorkerBaseCommitHash$. Publication (c) therefore revalidates dependencies at the captured head, checks the exact integration candidate, and advances the target only if the head is unchanged and the publication guard holds. A moved head returns the attempt to validation, and every other exit returns an explicit status.

Table 4: A Clean Merge with a Stale Dependency: Publication requires current dependency support and exact-candidate evidence, even when the workers edit different files.

Integration boundary	Evidence available	Required decision
Both workers start at `repo_base_01`	Caller depends on the original interface	Keep each candidate private
Interface change becomes `repo_head_02`	Caller writes are separate, but its interface dependency changed	Revalidate or regenerate affected caller work
Revised caller candidate passes required checks	Results identify the exact combined candidate and checked inputs	Attempt guarded publication against `repo_head_02`
Head changes before publication	Candidate evidence was established for the earlier integration attempt	Return to validation; do not overwrite the intervening change

Repeated invalidations quickly erode the efficiency gains of parallel delegation. If several agents continuously update overlapping dependencies, workers spend more compute discarding stale rollouts and reconciling candidates than generating productive code. Runtimes mitigate this through bounded retries, exponential backoff, and serialized commit queues, transitioning exhausted attempts into explicitly unresolved task states. However, when invalidation rates remain persistently high, the architectural remedy lies in work decomposition rather than concurrency tuning. Structuring the task graph to sequence interface migrations ahead of dependent caller tasks eliminates the cross-worker hazard entirely, achieving higher net throughput with fewer wasted agent turns.

18.5.3 Leases for external resources

Repository staging isolates and buffers only local repository state. A failed Git integration rolls back local commits, but it cannot undo mutations already executed on shared relational databases, physical test rigs, or external payment gateways. External resources operate under their own conditional-update and ownership semantics.

When managing unmergeable stateful resources (a live database migration lock, a dedicated test bench, or an embedded hardware debugger), the runtime must decide precisely when to enforce mutual exclusion. A pessimistic lease acquires an exclusive, time-bounded grant before an agent begins work, and the coordinator reclaims an expired grant so that a stalled holder cannot keep the resource indefinitely. Conflicting workers block until the lease holder releases the lock or times out, avoiding conflict-driven discarded work while the lease remains valid, but agent concurrency collapses into serialized execution. Conversely, optimistic control maximizes parallel execution by deferring conflict checks until publication. If validation fails, however, the runtime discards the entire execution trajectory, while any external side effects already dispatched to outside systems remain irreversible. This irreversibility governs the architectural division: optimistic concurrency control excels for private, discardable working trees, whereas the non-mergeable exclusive resources considered here require exclusion established at the target resource before issuing commands. Table 5 compares these operational strategies.

↩︎ Leases, the split-brain they permit when a stalled worker outlives its grant, and epoch fencing at the destination resource are established in Operation identity and endpoint contracts.

Table 5: Where Exclusion Is Established: Leases pay in waiting before the work; optimistic control pays in discarded or reconciled work afterward, which only private candidates can afford.

Control	Exclusion established	Cost of a conflict	Parallelism	Fits	Residual hazard
Pessimistic lease with fencing	Before acting, at the resource	Waiting; avoids conflict-driven discard	Serialized per resource	Non-mergeable resources and external effects	Stalled holders; expiry needs a resource-side fence
Optimistic validation at publication	At publication, against the captured head	Discarded trajectory and repeated checks	Workers proceed concurrently	Private, discardable candidates	Repeated invalidation under contention
Optimistic validation with reconciliation	At publication, followed by a bounded merge task	Reconciliation work and a new check	Concurrent, plus the reconciliation work	Coupled changes that usually compose	A reconciled candidate is another proposal that needs full validation

An agent stalled by rate limits or slow inference can outlive its lease without noticing, so each leased resource needs the resource-side fencing token of Availability and ownership, which rejects writes stamped with an older lease generation. A duplicate of the same operation from the current holder remains a separate obligation, settled through its operation identity under settlement before retry (principle 8). Delegation adds one case to this mechanism. The stalled holder and the worker that replaces it are often siblings under one supervisor, and a restart under the policies of section 18.3.4 creates exactly such a replacement. The supervisor therefore must not let the new attempt act on the resource until the new lease generation is installed there, and until that fence is in place the runtime verifies lease validity before dispatching each command.

↪ A delayed writer, traced before and after its replacement’s fencing token is installed, is developed in Leases and Fencing.

Guarded publication provides a robust concurrency framework for serializing concurrent state transitions. Its scope, however, is limited to structural and dependency consistency; OCC does not establish semantic correctness. If multiple workers inherit the same flawed assumptions from a shared planner, each worker can satisfy every step of the guarded publication protocol and cleanly commit a flawed patch to the repository.

18.6 Correlated Ensemble Failures

Consider an automated refactoring pipeline where five model reviewers evaluate a caller patch. All five reviewers may endorse the patch because they share the mistaken assumption that the legacy interface remains available. They accumulate approvals without ever verifying the underlying dependency. This synchronized breakdown illustrates a correlated failure, in which the reviewers fail on the same inputs. When individual agents share systemic blind spots, consensus among them is informative only up to the limits of their joint error distribution.

18.6.1 Shared difficulty and conditional independence

Two classical foundations in fault tolerance appear to promise the opposite. Condorcet’s jury theorem (Condorcet, Marquis de 1785) states that if independent voters are each correct with probability above one half, the probability that a majority vote is correct approaches one as voters are added. In computer engineering, N-modular redundancy applies the identical arithmetic to hardware, masking a faulty replica through majority voting circuits (Neumann 1956). Both guarantees rest on an essential premise: that individual voters or components fail independently given the ground truth. Software engineering discovered during the 1980s that this premise breaks down in practice. Independently developed program versions failed on identical inputs far more frequently than statistical independence predicted⁷ (Knight and Leveson 1986). Table 6 contrasts the physical roots of independence in hardware redundancy with the fragile assumptions underlying model reviewer ensembles.

⁷ N-Version Programming: N-version programming builds several distinct implementations of a software specification and votes on their runtime outputs. Knight and Leveson had twenty-seven versions written independently across two universities and evaluated each against one million test inputs; although individual versions achieved high reliability, inputs on which several failed together were far more common than independence allowed (Knight and Leveson 1986). Language models trained on overlapping web-scale data face this exact vulnerability: benchmark evaluations across hundreds of models show heavily correlated errors, with the strongest correlation appearing among the largest and most capable models (Kim et al. 2025).

Knight, John C., and Nancy G. Leveson. 1986. “An Experimental Evaluation of the Assumption of Independence in Multiversion Programming.” IEEE Transactions on Software Engineering SE-12 (1): 96–109. https://doi.org/10.1109/TSE.1986.6312924.

Kim, Elliot, Avi Garg, Kenny Peng, and Nikhil Garg. 2025. “Correlated Errors in Large Language Models.” International Conference on Machine Learning (ICML).

Table 6: Redundancy with and without Independent Faults: Majority voting inherits its guarantee from independent failures, an assumption that must be justified for both replicated hardware and model reviewers.

Question	Replicated hardware under majority vote	Model reviewers under majority vote
Source of independence	Physically separate faults such as particle strikes and wear	Must be established; shared training, prompts, and inputs can correlate errors
What a replica checks	The same deterministic computation	A judgment about a candidate whose difficulty is shared by every reviewer
What adding voters buys	Majority error falls rapidly when faults are independent	Gain depends on the joint error model and may level off at a floor

To quantify how correlation degrades redundancy, consider a binary review process evaluating candidate artifacts known to violate an acceptance criterion. Let $\ReviewerFalseApprovalIndicator_j=1$ denote the event where reviewer $\ReviewerIndex$ erroneously approves an invalid candidate, with marginal false-approval probability $\MarginalFalseApprovalProbability$ over this candidate population. If an ensemble of $\WorkerCount$ reviewers makes independent errors with identical probability $\MarginalFalseApprovalProbability$, their total number of false approvals $\FalseApprovalCount$ follows a binomial distribution. For an odd ensemble size $\WorkerCount$, a faulty majority forms with probability

\[ \Pr(\FalseApprovalCount>\WorkerCount/2)=\sum_{k=(\WorkerCount+1)/2}^{\WorkerCount}\binom{\WorkerCount}{\FalseApprovalOutcomeCount}\MarginalFalseApprovalProbability^\FalseApprovalOutcomeCount(1-\MarginalFalseApprovalProbability)^{\WorkerCount-\FalseApprovalOutcomeCount}. \]

Statistical independence must always be stated relative to the information held fixed. Repeated, independently sampled calls to a single model on one fixed input prompt can be conditionally independent. However, candidate defects vary widely in real workloads: some bugs are subtle and intricate, whereas others are straightforward. A challenging candidate is difficult for every reviewer. Across the broader candidate population, individual reviewer errors become positively correlated. Furthermore, multi-agent debate protocols introduce an intentional communication channel where agents revise their answers after inspecting peer conclusions (Du et al. 2023). This deliberate coupling introduces a secondary layer of dependence on top of shared task difficulty.

A latent-propensity model makes this shared difficulty explicit. Eckhardt and Lee originally introduced this framework to explain coincident software failures (Eckhardt and Lee 1985), assigning each candidate input an intrinsic propensity $\FalseApprovalPropensity \in [0, 1]$ of causing a randomly chosen version to fail. In an agent review setting, draw a candidate with false-approval propensity $\FalseApprovalPropensity$. Conditional on $\FalseApprovalPropensity$, each reviewer independently issues an erroneous approval with probability $\FalseApprovalPropensity$. Reviewers share the candidate’s intrinsic difficulty, even though their individual sampling realizations remain independent. Averaging across the candidate population yields the marginal false-approval rate $\MarginalFalseApprovalProbability$, the pairwise covariance, and the correlation coefficient $\CorrelationCoefficient$:

\[ \MarginalFalseApprovalProbability=\mathbb{E}[\FalseApprovalPropensity],\qquad \operatorname{Cov}(\ReviewerFalseApprovalIndicator_i,\ReviewerFalseApprovalIndicator_j)=\operatorname{Var}(\FalseApprovalPropensity),\qquad \CorrelationCoefficient=\frac{\operatorname{Var}(\FalseApprovalPropensity)}{\MarginalFalseApprovalProbability(1-\MarginalFalseApprovalProbability)}\quad(\PeerReviewerIndex\ne \ReviewerIndex). \]

To model this variation analytically, assume $\FalseApprovalPropensity\sim\operatorname{Beta}(\PropensityPriorApprovalShape,\PropensityPriorRejectionShape)$, a flexible density on $[0,1]$ with positive shape parameters $\PropensityPriorApprovalShape$ and $\PropensityPriorRejectionShape$. Its mean is $\PropensityPriorApprovalShape/(\PropensityPriorApprovalShape+\PropensityPriorRejectionShape)$, and for reviewers who share $\FalseApprovalPropensity$ the pairwise correlation works out to $1/(\PropensityPriorApprovalShape+\PropensityPriorRejectionShape+1)$, so a small $\PropensityPriorApprovalShape+\PropensityPriorRejectionShape$ means candidates differ widely in difficulty and errors correlate strongly. Setting the mean to the marginal rate and the correlation to the target gives $\PropensityPriorApprovalShape+\PropensityPriorRejectionShape=\CorrelationCoefficient^{-1}-1$, which implies $\PropensityPriorApprovalShape=\MarginalFalseApprovalProbability(\CorrelationCoefficient^{-1}-1)$ and $\PropensityPriorRejectionShape=(1-\MarginalFalseApprovalProbability)(\CorrelationCoefficient^{-1}-1)$ for $0<\MarginalFalseApprovalProbability<1$ and $0<\CorrelationCoefficient<1$. Compounding the conditional binomial distribution over this beta prior yields the beta-binomial probability for $\FalseApprovalOutcomeCount$ false approvals:

\[ \Pr(\FalseApprovalCount=\FalseApprovalOutcomeCount)=\binom{\WorkerCount}{\FalseApprovalOutcomeCount}\frac{\mathrm{B}(\FalseApprovalOutcomeCount+\PropensityPriorApprovalShape,\WorkerCount-\FalseApprovalOutcomeCount+\PropensityPriorRejectionShape)}{\mathrm{B}(\PropensityPriorApprovalShape,\PropensityPriorRejectionShape)}, \]

where $\mathrm{B}$ denotes the beta function. A stipulated marginal error rate and pairwise correlation do not uniquely determine the full joint distribution, and the beta family represents an idealized model for shared difficulty. Consequently, any production deployment must empirically measure its joint error distribution directly on domain-specific candidates.

↪ The derivation of the beta-binomial false-approval count from the latent-propensity model is developed in Correlated failures in multi-agent quorum voting.

Napkin Math 18.4: What the joint error model changes

Problem: Five reviewers assess known-invalid candidates, each with marginal false-approval probability $\MarginalFalseApprovalProbability=0.20$. How often does a majority falsely approve if their errors are independent, and how often under the beta mixture at $\CorrelationCoefficient=0.40$?

Math: Summing the binomial masses for three or more false approvals gives 5.79 percent under independent errors. The beta-binomial masses with $\PropensityPriorApprovalShape=\MarginalFalseApprovalProbability(\CorrelationCoefficient^{-1}-1)$ and $\PropensityPriorRejectionShape=(1-\MarginalFalseApprovalProbability)(\CorrelationCoefficient^{-1}-1)$ give 16.68 percent. Unanimous false approval changes from 0.032 percent to 3.92 percent.

Systems insight: At the same marginal error rate, positive correlation erases most of the reliability gains expected from voting. The mixture’s majority improves only slightly on a single reviewer’s marginal rate $\MarginalFalseApprovalProbability$, and a unanimous false approval is about 122 times as likely as independence predicts. Before adding reviewers to an ensemble, estimate $\CorrelationCoefficient$ empirically on known-invalid candidates. When correlation is high, spending additional token budget on more reviewers of the same type yields diminishing returns; that budget is far better spent on independent, deterministic validation checks. These calculations condition on the candidate being invalid; the overall probability that an approved candidate is invalid also depends on the prevalence of invalid candidates in the workload.

The mixture model also bounds what ensemble scaling can achieve. Conditional on a candidate’s propensity $\FalseApprovalPropensity$, the weak law of large numbers implies that the fraction of reviewers falsely approving converges to $\FalseApprovalPropensity$ as the ensemble grows. Consequently, an arbitrarily large majority vote falsely approves precisely those candidates with $\FalseApprovalPropensity>1/2$. Rather than decaying toward zero, majority false approval approaches a nonzero asymptotic floor at $\Pr(\FalseApprovalPropensity>1/2)$.

Under the parameters modeled in the notebook, that floor is 15.0 percent. At 15 reviewers, independent errors would reduce majority false approvals to 0.42 percent, whereas the beta mixture leaves the error rate stalled at 15.6 percent. In figure 4 the independent curve keeps falling toward zero while the mixture curve flattens just above the floor, and at five reviewers the mixture moves probability to the extremes, so a candidate is approved by no one or by a majority far more often than independence predicts. Tripling the committee from five to 15 reviewers of the same kind triples review spend yet lowers majority false approval only from 16.68 percent to 15.6 percent, because the remaining errors concentrate on candidates that every such model finds difficult.

Figure 4: **Majority Review Under an Assumed Error Mixture**: Every reviewer has the same false-approval rate, $\MarginalFalseApprovalProbability=0.20$. With independent errors (a), majority false approval at five reviewers (open markers) is 5.79 percent and keeps falling as reviewers are added. Under the beta mixture with $\CorrelationCoefficient=0.40$ it is 16.68 percent and levels off toward the floor $\Pr(\FalseApprovalPropensity>1/2)$ of 15.0 percent. At five reviewers (b), the mixture shifts probability toward the extremes, so a candidate is either approved by no one or approved by a majority far more often than independence predicts. The curves follow from an assumed beta mixture, not a measured law of model ensembles.

18.6.2 Evidence at the integration boundary

In an automated workflow such as migration_task_01, five reviewers that all repeat the assumption that the old interface remains available provide essentially a single effective observation. Their consensus should not trigger an automatic merge; instead, it should trigger an end-to-end integration check that evaluates the modified caller alongside the updated callee interface. A protected, deterministic check supplies ground-truth evidence that model reviewers cannot fabricate. A compiler establishes whether the candidate compiles cleanly under the target configuration, and a regression test suite confirms that specified functional behaviors remain intact. If an untrusted worker agent modifies a test suite to bypass a signature verification check, the test may pass while completely failing to validate the security property. This vulnerability is why authoritative evaluation suites must remain isolated behind a protected grading boundary. Even so, deterministic validation remains bounded by test suite coverage gaps and flawed formal specifications.

Classical distributed quorum protocols cannot rescue a review ensemble plagued by correlated errors. When a large language model (LLM) outputs well-formed, plausible, yet incorrect evidence, it produces a fail-plausible fault rather than a fail-stop crash. In the unsigned-message protocol model, Byzantine agreement guarantees consensus despite arbitrary faults only while faulty participants remain strictly below one third of the ensemble⁸ (Lamport et al. 1982). Because reviewers that share training distributions, system prompts, or upstream reasoning summaries fail together, correlated errors can push the faulty fraction past that one-third threshold regardless of replica count. Requiring each reviewer to inspect primary evidence before viewing peer conclusions (information isolation) removes direct peer influence, whereas distinct model architectures, diversified prompts, and separate evidence sources lower $\CorrelationCoefficient$ only as far as empirical measurement on known-invalid candidates demonstrates.

⁸ Byzantine Bound: The replica bound fixes how large a faulty fraction a protocol tolerates, not why replicas fail; the one-third limit applies to unsigned messages, and digital signatures relax it (Lamport et al. 1982). Classical deployments seek to keep simultaneous faults below that bound through physical diversity, running distinct code bases on separate hardware in different administrative domains. Model reviewers drawn from common model families, or trained on overlapping web-scale data, lack that isolation by default.

Lamport, Leslie, Robert Shostak, and Marshall Pease. 1982. “The Byzantine Generals Problem.” ACM Transactions on Programming Languages and Systems 4 (3): 382–401. https://doi.org/10.1145/357172.357176.

↩︎ The fail-plausible fault, output that is well formed and plausible yet wrong, is established in The fail-plausible fault.

Consensus among worker agents must never be confused with authoritative execution privilege. Reviewer agreement provides an informative heuristic signal within the bounds defined by an orchestration workflow, but granting authority to merge code, publish artifacts, broaden task scopes, or bypass gate checks requires explicit capability grants issued by a privileged control plane. Even unanimous approval from the five reviewers in migration_task_01 only advances the candidate to the integration gate, where the runtime still checks its scope, dependencies, and publication grant before updating the branch.

Checkpoint 18.2: Interpreting concurrent results and agreement

Clean merge vs. valid change: Why do disjoint write paths leave the caller patch unvalidated after an interface change, and which record lets the integration service decide?
Collision estimate: A repository has 2,000 files and each worker writes 10. Using equation 4, roughly how many workers make a shared write more likely than not? Should the runtime isolate workers at that size?
Reviewer budget: Majority false approval is 16.68 percent at five reviewers and levels off near 15.0 percent. Should the system provision ten more reviewers of the same kind, or one protected test, and why?
Approval vs. authority: Distinguish a worker’s approval, a scoped protected-test result, and permission to publish the candidate.

Validation evidence also carries a finite lifetime while asynchronous workers execute in parallel. If an upstream orchestrator rejects an intermediate candidate patch or alters its task plan, downstream worker agents may continue computing on stale state. Robust agent runtimes must invalidate and reject superseded work while properly terminating and accounting for in-flight child processes.

18.7 Bounding In-Flight Work

Suppose the supervisor cancels migration_task_01 while worker_interface_01 awaits an external test job and worker_caller_01 finishes generating a candidate patch. Even if the caller’s patch passes its local validation checks after the supervisor initiates cancellation, the runtime must ensure that the patch remains strictly unpublishable. Meanwhile, an external testing service may have already accepted the interface worker’s test request, incurring resource and billing charges that remain unsettled long after the worker process halts. In single-agent execution, a cancellation signal simply interrupts a local loop or an outstanding remote inference call. In a multi-agent system, that control boundary must span an entire hierarchy of distributed descendants.

↩︎ Pause and cancellation of a single trajectory, applied at turn boundaries and by streaming cancellation, are established in Control Actions.

To enforce cancellation across a fleet of workers, the runtime records the affected subtree, its current control generation, and the rationale for stopping. Authoritative dispatch and publication gates consult this record along the serialized path that admits new work. In distributed agent systems, closing admission, terminating execution, and releasing resources are three distinct milestones, each demanding its own independent evidence. Everything admitted before the cancellation stays under the settlement rule of failure recovery, now applied across the entire subtree. An operation admitted before the stop preserves its identity, execution status, and assigned owner until its outcome and associated financial charges settle. No cancellation signal, authorization revocation, timeout, or queue purge can retroactively erase that obligation.

↩︎ The settlement rule, which keeps an operation’s reservation and record until evidence establishes its outcome, is established in Effects Outside a Shared Transaction.

18.7.1 Cancellation context trees

When a parent task is canceled, a grandchild worker that has not yet received the stop signal can keep calling tools and publishing results under the parent’s delegated authority. The cancellation context tree prevents that leak without introducing a fourth graph structure. It is the supervision tree of section 18.3.4 seen from the control plane, with the same parent-child ownership edges, each annotated with the control generation of the ancestor that governs the child, and a child’s delegation lineage is simply its path from that tree’s root. To determine cancellation scope, the runtime traces this lineage rather than data-dependency edges. Authority, resource budgets, and execution mandates flow through delegation; when an ancestor task is revoked, every descendant executing under its delegated authority loses eligibility to run or publish results. Once the runtime establishes the cancellation scope along this delegation tree, it invalidates any downstream continuation whose upstream prerequisites are no longer eligible. Conversely, when a task contract permits optional speculative branches, a failed or canceled optional child leaves unrelated sibling work running undisturbed.

Definition 18.3: Hierarchical cancellation context tree

Hierarchical cancellation context tree is a runtime-owned delegation structure that links each child to the ancestor control decisions governing its continued execution and result publication.

Significance: It identifies which descendants must lose eligibility when an ancestor stops and which outstanding operations still need an owner.
Distinction: Propagating a stop request changes control policy; confirming remote termination, resource release, and effect settlement requires separate evidence.
Common pitfall: Treating a canceled parent record as proof that every child, external job, and charge has ended.

The ordering of events at each admission and publication gate dictates the precise boundary of cancellation. Suppose an admission gateway accepts worker_interface_01’s test operation, logs its unique operation identity along with its resource reservation, and begins transmitting the request. If the parent task cancels before a reply arrives, that test operation remains admitted and must proceed through the settlement protocol. However, any subsequent request from either child that arrives at that gateway after the cancellation decision is serialized will be rejected immediately. Result publication follows the exact same linear order. The integration path must re-verify task eligibility at the atomic publication boundary: if the cancellation commits first, it blocks publication of any patch, regardless of whether that patch passed every local check. If publication commits before the cancellation is serialized at the boundary, the resulting state change stands as a durable modification that the recovery contract must handle.

Under this architecture, a supervisor can authoritatively report that its gateways deny new work and reject publications without falsely claiming that a disconnected or remote worker process has already halted. A remote enforcement gateway that loses connectivity to the central control plane must fail closed. If a gateway instead relies on cached authorization tokens, it operates under an explicit stale-authorization window and cannot guarantee immediate, subtree-wide revocation (section 18.8).

18.7.2 Evidence preservation during cleanup

Terminating a distributed agent task reveals an asymmetry common to distributed systems. Closing a local client stream does not confirm that a remote model provider has ceased generation, and killing a local worker process leaves requests accepted by external services in flight. The runtime must therefore dispatch explicit stop requests to each reachable execution service, with each acknowledgment certifying only its specific operational scope (table 7); an executor’s process-level or infrastructure confirmation always outranks an agent’s self-reported claim that it has halted.

Table 7: Evidence at cancellation boundaries: Each acknowledgment supports a scoped claim rather than certifying that the whole subtree has disappeared.

Evidence	What it establishes	What remains separate
Authoritative admission hold	Later model/tool admissions and candidate publication are denied at the covered gates	Previously admitted work and disconnected enforcement points
Executor confirms worker termination	The identified execution scope has stopped under that executor’s contract	Remote jobs, external effects, and final usage
Provider confirms an operation’s outcome	The identified operation has the reported effect status	Other attempts, cleanup operations, and unresolved charges
Resource owner confirms release	The identified slot, sandbox, or allocation is available again	Retention of required evidence and settlement of other obligations

For an outstanding test request, the runtime retains the operation identity, execution attempt history, resource reservation, and external job handle while actively reconciling status. If the external test service eventually delivers a late result, that response can settle the operation’s outcome and finalize its billing without reactivating the canceled task trajectory. If the external outcome remains indeterminate, the runtime transfers the operation to a designated settlement owner. The execution receipt preserves these audit records through runtime.settlement_ref, ensuring they survive any context-window summarization or lineage compaction.

Cleanup operations cannot execute under the revoked worker’s authority; the runtime must provision a separately scoped administrative credential and a protected resource allowance. Furthermore, tearing down an allocated environment is itself an asynchronous operation with an uncertain outcome. Scratch workspace or container deletion must block until all relevant filesystem writers have terminated and required diagnostic artifacts have been safely archived. An asynchronous background sweeper reconciles registered physical allocations against these pending evidentiary obligations before unlinking directories or recycling sandbox containers.

↩︎ The cleanup graph that orders this teardown is established in The cleanup graph.

18.7.3 Hedged requests and speculative work

Waiting for every worker drops on-time odds below half by seven workers.

Beyond handling failures and user aborts, cancellation is a primitive for speculative execution and latency management. When an agent workflow fans out across multiple subtasks, waiting for every parallel worker exposes the entire system to stragglers, the tail-at-scale problem (Dean and Barroso 2013). Consider $\WorkerCount$ parallel workers with independent and identically distributed completion times $\WorkerCompletionTime_i$ required to produce an admissible result. If $\WorkerCompletionDistribution(\TimeInstant)=\Pr(\WorkerCompletionTime_i\le \TimeInstant)$ represents the cumulative probability of a single worker finishing within time $\TimeInstant$, an all-results barrier, which requires every worker to complete, achieves a deadline completion probability of

\[\Pr\bigl(\max_i \WorkerCompletionTime_i\le \TimeInstant\bigr)=\WorkerCompletionDistribution(\TimeInstant)^{\WorkerCount}.\]

Because the barrier needs every worker’s admissible result, each added worker multiplies the deadline probability by another factor $\WorkerCompletionDistribution(\TimeInstant)<1$, so it decays geometrically as the fan-out $\WorkerCount$ grows, the same geometric decay that horizon compounding (equation 1.1) applies across turns, now applied across workers. In production systems, correlated queueing delays, shared rate limits, and unequal prompt lengths break the idealized independent model, so deadline probabilities must be measured under the shared serving conditions. However, if the task contract permits any $\RequiredResultCount$ interchangeable admissible results out of $\WorkerCount$ replicas, the probability of meeting the deadline becomes

\[\Pr(\WorkerCompletionTime_{(k)}\le \TimeInstant)=\sum_{j=k}^{\WorkerCount}\binom{\WorkerCount}{\FinishedWorkerCount} \WorkerCompletionDistribution(\TimeInstant)^\FinishedWorkerCount[1-\WorkerCompletionDistribution(\TimeInstant)]^{\WorkerCount-\FinishedWorkerCount},\]

where $\WorkerCompletionTime_{(k)}$ denotes the arrival time of the $\RequiredResultCount$th admissible result. This $\RequiredResultCount$-of-$\WorkerCount$ stopping rule applies strictly to interchangeable outputs, such as parallel candidate retrieval or redundant reasoning paths. In the migration scenario, by contrast, the system requires both the interface update and the caller refactor; no majority of completed caller patches can stand in for a missing interface patch.

Napkin Math 18.5: A completion contract changes the barrier

Problem: A hypothetical read-only analysis task permits any 6 interchangeable admissible results from 8 workers. Each worker independently has a 90 percent probability of returning such a result within 10 s of dispatch, including its checks. What is the probability of having sufficient results by that deadline, compared with waiting for every worker?

Math: Requiring every result gives $\WorkerCompletionDistribution(\TimeInstant)^{\WorkerCount}$, or 43.05 percent. Summing the binomial probabilities for 6 through 8 completions gives 96.19 percent.

Systems insight: An all-results barrier multiplies the deadline probability by $\WorkerCompletionDistribution(\TimeInstant)$ for every worker added; at this per-worker rate it drops below even odds at just 7 workers. Where the contract permits interchangeable results, a $\RequiredResultCount$-of-$\WorkerCount$ stopping rule recovers most of the lost probability. Where it does not, the fan-out itself must shrink or the per-worker tail must be cut. The workers still running after the rule fires consume resources until cancellation takes effect, and that work belongs in the cost account.

Hedging⁹ mitigates tail latency by dispatching a redundant replacement attempt after a specified delay while the original worker continues running, subsequently accepting whichever admissible result completes first (Dean and Barroso 2013). Hedging functions smoothly for read-only analyses and sandboxed candidate patches where a single runtime publication gate arbitrates the winner and cancels redundant runners. However, speculative hedging introduces acute hazards if an agent executes external mutating actions. Unless the destination service implements a strict duplicate-effect or idempotency contract, a trailing or canceled worker can execute irreversible side effects before its cancellation signal is processed. A hedge of a mutating action is a retry issued before the first attempt has settled, which settlement before retry (principle 8) forbids unless both attempts carry one operation identity that the endpoint deduplicates. Furthermore, speculative attempts consume real token allowances and concurrency slots; dispatching hedges into a congested inference cluster amplifies queue depth and prolongs the very tail latencies the mechanism was intended to truncate.

⁹ Hedged Requests: Dean and Barroso’s recipe defers the second request until the first has been outstanding longer than the 95th-percentile expected latency, which bounds the extra load to roughly the fraction of requests that are that slow. For agents the delay matters more than for storage reads, because each hedge is a full model trajectory with its own reservation, and a hedge issued too early doubles spend on the common case to shorten the rare one.

Dean, Jeffrey, and Luiz André Barroso. 2013. “The Tail at Scale.” Communications of the ACM 56 (2): 74–80.

↩︎ Uncertain outcomes and the endpoint deduplication contracts that make a repeated mutation safe are established in Retrying Uncertain Actions.

18.7.4 Credit-based flow control

Even when every child agent stays within its own token budget, a rate mismatch between stages of a pipeline can still destabilize the workflow. A fast producer that emits candidate changes faster than a downstream reviewer or test runner can drain them fills the queue between the two stages. As that backlog grows, candidates wait longer before inspection, so the repository state they were built against moves underneath them while they sit in line.

Consider an upstream agent that lists files and emits candidate diffs at $\ArrivalRate =$ 5 items per second. A downstream reviewer model generates a 500-token critique for each item at a decode speed of 40 tokens per second, yielding an effective service rate of only $\ServiceRate =$ 0.08 items per second. In an unconstrained queue, the backlog expands at the net rate $\ArrivalRate - \ServiceRate$. After 10 minutes, the queue accumulates 2,952 unreviewed items, and a newly submitted diff faces an estimated queue wait of 10.2 hours. Long before process memory is exhausted, the queued items become obsolete, because the repository state they reference has diverged, reproducing between agents the stale-observation failure that context invalidation guards against inside one trajectory. Per-agent token budgets fail to prevent this collapse because each individual candidate item is inexpensive to generate.

↩︎ Context invalidation, which withdraws observations that a later change has made stale, is established in Context Invalidation.

A finite credit window prevents this divergence by bounding the number of admitted, in-flight items, much as an aggregate budget caps token expenditure; it is the same mechanism that bounds staged records in trajectory collection. A producer transmits only while it holds a credit the consumer issued for free capacity, so congestion delays the producer but never overflows a buffer. Let $\CreditWindowCapacity$ denote the fixed credit capacity of the channel, $\FreeCreditCount$ the unallocated credits held by the producer, and $\OutstandingItemCount$ the outstanding admitted items currently circulating in the pipeline. The runtime enforces the structural invariant:

\[\FreeCreditCount+\OutstandingItemCount=\CreditWindowCapacity,\qquad \FreeCreditCount\ge0,\quad \OutstandingItemCount\ge0.\]

↩︎ Collection credits, which bound staged trajectories between generation and verification, are established in Collection credits and staging reserves.

Under this discipline, admitting a new work item requires the producer to acquire and attach an available credit. That credit remains tied to the item while it traverses the network, waits in downstream queues, undergoes evaluation, or reserves output buffer space. The runtime returns the credit to the producer’s pool only when the item reaches a designated capacity-release boundary. Credit returns are processed atomically and with at-most-once semantics. A lost return silently shrinks the window, and a duplicated one inflates it, so network disconnections trigger a recount of outstanding credits against the authoritative runtime state rather than granting producers a fresh batch of credits.

Beyond protecting buffer memory, credit windows provide a sizing model for mean residence at a sustained service rate. Little’s law (theorem 5.1, equation 5.7) states that the mean number of items held equals their admitted rate times their mean residence. Applying it to a saturated window takes one mapping. The items held are the outstanding ones, $\OutstandingItemCount=\CreditWindowCapacity$. The window admits a new item only when the consumer drains one, so the admitted rate is the drain rate $\ServiceRate$, not the producer’s offered rate $\ArrivalRate$. Dividing the items held by the admitted rate gives a mean residence of $\CreditWindowCapacity/\ServiceRate$. With a window of $\CreditWindowCapacity =$ 8 credits in the pipeline above, a diff that would have waited 10.2 hours behind the unbounded backlog instead resides in the window for 100 seconds on average. A hard freshness requirement additionally needs admission timestamps, deadline checks before service, and bounded service times if timely service must be guaranteed. When credits are exhausted, the producer yields execution instead of flooding the pipeline with artifacts destined to be obsolete upon inspection. Furthermore, if each in-flight payload is constrained to at most $\DataVolume$ bytes, total memory occupancy cannot exceed $\CreditWindowCapacity\DataVolume$. This demonstrates why payload return bounds (section 18.4) serve as crucial admission-control parameters rather than mere prompt formatting conventions.

Exhausting data credits, however, must never starve control-plane traffic. Signals such as cancellation commands, credit reconciliation messages, execution status receipts, and financial settlement records travel over reserved out-of-band control channels. The runtime must reject new task admissions whenever doing so would risk exhausting the execution slots reserved for downstream consumers and cleanup handlers; otherwise, upstream producers waiting for credits will block the very consumers needed to release them, deadlocking the system. Finally, releasing a channel credit must not be conflated with releasing an external resource or refunding a financial commitment. Credit reclamation restores pipeline capacity, whereas financial settlement accounts for external cost.

Together, cancellation trees and credit windows bound the volume and financial exposure of in-flight work while keeping control paths responsive, and the credit window sets mean residence under the stated service rate. Neither control, however, decides which operations a child is allowed to propose while it runs. Enforcing those limits across a delegation tree depends on the authority model at each node: what capabilities each descendant holds, how its allowance is reserved, and how fresh its lineage must be when checked at a remote gateway (section 18.8).

18.8 Capability Delegation

Suppose worker_caller_01, an agent authorized only to update selected caller functions, spawns a new child task to inspect upstream source code and designates the root orchestrator as that child’s parent. If the runtime naively resolves authority from the client-supplied parent identifier, the inspection child inherits the root’s global authority, including publication credentials intended exclusively for the release integration service. The delegation tree (the supervision tree’s parent-child edges, along which grants now flow) has itself manufactured a confused deputy (definition 7.3). The runtime resolved authority from a name the requester supplied, the parent identifier that the child chose for itself. Similarly, two sibling workers dispatched concurrently might both observe the parent’s uncommitted budget before either issues an external call, overdrawing the task’s shared financial or token allowance. Task cancellation exposes a matching temporal hazard: a descendant grant that was perfectly valid when minted must admit no further work once the runtime revokes an ancestor in its lineage.

Scoped grants and credential brokering establish where authority resides within isolated execution environments. Multi-agent architectures extend this foundation through attenuated delegation: every hop down the task hierarchy passes authority no broader than the delegator’s existing authority. This model enforces the principle of least privilege (Saltzer and Schroeder 1975) with capabilities (definition 8.2), so the authority travels in the reference a child holds rather than being looked up from the identity it claims, and confinement survives concurrent spending and ancestor state transitions. While a model may propose spawning a child task and suggest its scope, the runtime supervisor alone assigns the child’s identity, issues its attenuated grant, commits its resource reservation, and binds its lifecycle.

Saltzer, J. H., and M. D. Schroeder. 1975. “The Protection of Information in Computer Systems.” Proceedings of the IEEE 63 (9): 1278–308. https://doi.org/10.1109/proc.1975.9939.

18.8.1 Attenuated grants and split allowances

Passing a parent’s full credential or unreserved budget balance to a child lets a single compromised subtask modify unrelated files or spend the entire task allowance. To keep each hop narrower than the one above it, a delegation tree applies the containment relation $\GrantAllowedAccesses(\ChildCapabilityGrant)\subseteq\GrantAllowedAccesses(\ParentCapabilityGrant)$ established in Narrowing delegated authority at every hop. In a multi-agent tree the relation governs concrete operations executed on underlying system resources, rather than superficial labels such as tool names or directory prefixes that an agent might attempt to manipulate. For example, an inspection child task may hold permission to inspect a specific interface file, but it must possess no rights to modify caller source files, exfiltrate repository data, or access the parent broker’s credentials for external repositories. The execution boundary enforces these perimeter restrictions directly; the child environment starts without inheriting broader host credentials or open file handles.

Runtimes can implement these bindings using either protected internal kernel handles or cryptographically verifiable bearer tokens. Chained-caveat tokens let a holder attenuate its grant locally without contacting an issuer, because each added restriction extends a keyed hash chain that the holder cannot unwind (Birgisson et al. 2014). Because the runtime supervisor, never the generative model, binds the resulting capability to the specific task execution context, a compromised or malfunctioning worker cannot forge a parent lineage or substitute a token belonging to another task.

Permissions and consumable budgets require different delegation rules. Permissions are not depleted by use, so they can be shared: a parent that delegates read access retains its own ability to read. Consumable budgets, by contrast, are depletable resources that must be partitioned rather than duplicated, ensuring that each unit of currency or token quota is spent at most once. The admission control gate must therefore ensure that no unit of budget is created from nothing or spent twice anywhere in the delegation hierarchy. Before dispatching a child task, the runtime atomically reserves the child’s admitted liability against the shared allowance, accounting for all concurrent siblings and the parent’s own outstanding work. This atomic reservation prevents two sibling workers from racing to commit the same remaining balance, and it is the shared-allowance rule of trajectory-level encapsulation (principle 10) applied across a tree, under which concurrent holders reserve against one allowance and a derived allowance only narrows. If a child subsequently subdivides its allowance among its descendants, it creates a nested sub-budget that can never exceed its own allocation, not an independent pool that can be charged separately.

↪ The settlement rules developed in Budget conservation across descendants decide when a delegated allocation’s unspent backing returns to the parent and count a late bill once.

18.8.2 Revocation and lineage checks

In a distributed multi-agent system, revocation cannot depend on promptly delivering push notifications to every running child. A robust architectural pattern assigns each task node in the runtime a monotonic generation counter and an operational state (such as active, canceled, or completed). When a grant is issued, the runtime binds it cryptographically to the complete root-to-holder lineage path, recording the exact generation counter of each ancestor at the moment of delegation. Revoking an ancestor marks that node ineligible or advances its generation counter. Node restarts must monotonically advance or preserve generation counters rather than resetting to zero, which would inadvertently revive expired or revoked grants.

When an agent submits an operation to the API gateway, the admission check verifies the grant’s cryptographic integrity, scope, and expiration while querying the current lifecycle status and generation of every ancestor in the bound lineage path. If any ancestor has been canceled or its generation has advanced, the gateway rejects the descendant’s request immediately, even if the leaf worker has not yet received a cancellation signal and still considers itself active. Traversing a lineage path of depth $\ell$ requires $\mathcal{O}(\ell)$ ancestor lookups at admission time, whereas advancing an ancestor’s generation number invalidates the entire subtree of descendant grants in $\mathcal{O}(1)$ time without rewriting individual token payloads. Gateway caches or indexed summaries can shorten those admission lookups at the cost of cache-invalidation rules, and table 8 traces how the check behaves across migration_task_01 without assuming that cancellation messages arrive everywhere at once.

Table 8: Lineage checks across cancellation: The authority decision depends on current ancestor state and the order of admission, not on whether a child has acknowledged a message.

Situation	What the admission authority knows	Consequence
A worker proposes an operation before cancellation	Bound lineage generations match and ancestor tasks remain active	Continue checking operation scope, resource conditions, expiry, and budget; lineage validity alone does not authorize the operation
The root cancellation is committed before a later admission	The root is ineligible or its generation differs from the grant	Reject the descendant request even if the worker has not received its cancellation message
A remote gateway cannot establish current ancestor state	A cached record may predate cancellation	Withhold admission under the strict freshness policy; do not claim current authorization from the old record
An external operation was admitted before cancellation	Its outcome is still unresolved	Retain operation identity and settlement ownership; rejecting later requests does not undo the earlier effect

Enforcing cancellation semantics requires an unambiguous, linearizable ordering point. Under a strict freshness policy, revocation updates and admission checks share an authoritative global order: once a revocation is committed, no subsequent admission check within that scope may evaluate against stale policy state. Because local signature verification and expiry checks establish only that a grant was valid when issued, a replicated gateway that cannot verify current ancestor state must fail closed, withholding admission from new operations.

Alternatively, systems that prioritize availability over strict consistency may permit distributed gateways to evaluate requests against cached ancestor state for a declared interval. This engineering trade-off introduces a stale-policy window, the bounded interval in which an already-revoked grant may still be accepted by an out-of-date gateway. The system designer must explicitly bound this window to account for cache invalidation propagation, token refresh intervals, clock skew assumptions, and network partition timeouts. Furthermore, revocation must actively sever all mediation pathways, including revoking open writable file handles held by running processes; any operations already admitted to external systems prior to revocation remain governed by transactional settlement rules.

18.8.3 Approval requests and operation binding

During execution, a worker may discover that completing its objective requires an operation that exceeds its delegated authority. Rather than terminating or attempting privilege escalation, the worker submits an authorization request. An approval binds to the exact operation it authorizes, never to a model’s explanation of it (Action-bound approval), and the runtime recomputes that binding and rechecks its preconditions at dispatch (Dispatch-time rechecks). For a delegated publication, the bound operation names the originating task (migration_task_01), the content hash of the candidate artifact, the destination reference, and its base-version preconditions, so a candidate altered by a single byte after approval needs a fresh decision.

Delegation changes where the request goes and what the recheck must cover. The worker cannot widen its own grant, and attenuation forbids its parent from granting more than the parent holds, so the runtime collects such requests in a bounded approval queue, deduplicates repeated submissions from siblings, and routes each to the task owner rather than to an intermediate parent whose own grant could not cover the operation. Any rationale a root or worker model attaches remains unverified commentary. At dispatch, the recheck extends from the operation to its lineage: current grants, every ancestor’s lineage generation, and the remaining budget must still permit the action, so an ancestor cancellation committed after approval blocks it as surely as a changed candidate does. Passing validation tests in migration_accept_v1, obtaining operator approval, and executing the privileged publication remain three distinct, non-fungible events.

Checkpoint 18.3: Bounding work, authority, and spending after a split

Cancellation scope: The supervisor cancels migration_task_01 after the gateway admitted worker_interface_01’s test operation but before its reply arrives. Which statements can the runtime make truthfully now, and which must wait for further evidence?
Barrier vs. quorum: At a per-worker on-time probability of 90 percent, why can a 6-of-8 stopping rule rescue a read-only analysis but not the two-part migration?
Hedging a mutation: Why is a hedged copy of a mutating tool call a retry before settlement, and what must both attempts share before the runtime may issue it?
Credit window: The reviewer drains 0.08 items per second. What window keeps the modeled mean residence under one minute, and which messages must travel outside the data credits?
Joint allowances and revocation: Two siblings each receive less than the parent’s remaining allowance. What must the runtime do so they cannot jointly overdraw it, and what happens at a remote gateway that cannot confirm an ancestor’s current generation?

Delegation controls conserve authority and spending, distinguish cancellation from completed cleanup, and separate administrative approval from verified success. These safeguards make task decomposition governable. Whether splitting a task across multiple agents is actually useful, however, remains a separate empirical question, answerable only by measurement against a strong single-agent baseline.

18.9 Benchmarking Against a Single Agent

A software repair task, such as an authentication migration, can execute under a single agent controller equipped with parallel tool dispatch, or under a multi-agent supervisor coordinating separate workers for interface updates and caller refactoring. If an experimental trial grants parallel tool execution to the supervisor while artificially restricting the single controller to serial execution, the benchmark measures that baseline handicap rather than the true benefit of delegation. A rigorous evaluation begins with an objective declared in advance, such as minimizing cost per accepted task subject to a deadline, or maximizing completed tasks within a fixed operating budget. The coordination tax (principle 14) then appears in three measurements read together: accepted-task rate, elapsed wall-clock time, and cost per accepted task. While a Pareto improvement across all three dimensions is ideal, it is rarely achieved; in practice, delegating work across agents represents an explicit trade of computational cost for lower latency. This trade-off is justified only when the engineering objective values latency reduction and the solution satisfies all quality and budget constraints.

18.9.1 Matched comparison conditions

Comparing a multi-agent fleet against a single-turn prompt or a controller with lower tool concurrency credits delegation for resources the single agent was never allowed to use. A fair evaluation applies the matched-budget comparison established in Matched-budget comparison, which fixes the task distribution, criteria, and resource envelope before policies are compared, against an equally capable baseline: an iterative single controller with parallel tool execution, rather than an isolated, single-turn model call. For delegation, the matched envelope must also fix starting fixtures, evidence access, and identical concurrency limits on both model calls and tool executions. Because either policy may terminate early, unconsumed budget represents an operational outcome rather than an experimental discrepancy. If a delegated design also alters underlying model selections or prompt formulations, the trial evaluates a compound bundle of variables, so isolating the architectural impact of delegation requires a controlled ablation. Finally, acceptance must be scored on the integrated end-to-end task rather than on worker subtasks, because an interface update that passes its local unit tests still fails the migration if the accompanying caller patch introduces breaking signature incompatibilities.

18.9.2 Outcome, latency, and cost metrics

Every attempted task must remain in the evaluation denominator; tasks that encounter timeouts, unhandled errors, or indeterminate verdicts cannot be discarded from the benchmark. When the operational contract treats late delivery as an outage, on-time acceptance must be recorded as a distinct metric alongside gross completion. End-to-end latency spans the full execution envelope, measured continuously from task arrival through task decomposition, sub-agent dispatch, intermediate reconciliation, final integration, and automated assessment. Calculating median latency solely over accepted tasks introduces severe survival bias by filtering out prolonged failures. Systems evaluation therefore tracks latency across all arrivals. A task still running at the observation cutoff is right-censored: its latency is known only to exceed the cutoff, so it enters the latency distribution as a lower bound rather than being dropped, the same refusal to discard unresolved outcomes that keeps pending and unknown verdicts in the evaluation denominator (The four-verdict rule).

Cost accounting must encompass the complete system boundary: supervisor orchestration, retrieval queries, verification suites, merge conflict reconciliation, failed exploratory attempts, canceled speculative branches, and environment cleanup. Token expenditures must distinguish input and output tokens at their respective market prices, while concurrent tool invocations must be billed by aggregate worker execution time, which frequently exceeds the wall-clock span of the critical path. The effective cost per accepted task divides this full cohort spend by the accepted count under the same matched-budget accounting, so an architecture with no accepted solutions still reports its spend and the zero count. The token inflation documented in war story 18.1 illustrates why rigorous cost accounting is essential before committing to a multi-agent deployment.

Napkin Math 18.6: How much acceptance a token multiple must buy

Problem: A delegated multi-agent architecture consumes tokens at the ratios reported for the research system: 15× the token volume of a standard chat interaction, compared to 4× for an autonomous single agent. Assuming a constant price per token, how much must task acceptance improve for delegation to break even on cost per accepted task, and over which baseline success rates is break-even mathematically achievable?

Math: Let $\DelegationTokenMultiple$ be the token multiple, delegated tokens per attempt over single-agent tokens per attempt. Following equation 1.2, with cost proportional to tokens, the delegated cost per accepted task divided by the single-agent cost per accepted task is $\DelegationTokenMultiple\,\SingleAgentAcceptanceProbability/\MultiAgentAcceptanceProbability$. With $\DelegationTokenMultiple=$ 15× $/$ 4× $=$ 3.75×, economic break-even requires that $\MultiAgentAcceptanceProbability =$ 3.75× $\cdot\, \SingleAgentAcceptanceProbability$. Because probability is bounded ($\MultiAgentAcceptanceProbability \le 1$), break-even is possible only when the single-agent baseline achieves $\SingleAgentAcceptanceProbability \le$ 26.7 percent. Even if the reported evaluation score gain of 90.2 percent translated directly into an acceptance rate multiplier of 1.90×, the effective cost per accepted task would remain 2.0× that of the single-agent baseline.

Systems insight: When delegation multiplies token consumption by a factor of $\DelegationTokenMultiple$, it reduces effective cost $\CostPerAcceptedTask$ if and only if it scales task acceptance by more than $\DelegationTokenMultiple$. At an expansion ratio of 3.75×, this economic efficiency can materialize only on difficult tasks where the single agent succeeds less than 26.7 percent of the time. On workloads where a single agent already succeeds reliably, delegation cannot be justified by cost efficiency; it must be justified as a purchase of reduced wall-clock latency or broader search coverage, valued explicitly by the system’s operational requirements.

18.9.3 Scaling models for worker count

Coherency cost turns added workers into lost capacity past the peak.

A matched trial is expensive, so before running one a team must decide which worker counts deserve a trial at all. The fixed-work scaling model of equation 1 does not replace that benchmarking; its role is to guide the search by identifying promising worker counts. Varying the worker count alters resource contention, sub-task dispatch boundaries, and inter-agent reconciliation costs simultaneously. Consequently, any empirical overhead curve holds strictly within the evaluated range and serves as a hypothesis beyond it. To reason about scaling limits systematically, classical systems engineering separates everything that keeps a fleet from ideal division into work that serializes (undivided planning, and any overhead that queues at a single resource) and pairwise reconciliation, two mechanisms that require different architectural remedies.

Theorem 18.1: Universal scalability law

For a fixed amount of work divided among $\WorkerCount$ equally capable workers, Gunther’s universal scalability law (USL) (Gunther 2008) gives the relative capacity, the speedup over one worker, as equation 5, with its peak at equation 6.

\[ \text{Speedup}(\WorkerCount)=\frac{\WorkerCount}{1+\ContentionCoefficient(\WorkerCount-1)+\CoherencyCoefficient \WorkerCount(\WorkerCount-1)} \tag{5}\]

\[ \WorkerCount^*=\sqrt{\frac{1-\ContentionCoefficient}{\CoherencyCoefficient}} \tag{6}\]

Contention ($\ContentionCoefficient$): The share of work that serializes, including undivided planning, final assessment, and queueing at single resources such as the supervisor or the integration queue.
Coherency ($\CoherencyCoefficient$): The cost of pairwise reconciliation. Each of the $\WorkerCount(\WorkerCount-1)$ ordered worker pairs may exchange state, re-read a peer’s output, or resolve a conflicting change, the same count as the mesh round in section 18.3.
Amdahl’s law ($\CoherencyCoefficient=0$): Capacity saturates at $1/\ContentionCoefficient$ and never declines.
Retrograde region ($\WorkerCount>(1-\ContentionCoefficient)/\CoherencyCoefficient$): A positive $\CoherencyCoefficient$ makes added workers harmful, not merely useless. Capacity peaks at $\WorkerCount^*$ and falls below one, slower than a single worker, past this count. With the screening notebook’s $\ContentionCoefficient=$ 0.20 and $\CoherencyCoefficient=$ 0.02, every count from 41 workers up finishes later than the serial reference.

Dividing both the numerator and denominator of equation 5 by $\WorkerCount$ yields $1/[\ContentionCoefficient+(1-\ContentionCoefficient)/\WorkerCount+\CoherencyCoefficient(\WorkerCount-1)]$. This expression matches equation 1 directly when setting the parallel fraction $\ParallelFraction=1-\ContentionCoefficient$ and the overhead function $\CoordinationOverhead(\WorkerCount)=\CoherencyCoefficient(\WorkerCount-1)$, so the screen’s linear penalty $\WorkerOverheadSlope$ plays the role of the coherency coefficient $\CoherencyCoefficient$. The match follows from the screen’s assumed linear elapsed penalty; it does not establish that every handoff cost is pairwise. Pairwise state reconciliation across $\WorkerCount$ workers can produce such a penalty when its quadratic aggregate work is distributed across the workers. Serialized processing of a growing receipt volume can also increase elapsed overhead with worker count. A fitted coefficient therefore nominates a mechanism to investigate rather than identifying its cause. Applying the notebook’s assumed parameters, equation 6 places the continuous theoretical optimum at 6.3 workers, which evaluates to the discrete optimum of 6 workers identified in the screening notebook.

↪ The stationary-root analysis that locates the peak of a fixed partition’s speedup curve is developed in Optimal worker count under Amdahl's Law with coordination overhead.

The architectural remedy depends on the measured source of overhead. Supervisor queue time, dependency invalidations, and reconciliation work help distinguish serial processing from cross-worker dependency work, and a matched trial that changes one mechanism can test the diagnosis. A verified serial bottleneck may benefit from pipelining supervisory prompts, sharding shared integration queues, or asynchronous event loops. When dependency reconciliation dominates, a partition that reduces cross-agent synchronization may instead pay. Interface refactoring coupled to caller implementations provides one such dependency hazard; a research query with independent search paths provides a contrasting partition.

Lighthouse 18.1: Research agent (orchestrator-worker fan-out)

Workload: The research agent addresses open-ended, breadth-first queries. A lead orchestrator decomposes the inquiry into independent search paths, dispatches read-only subagents to retrieve and analyze external sources, and synthesizes their condensed findings. The builders of one production research system report that this breadth-first regime is where delegation helps most, in contrast to coding tasks whose tight interdependencies leave less work to run in parallel (Hadfield et al. 2025).

Scenario coefficients: Suppose lead-agent planning and final synthesis serialize $\ContentionCoefficient=$ 0.10 of total execution, while subagents operate almost entirely without cross-communication ($\CoherencyCoefficient=$ 0.002). Evaluating the scalability model yields an optimal fan-out of 21 subagents achieving 5.5× relative capacity. In contrast, the code repair agent’s high coherency limits its configuration to 6 workers at 2.3× capacity. Under these assumptions, the research partition permits a 3.5× wider effective worker fan-out. (These stylized coefficients illustrate the scaling regime rather than measured telemetry.)

Local constraint: Low coherency overhead permits wider fan-out under the supplied model, but token expenditure and context trust can still constrain deployment. At fixed per-worker work, token consumption scales linearly with fan-out, so the economic break-even threshold analyzed in notebook 18.6 may cap deployment before the modeled capacity peak $\WorkerCount^*$. Furthermore, because worker receipts incorporate uncurated text from external web APIs, the bounded receipt protocol of section 18.4 limits returned context and keeps worker claims separate from runtime evidence. Source-derived fields and summaries remain untrusted inputs whose proposed uses require the security checks established for the tool boundary.

Systems insight: Under the supplied coefficients, the research partition supports wider fan-out than the repair partition. Dependency traces can establish whether interface isolation addresses the repair workload’s overhead; matched outcome and cost measurements determine whether wider research fan-out earns its additional spend. Admission controls bound that spend independently of the modeled capacity gain.

In production systems, empirical engineering inverts this analytical workflow. Rather than postulating coefficients, engineers conduct targeted benchmarking trials across a small set of practical worker counts (for example, $\WorkerCount \in \{1, 2, 4\}$) to estimate $\ContentionCoefficient$ and $\CoherencyCoefficient$. The resulting model fit projects the empirical capacity peak $\WorkerCount^*$, identifying the next candidate configuration to benchmark. A large fitted coherency parameter $\CoherencyCoefficient$ warrants inspecting traces and testing targeted interventions. Redesigning the task decomposition is justified when that evidence confirms that dependency reconciliation dominates; the coefficient alone does not establish the remedy.

18.9.4 A complete delegation decision

Once the scalability fit has nominated a configuration, the matched trial decides whether it earns its tax. Consider the evaluation results for a representative cohort of software migration tasks patterned after migration_task_01, evaluated under identical automated test suites (migration_accept_v1). Both configurations operate under identical constraints: matching tool and model concurrency limits, identical sandbox permissions, and equivalent token and financial ceilings. The experiment isolates the delegation architecture itself (how work is decomposed, dispatched, and integrated) rather than what the runtime allows.

Napkin Math 18.7: Buying deadline coverage with delegation

Problem: A prespecified screening protocol requires at least 80 accepted tasks before a final observation cutoff of 600 s, including at least 75 accepted before a strict deadline of 300 s, evaluated across 100 initiated tasks. Each architecture operates under a total cohort budget ceiling of $20. Which configuration satisfies this engineering screen?

Assumptions: Every trial reaches a terminal verdict with settled charges. Tasks may continue executing past the deadline up to the final cutoff and budget ceiling, but late completions do not count toward on-time acceptance. Illustrative pricing is $3 per million input tokens, $10 per million output tokens, and $0.01 per worker-second of metered sandbox, evaluation, and cleanup services, with no human intervention charges.

Table 9 sets the outcome counts beside the resources that produce their cost.

Table 9: Costs and Outcomes of a Hypothetical Delegation: Every model call and metered service contributes to total spend, including reconciliation and work not retained in the final artifact. The discarded-work row is a tagged subset, not an extra charge.

Cohort measurement	Single controller	Delegated configuration
Accepted by final cutoff	80 (80%)	80 (80%)
Accepted by deadline	70	78
Median time, accepted tasks only (biased)	240 s	180 s
Total input tokens	2,000,000	3,000,000
Total output tokens	400,000	600,000
Aggregate metered service time	200 s	300 s
Total priced spend	$12	$18
Included failed-attempt and canceled-branch spend	$3	$6
Cost per accepted task	$0.150	$0.225

Math: Total spend sums input and output tokens multiplied by their respective rates, plus aggregate worker service time multiplied by its compute rate; dividing this sum by total accepted tasks yields the effective cost per accepted task. Both architectures meet the gross acceptance target and stay within the budget ceiling, but only the delegated system satisfies the on-time completion threshold. Delegation incurs an incremental spend of $6 to secure 8 additional on-time completions, a marginal cost of $0.75 per additional on-time task, while inflating the overall cost per accepted task by 1.5×.

Systems insight: The screen advances the delegated configuration because the operational contract explicitly prioritizes deadline compliance over raw cost efficiency. Delegation does not Pareto-dominate the single-agent baseline; it trades dollar spend for wall-clock timeliness. The rational decision rule hinges on marginal value: delegate when an incremental on-time completion is worth at least $0.75, but retain the single controller when the objective is minimizing cost per completed task. Because speculative failures and canceled branches account for 33.3 percent of the multi-agent spend, this discarded work is a substantial cost component to investigate when reducing the coordination tax. The median row is the survivors-only statistic that section 18.9.2 warns against. It drops every task that was not accepted, so it flatters both configurations, and the decision deliberately rests on the on-time count instead. A production release decision further requires evaluating task diversity, paired statistical tests, and formal uncertainty bounds as detailed in Statistical Evaluation Rigor.

Whichever configuration the matched trial favors, a single capable controller or a delegated topology, the deployment must preserve end-to-end acceptance verification, fine-grained sandbox authority, and accounting for canceled speculative work. The scalability fit chooses which worker counts deserve a trial, and the matched trial prices those candidates against the declared objective. Skipping either step—or relaxing the runtime controls that keep handoffs, merges, reviews, and cancellations sound—produces the recurring multi-agent failures cataloged next.

↪ Choosing between a single controller and a delegated topology by pricing both against the same acceptance contract and objective is developed in When a bounded loop beats a single call.

18.10 Fallacies and Pitfalls

Every pitfall below comes from treating a delegation boundary as a guarantee that the runtime never actually enforced. Splitting work across agents does not by itself speed up completion, prevent semantic conflicts, decorrelate reviewer errors, or settle in-flight operations when a parent stops. Each of those assumptions carries a measurable cost in latency, token spend, or broken repository state.

Fallacy: More workers necessarily improve the task outcome.

Adding parallel workers introduces synchronization overhead, resource contention, and coordination traffic that quickly erode parallel speedup. In the screening notebook (18.1), deploying eight workers consumes 0.440 of the serial execution time, compared to 0.433 achieved at an optimal configuration of 6 workers. Beyond this point, coherency cost dominates: under the universal scalability law with those same coefficients, scaling out to 41 workers runs slower than executing the workload on a single agent. Furthermore, economic cost escalates even when latency stalls. A multi-agent delegation multiple of 3.75× in token consumption pays for itself only on difficult tasks that an isolated single agent completes less than 26.7 percent of the time. Rather than assuming that parallelism is beneficial, system designers must benchmark candidate topologies under identical token budgets and time ceilings against a declared task objective.

Pitfall: Treating a clean merge as evidence that concurrent changes remain compatible.

A successful textual merge only verifies that concurrent workers avoided line collisions in shared files, leaving cross-file semantic dependencies completely unvalidated. Across a repository of 1,000 files where each worker performs 10 edits, two concurrent workers touch completely disjoint files 90.4 percent of the time. As a result, nearly every pair of concurrent patches merges cleanly from the perspective of version control, even when a caller and an interface worker introduce mutually incompatible API contracts. Coordination systems must validate semantic dependencies and test candidate integration trees within an isolated environment before guarded publication (section 18.5).

Fallacy: Agreement among reviewers proves correctness.

Consensus among language-model reviewers reflects the correlation of their errors rather than an objective proof of correctness. When multiple reviewer agents share underlying model families, prompt templates, or reasoning biases, their mistakes correlate positively. For instance, five reviewers with an individual false-approval rate of 20 percent would reach an erroneous majority verdict only 5.79 percent of the time under strict statistical independence. Under the assumed beta mixture, in which reviewers share each candidate’s difficulty, that false-majority rate jumps to 16.68 percent. Adding more reviewers of the same kind cannot eliminate this shared bias, because error rates quickly level off near an irreducible floor of 15.0 percent (section 18.6). Production architectures must treat subjective reviewer voting as an advisory signal and isolate it strictly from deterministic, guarded verification checks.

Pitfall: Closing the parent task and releasing its reservations as soon as cancellation is requested.

A cancellation request immediately closes admission for new subtasks, but active execution, external tool calls, and downstream token charges drain asynchronously. Discarded work is not a rounding error. In the delegation of table 9, failed attempts and canceled speculative branches account for $6 of $18 in delegated spend, and that table is complete only because every one of those charges stayed owned until it settled. If the parent task releases its accounting context and budget allocations the moment cancellation is requested, the trailing operations continue running without an owner, and their charges land outside any budget as untracked spend and leaked resources. Robust orchestrators close admission at the entry gates, broadcast cancellation signals downstream, and maintain accounting context and state reservations until all active operations, diagnostic evidence, and billing charges have fully settled under the settlement rule.

Fallacy: If each worker usually finishes on time, the fan-out usually finishes on time.

Synchronizing multiple concurrent workers behind an all-results barrier compounds tail latency exponentially. Because every worker must complete before the barrier can lift, the overall probability of on-time completion multiplies each individual worker’s success rate. With an individual on-time probability of 90 percent per worker, a fan-out of 8 workers completes within the deadline only 43.05 percent of the time, and barrier success falls below even odds once the fleet reaches 7 workers (section 18.7). Where the system contract accepts interchangeable or quorum-based results, implementing a stopping rule restores 96.19 percent; where every subtask is strictly required, the orchestrator must reduce fan-out width to keep tail latency bounded.

18.11 Summary

Delegation turns one trajectory into several, and every boundary it adds must carry explicitly what a single trajectory carried implicitly: the inputs a worker may rely on, the authority and allowance it may spend, the evidence it must return, and the obligations that outlive it. The runtime, not the workers, owns those boundaries. It separates claims from execution records, revalidates dependencies before anything publishes, treats agreement among similar reviewers as one correlated signal, and keeps every admitted operation owned until it settles.

Whether those boundaries are worth building is a measurement question. Delegation lowers cost per accepted task only when it raises acceptance by more than it multiplies spend; otherwise it must be bought as reduced wall-clock time or broader coverage that the declared objective explicitly values. The relations in table 10 carry these decisions, each under the modeling assumptions stated where it is developed.

Table 10: Key Equations of Multi-Agent Coordination: Each relation holds only under the assumptions stated where it is developed, such as a fixed work partition, uniform and independent write sets, an assumed beta mixture of reviewer difficulty, or independent and identically distributed completion times.

Equation	What it bounds or decides	Where derived
$\text{Speedup}(\WorkerCount)=\dfrac{1}{(1-\ParallelFraction)+\ParallelFraction/\WorkerCount+\CoordinationOverhead(\WorkerCount)}$	Elapsed-time speedup of a fixed work partition; achieving any gain over serial execution requires coordination overhead $\CoordinationOverhead(\WorkerCount)<\ParallelFraction(1-1/\WorkerCount)$	equation 1
$\AggregateSlotWork=\sum_{\DependencyGraphVertex\in \DependencyGraphVertexSet}\VertexSlotTime(\DependencyGraphVertex)$, $\CriticalPathDuration=\max_{\pi}\sum_{\DependencyGraphVertex\in\pi}\VertexSlotTime(\DependencyGraphVertex)$	Total execution work and the critical path; identifies sequential bottlenecks that bound parallel makespan	equation 2
$\ScheduleFinishTime\ge\max\left(\AggregateSlotWork/\WorkerCount,\CriticalPathDuration\right)$	Lower bound on makespan; adding worker capacity beyond peak concurrency cannot beat the critical-path term	equation 3
$\Pr(\text{no shared write})\approx\exp\left(-\dfrac{\WorkerCount(\WorkerCount-1)\WorkerWrittenFileCount^2}{2\RepositoryFileCount}\right)$	Probability that uniform write sets remain disjoint; collision risk scales quadratically with worker pairs, requiring isolated workspaces	equation 4
$\CorrelationCoefficient=\dfrac{\operatorname{Var}(\FalseApprovalPropensity)}{\MarginalFalseApprovalProbability(1-\MarginalFalseApprovalProbability)}$, $\text{majority false approval} \to \Pr(\FalseApprovalPropensity>1/2)$	Correlation among reviewer errors and the asymptotic error floor that adding homogeneous reviewers cannot reduce	section 18.6
$\WorkerCompletionDistribution(\TimeInstant)^{\WorkerCount}$ against $\Pr(\WorkerCompletionTime_{(k)}\le \TimeInstant)=\sum_{j=k}^{\WorkerCount}\binom{\WorkerCount}{\FinishedWorkerCount} \WorkerCompletionDistribution(\TimeInstant)^\FinishedWorkerCount[1-\WorkerCompletionDistribution(\TimeInstant)]^{\WorkerCount-\FinishedWorkerCount}$	Deadline probability of an all-worker barrier vs. a $\RequiredResultCount$-of-$\WorkerCount$ quorum; applies only when partial results are interchangeable	section 18.7
$\FreeCreditCount+\OutstandingItemCount=\CreditWindowCapacity$, $\text{residence} \approx \CreditWindowCapacity/\ServiceRate$	Credit-window invariant; bounds outstanding concurrent tasks and total context payload occupancy $\CreditWindowCapacity\DataVolume$; models mean residence under the stated service assumptions	section 18.7
$\GrantAllowedAccesses(\ChildCapabilityGrant)\subseteq\GrantAllowedAccesses(\ParentCapabilityGrant)$	Authority attenuation across delegation hops; capabilities monotonically narrow, while consumable allowances are partitioned and reserved atomically	section 18.8
Cost-per-accepted-task ratio $=\DelegationTokenMultiple\,\SingleAgentAcceptanceProbability/\MultiAgentAcceptanceProbability$	Cost-effectiveness threshold; multi-agent execution with token overhead multiple $\DelegationTokenMultiple$ lowers effective cost only if task acceptance increases by more than $\DelegationTokenMultiple$	equation 1.2, section 18.9
$\text{Speedup}(\WorkerCount)=\dfrac{\WorkerCount}{1+\ContentionCoefficient(\WorkerCount-1)+\CoherencyCoefficient \WorkerCount(\WorkerCount-1)}$, $\WorkerCount^*=\sqrt{(1-\ContentionCoefficient)/\CoherencyCoefficient}$	Modeled system capacity under supplied contention and coherency penalties; identifies optimal fan-out $\WorkerCount^*$ and the retrograde regime where additional concurrency degrades throughput	equation 5, equation 6

Key Takeaways: Delegation must earn and preserve its boundaries

Coordination overhead sets the useful fleet size: Serial execution constraints cap parallel speedup at $1/\ContentionCoefficient$, while pairwise reconciliation costs cause effective system throughput to fall beyond $\WorkerCount^*=\sqrt{(1-\ContentionCoefficient)/\CoherencyCoefficient}$. Shrinking serial planning and integration overhead raises the scalability ceiling far more than merely shaving latency off individual handoffs. Empirical profiling across realistic workloads, rather than casual inspection of isolated agent trajectories, must calibrate these parameters.
Task dependencies govern completion makespan: Communication topologies, scheduling precedence, and fault-supervision hierarchies address distinct systems requirements. Once a schedule attains its critical-path bound, further latency reductions require shortening that path; before it does, additional slots or reduced contention may also shorten runtime. Furthermore, any agent endowed with recursive delegation authority requires hard runtime limits on fan-out, nesting depth, and aggregate token reservations.
Delegation handoffs require explicit runtime contracts: A handoff envelope must establish immutable task inputs, granted execution authority, resource budgets, and required evidence before worker execution begins. The returned receipt must strictly isolate ground-truth execution records from the worker’s unverified self-assessment, truncating narrative explanations rather than audit telemetry whenever context limits bind.
Disjoint writes do not guarantee semantic compatibility: Non-overlapping file edits establish only that parallel workers avoided concurrent modification conflicts; they do not prove that combined changes preserve system-wide behavioral invariants. Safe publication requires revalidating dependencies against the latest branch head, testing the integrated candidate in isolation, and advancing branch pointers through conditional atomic updates.
Correlated reviewer errors impose an irreducible accuracy floor: When automated reviewers evaluate an intrinsically challenging artifact, shared model blind spots cause their errors to correlate, preventing majority-voting failure rates from dropping to zero. Beyond this floor, spending additional tokens on reviewers of the same kind yields negligible benefit. Runtimes must instead incorporate independent checks, such as deterministic test suites or static analyzers, because peer consensus cannot manufacture authoritative correctness.
Resource obligations outlive parent caller lifecycles: Canceling a parent agent halts the dispatch of new downstream tasks, but it does not automatically terminate remote tool operations, network sockets, or asynchronous child processes already in flight. Each in-flight bound has its own mechanism. Credit windows bound the volume of queued work and support mean-residence sizing, attenuated grants and atomic reservations bound authority and spend, and the settlement record, not cancellation or credit release, keeps every admitted effect owned until its outcome and charges settle.
Multi-agent execution must outperform a capable single-agent baseline: A meaningful evaluation benchmarks multi-agent architectures against an equally optimized single-agent controller provisioned with identical parallel tool access, context allowances, and wall-clock budgets. System accounting must price every failed attempt, speculative invocation, and rollback, justifying multi-agent coordination only when the resulting increase in task success or latency reduction offsets its marginal token overhead.

The coordination tax (principle 14) manifests in the serialized handoffs, validation barriers, and residual dependencies that remain after decomposing a task. Invariant closure (principle 1) mandates that these architectural boundaries maintain strict external validation and effect gating, ensuring that peer consensus among models is never mistaken for authoritative execution rights. Finally, trajectory-level encapsulation (principle 10) extends from one trajectory to a tree of them. Every child is a separately owned trajectory whose derived grants only narrow, whose consumable allowance is reserved against its ancestors’ shared allowance, and whose unsettled side effects remain accounted for by the runtime after its parent stops.

18.12 Historical Perspective and Further Reading

The question of when dividing computational work yields a net speedup is older than autonomous software agents. Gene Amdahl’s 1967 argument established that serial execution fractions strictly cap the speedup achievable by adding processors (Amdahl 1967). Two years later, Ronald Graham showed that while greedy list scheduling lands close to the theoretical dependency bound, adding parallel resources can paradoxically increase total completion time (Graham 1969). Neil Gunther later unified these dynamics in the universal scalability law, introducing a pairwise coherency penalty to explain how crosstalk and contention turn throughput saturation into outright performance collapse (Gunther 2008). Across successive computing generations, systems architects repeatedly found that coordination overhead and coherency penalties, rather than the raw supply of workers, dictate practical scale.

Amdahl, Gene M. 1967. “Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities.” Proceedings of the April 18-20, 1967, Spring Joint Computer Conference on - AFIPS ’67 (Spring), AFIPS ’67 (spring), 483–85. https://doi.org/10.1145/1465482.1465560.

Erman, Lee D., Frederick Hayes-Roth, Victor R. Lesser, and D. Raj Reddy. 1980. “The Hearsay-II Speech-Understanding System: Integrating Knowledge to Resolve Uncertainty.” ACM Computing Surveys 12 (2): 213–53. https://doi.org/10.1145/356810.356816.

Hewitt, Carl, Peter Bishop, and Richard Steiger. 1973. “A Universal Modular ACTOR Formalism for Artificial Intelligence.” Proceedings of the 3rd International Joint Conference on Artificial Intelligence (IJCAI), 235–45.

Distributed artificial intelligence confronted the handoff problem in the 1970s. The Hearsay-II speech-understanding system coordinated independent, opportunistic knowledge sources through a shared blackboard (Erman et al. 1980). Carl Hewitt’s actor model abandoned shared memory entirely, giving each autonomous agent private local state and routing interactions through addressed messages (Hewitt et al. 1973). Reid Smith formalized structured delegation in the Contract Net Protocol, turning task announcement, bidding, and award into an explicit, typed exchange between a manager and prospective contractors (Smith 1980).

Over the following decades, classical distributed systems research supplied the precise operational controls that multi-agent architectures require today. Kung and Robinson introduced optimistic concurrency control, permitting workers to execute tentatively against private workspace copies and validate isolation before committing (Kung and Robinson 1981). Birrell and Nelson established typed remote procedure calls with explicit failure semantics, replacing unstructured message passing with formal client-server contracts (Birrell and Nelson 1984). Gray and Cheriton solved distributed state synchronization and lock management through time-bounded leases (Gray and Cheriton 1989). Joe Armstrong formalized supervision trees within Erlang, demonstrating how structured hierarchies and crash-only semantics allow runtimes to restart failed processes from clean, known states (Armstrong 2003). Finally, object-capability systems eliminated ambient authority by embedding access rights directly into object references rather than relying on global identity checks (Dennis and Van Horn 1966; Hardy 1988), an approach later extended through cryptographically attenuable tokens with chained caveats (Birgisson et al. 2014).

Kung, H. T., and John T. Robinson. 1981. “On Optimistic Methods for Concurrency Control.” ACM Transactions on Database Systems 6 (2): 213–26. https://doi.org/10.1145/319566.319567.

Birrell, Andrew D., and Bruce Jay Nelson. 1984. “Implementing Remote Procedure Calls.” ACM Transactions on Computer Systems 2 (1): 39–59. https://doi.org/10.1145/2080.357392.

Gray, Cary G., and David R. Cheriton. 1989. “Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency.” Proceedings of the Twelfth ACM Symposium on Operating Systems Principles (SOSP), 202–10. https://doi.org/10.1145/74850.74870.

Dennis, Jack B., and Earl C. Van Horn. 1966. “Programming Semantics for Multiprogrammed Computations.” Communications of the ACM 9 (3): 143–55. https://doi.org/10.1145/365230.365252.

Hardy, Norm. 1988. “The Confused Deputy: (Or Why Capabilities Might Have Been Invented).” ACM SIGOPS Operating Systems Review 22 (4): 36–38. https://doi.org/10.1145/60609.60611.

Birgisson, Arnór, Joseph G. Politz, Úlfar Erlingsson, Ankur Taly, Michael Vrable, and Mark S. Miller. 2014. “Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud.” Proceedings of the Network and Distributed System Security Symposium (NDSS).

Condorcet, Marquis de. 1785. Essai Sur l’application de l’analyse à La Probabilité Des décisions Rendues à La Pluralité Des Voix. Imprimerie Royale.

Neumann, John von. 1956. “Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components.” In Automata Studies, edited by Claude E. Shannon and John McCarthy, vol. 34. Annals of Mathematics Studies. Princeton University Press. https://doi.org/10.1515/9781400882618-003.

Eckhardt, Dave E., and Larry D. Lee. 1985. “A Theoretical Basis for the Analysis of Multiversion Software Subject to Coincident Errors.” IEEE Transactions on Software Engineering SE-11 (12): 1511–17. https://doi.org/10.1109/TSE.1985.231895.

Redundancy followed a parallel trajectory of high theoretical promises followed by sobering empirical corrections. The Condorcet jury theorem (Condorcet, Marquis de 1785) and John von Neumann’s multiplexed majority organs (Neumann 1956) demonstrated that aggregating independent votes can synthesize near-perfect reliability from noisy components. Leslie Lamport, Robert Shostak, and Marshall Pease proved the rigorous mathematical bounds of Byzantine fault tolerance, establishing that agreement in the unsigned-message protocol model survives arbitrary, even malicious, faults only while fewer than one third of participants are faulty (Lamport et al. 1982). However, the independence premise behind probabilistic majority-voting guarantees collapsed when applied to software. John Knight and Nancy Leveson demonstrated experimentally that independently written programs fail coincidentally on the same edge cases far more often than chance predicts (Knight and Leveson 1986). Dave Eckhardt and Larry Lee provided the analytical explanation: complex problem domains harbor intrinsically difficult input regions that induce correlated failures across diverse implementations (Eckhardt and Lee 1985).

Modern language-model systems have revived every one of these designs at the same time. Self-consistency uses majority voting across sampled reasoning paths (Wang et al. 2023), multi-agent debate structures iterative argumentation across model instances (Du et al. 2023), and conversational frameworks coordinate role-playing agents over structured communication graphs (Wu et al. 2023). In production, orchestrator-worker patterns have delivered capability gains on breadth-first research tasks, and their builders report roughly 15× the token consumption of a chat interaction to get them (Hadfield et al. 2025). Systematic empirical analyses of multi-agent failures reveal that the field has re-encountered classical distributed failure modes: ill-defined task boundaries, uncoordinated handoffs, and verification bottlenecks that silently propagate errors rather than catching them (Cemri et al. 2025).

Wang, Xuezhi, Jason Wei, Dale Schuurmans, Quoc Le, Ed Chi, Sharan Narang, Aakanksha Chowdhery, and Denny Zhou. 2023. “Self-Consistency Improves Chain of Thought Reasoning in Language Models.” The Eleventh International Conference on Learning Representations.

Du, Yilun, Shuang Li, Antonio Torralba, Joshua B. Tenenbaum, and Igor Mordatch. 2023. “Improving Factuality and Reasoning in Language Models Through Multiagent Debate.” arXiv Preprint arXiv:2305.14325.

Wu, Qingyun, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Biyi Gao, et al. 2023. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation.

Hadfield, Jeremy, Barry Zhang, Kenneth Lien, Florian Scholz, Jeremy Fox, and Daniel Ford. 2025. How We Built Our Multi-Agent Research System. Anthropic Engineering Blog.

The Contract Net Protocol (Smith 1980). The foundational text on structured delegation. Smith frames task distribution as a typed, negotiated protocol, showing that the essential elements of modern task envelopes, from capability announcements to formal awards, were established long before language models existed.
An Experimental Evaluation of the Assumption of Independence in Multiversion Programming (Knight and Leveson 1986). The landmark controlled experiment that disproved the assumption of independent software failures. This paper provides the standard methodological blueprint for evaluating whether an ensemble of redundant agent reviewers yields genuine reliability gains or merely inflates inference cost.
Making Reliable Distributed Systems in the Presence of Software Errors (Armstrong 2003). Armstrong’s doctoral dissertation detailing the architecture of Erlang. It articulates the operational rationale for supervision trees, fail-stop process isolation, and restart strategies, mapping directly to how orchestrators should manage the lifecycles and blast radiuses of child agent trajectories.
A General Theory of Computational Scalability Based on Rational Functions (Gunther 2008). Gunther derives the universal scalability law directly from queueing models. The derivation clarifies the physical distinction between contention and coherency, explaining why serial bottlenecks and cross-agent communication require different architectural fixes.
Why Do Multi-Agent LLM Systems Fail? (Cemri et al. 2025). An extensive empirical taxonomy analyzing real-world multi-agent failure traces. It serves as an indispensable field catalog of the specification gaps, uncoordinated handoffs, and verification failures that production runtime environments must actively prevent.

Smith, Reid G. 1980. “The Contract Net Protocol: High-Level Communication and Distributed Problem Solving in a Distributed Processor.” IEEE Transactions on Computers C-29 (12): 1104–13.

Gunther, Neil J. 2008. “A General Theory of Computational Scalability Based on Rational Functions.” arXiv Preprint arXiv:0808.1431.

Cemri, Mert, Melissa Z. Pan, Shuyi Yang, Lakshya A. Agrawal, Bhavya Chopra, Rishabh Tiwari, Kurt Keutzer, et al. 2025. Why Do Multi-Agent LLM Systems Fail?

18.13 Exercises

Every given below is a hypothetical problem input, not a measurement of a real system. Each problem ends in a design decision, and the calculation exists to justify it.

Choosing the lever in a worker-count screen (Basic). A fixed work partition has divisible fraction $\ParallelFraction=0.9$ and normalized overhead $\CoordinationOverhead(\WorkerCount)=\WorkerOverheadSlope(\WorkerCount-1)$ with $\WorkerOverheadSlope=0.01$. The resource ceiling permits at most $20$ workers, and each added worker adds roughly the same token spend.
1. Using equation 1, compute the normalized elapsed time at $\WorkerCount=4$, $8$, and $16$, the integer count that minimizes it, and the speedup at that count. Compare the count with $\sqrt{\ParallelFraction/\WorkerOverheadSlope}$.
2. Two proposals compete for the same engineering effort: halving the per-worker overhead to $\WorkerOverheadSlope=0.005$, or halving the serial work so that $\ParallelFraction=0.95$. Compute the best integer count and its speedup under each proposal.
3. Decide which proposal to fund once worker spend is counted, and state which proposal alone can ever deliver a speedup above $10\times$.
Hot files in a shared workspace (Basic). A repository holds $\RepositoryFileCount=5{,}000$ files, and each worker writes $\WorkerWrittenFileCount=20$ of them, chosen uniformly and independently.
1. Using equation 4, compute the probability of at least one shared write for $\WorkerCount=2$ and $\WorkerCount=4$ workers, both exactly and by the exponential approximation. Find the smallest fleet for which a shared write is more likely than not.
2. Each worker also edits one shared dependency manifest with probability $0.3$, independently of its other writes. For four workers, compute the probability that at least two edit the manifest, and the probability of any shared write at all.
3. A colleague proposes a single shared working directory for four workers because “collisions are under 40 percent.” Decide, and name the two hazards of section 18.5 that remain even when no two workers write the same file.
Sizing a credit window for staleness (Basic). A producer emits candidate items at $\ArrivalRate=2$ items per second. A consumer model writes a $400$-token critique of each item at $50$ output tokens per second, and each returned record occupies at most $\DataVolume=8{,}192$ bytes. An item is useful only if the consumer begins serving it within $60$ s of admission. For initial sizing, screen a saturated credit window by requiring its modeled mean residence to be no greater than this interval; assume negligible transport time and full utilization at the stated service rate.
1. Compute the consumer’s service rate $\ServiceRate$, the backlog of an unbounded queue after five minutes, and the wait of the newest item behind that backlog.
2. Using the full-window mean residence $\CreditWindowCapacity/\ServiceRate$, find the largest integer window $\CreditWindowCapacity$ that passes this sizing screen and its payload bound $\CreditWindowCapacity\DataVolume$. Does passing the screen establish that every item begins service before its freshness deadline?
3. Find the minimum number of identical consumers needed to keep pace with the producer and the largest shared window that passes the same mean-residence screen at their aggregate service rate. State how admission timestamps and a freshness check before service should handle an item that has waited too long. Explain why cancellation and settlement traffic must not draw on these data credits.
A fourth slot or a shorter vertex (Intermediate). A migration plan has a shared specification $\DependencyGraphVertex_1$ ($30$ s); four module refactors $\DependencyGraphVertex_2$ through $\DependencyGraphVertex_5$ ($60$, $60$, $90$, and $40$ s), each depending only on $\DependencyGraphVertex_1$; and an integration check $\DependencyGraphVertex_6$ ($50$ s) depending on all four refactors. Each vertex occupies one interchangeable slot, with no other delays.
1. Compute $\AggregateSlotWork$ and $\CriticalPathDuration$ from equation 2, and the lower bound of equation 3 for $\WorkerCount=2$, $3$, and $4$ slots.
2. By assigning the four refactors to slots, find the shortest achievable makespan for each $\WorkerCount$. Explain why the bound is not attained at $\WorkerCount=2$.
3. The team currently runs $\WorkerCount=3$ and can afford either a fourth slot or engineering that shortens $\DependencyGraphVertex_4$ to $60$ s. Decide, and state what shortening $\DependencyGraphVertex_4$ buys once the fourth slot exists.
Pricing deadline coverage (Intermediate). Under matched resource ceilings, a single controller spends an expected $\$0.40$ per attempt with $\AcceptanceProbability=0.60$, and $40$ of every $100$ attempts are accepted by the deadline. A delegated configuration spends $\$0.90$ per attempt with $\AcceptanceProbability=0.80$, and $72$ of every $100$ attempts are accepted by the deadline. Spend includes failed attempts and canceled branches, and cost is proportional to tokens.
1. Compute $\CostPerAcceptedTask$ for both configurations from equation 1.2, and their ratio.
2. Find the token multiple $\DelegationTokenMultiple$, the delegated acceptance that would restore break-even on $\CostPerAcceptedTask$, and the largest single-controller acceptance for which break-even is possible at all.
3. Per $100$ attempts, compute the marginal cost of each additional on-time acceptance. One service values an on-time accepted migration at $\$1$, another at $\$5$. Decide which configuration each should run.
Hedged lookups for the support agent (Intermediate, second-lighthouse transfer). The support agent answers a refund-eligibility question by dispatching three read-only lookups in parallel: the customer record, the order history, and the governing policy clause. All three are required. Each lookup attempt independently returns an admissible result within $1$ s with probability $0.70$ and within $2$ s with probability $0.95$. The service target is that at least $95$ percent of answers have all three results within $2$ s. Assume $1{,}000$ sessions dispatch their three initial lookups simultaneously. The lookup pool has $4{,}000$ slots, and each launched attempt retains its reservation until the $2$ s observation cutoff, even if its result arrives earlier. An attempt that has not returned an admissible result remains outstanding until that cutoff. Treat the stated completion probabilities as unchanged by load when calculating a policy without admission blocking.
1. Compute the probability that all three results arrive within $2$ s without hedging. Explain why the $\RequiredResultCount$-of-$\WorkerCount$ stopping rule of section 18.7 does not rescue this fan-out.
2. Compare two hedging policies: duplicating every lookup at dispatch, and starting a replacement only for a lookup still outstanding at $1$ s, which must then itself return within the remaining $1$ s. Assuming every proposed hedge is admitted, compute the per-lookup and all-three probabilities within $2$ s. For each policy, compute both expected slot demand and the largest possible slot demand before the cutoff.
3. Decide whether either calculation establishes that the policy meets the deadline target within the hard slot limit. Propose an admission rule for delayed hedges, and explain why deadline acceptance must be evaluated again when the rule can deny replacements. Contrast the binding constraint here with the coherency limit on the repair agent’s migration, and state what must hold before the same hedging could be applied to issuing the refund itself.
Bounding a remediation delegation tree (Intermediate, second-lighthouse transfer). The remediation agent is restoring a degraded checkout service. Its root grant permits reading metrics and logs for checkout and scaling the checkout deployment between $4$ and $12$ replicas; it permits no configuration writes. The root’s remaining allowance is $\$50$, of which $\$5$ is a protected finalization reserve and $\$6$ is already reserved for the root’s own outstanding work. The model proposes three children, each with a $\$20$ allowance, “less than the parent’s remaining $\$50$”: a metrics worker that reads checkout metrics, a log worker that reads logs for checkout and payments, and a capacity worker that scales checkout between $4$ and $16$ replicas.
1. State which proposed grants violate $\GrantAllowedAccesses(\ChildCapabilityGrant)\subseteq\GrantAllowedAccesses(\ParentCapabilityGrant)$ and how to narrow them. Compute the worst-case liability if each child’s allowance is copied from the parent’s balance, and which children atomic reservation admits if they are dispatched in the order listed. Find the largest equal allowance that admits all three. The capacity worker then proposes two scale workers at $\$8$ each; state which the runtime admits and repair the split.
2. An operator takes over and the runtime cancels the root at $\TimeInstant=0$. Both scale workers are active, and each submits at most one scale step every $5$ s to a remote gateway. Under a cached-authorization policy the gateway trusts a lineage record for up to $18$ s, with a $2$ s clock-skew allowance. Under a strict policy it looks up the current status and generation of each of the $3$ nodes in a scale worker’s lineage at $4$ ms per lookup. Compute the stale-policy window, the most scale steps it can admit after cancellation, and the strict policy’s added latency as a fraction of the step interval. Choose a policy for scale steps and one for metric reads, and state what the strict policy costs if the authoritative store is unreachable for $30$ s.
3. Under the policy chosen in part (b), the cost record at cancellation shows: the metrics worker settled $\$4$ and stopped; the log worker settled $\$9$, and a log-export job it started before cancellation is still unresolved with a bounded liability of $\$3$; the first scale worker settled $\$2$ and was confirmed terminated; the second scale worker settled nothing, and a node-pool scale-up it started before cancellation has an unknown outcome with a bounded liability of $\$5$; the root’s own work settled $\$4$. Compute the allowance the runtime may release now, the amount still held, and the release a “cancellation refunds all reservations” rule would claim. A follow-up remediation task needs a $\$20$ allowance. Decide whether to admit it now, and state who owns the two open operations and what that owner must retain.
Buying evidence past a correlated floor (Advanced). Reviewers each falsely approve a known-invalid candidate with marginal probability $\MarginalFalseApprovalProbability=0.10$, and their errors follow the beta mixture of section 18.6 with $\CorrelationCoefficient=0.30$. The release rule requires that an invalid candidate be approved with probability at most $0.01$. A reviewer call costs $\$0.20$. A protected regression test costs $\$0.50$ and passes an invalid candidate with probability $0.05$, assumed independent of the candidate’s reviewer propensity $\FalseApprovalPropensity$.
1. Compute the beta parameters $\PropensityPriorApprovalShape$ and $\PropensityPriorRejectionShape$, and the majority false-approval probability for three reviewers under independent errors and under the mixture.
2. Compute the mixture’s majority false approval for seven reviewers and the floor $\Pr(\FalseApprovalPropensity>1/2)$, numerically. Decide whether any number of reviewers of this kind can meet the release rule.
3. Price two designs per candidate: seven reviewers under majority vote, and three reviewers plus the protected test, with approval requiring both a reviewer majority and a passing test. Compute each design’s false-approval probability and choose one.
4. Critique the assumption that the test is independent of $\FalseApprovalPropensity$. Name a mechanism from this chapter that would correlate the test with the reviewers, and state the measurement that must precede release.
Fitting the scalability law before choosing a fan-out (Advanced, critique and redesign). Trials of a repair-migration partition under matched resources measure relative capacity $\text{Speedup}(2)=1.835$ and $\text{Speedup}(4)=2.878$. The serial reference takes $40$ minutes, and the service requires completion within $11$ minutes. The expected cost of an attempt grows with worker count as $\$1.00+\$0.30(\WorkerCount-1)$, and acceptance does not change with $\WorkerCount$.
1. Rearrange equation 5 so that it is linear in $\ContentionCoefficient$ and $\CoherencyCoefficient$, fit both coefficients from the two measurements, and compute $\WorkerCount^*$ from equation 6, the best integer count and its capacity, and the smallest count that runs slower than one worker.
2. A trial at $\WorkerCount=8$ measures $2.90$. Compare it with the fitted prediction, and state what the gap implies about using the fit outside the measured range.
3. The team proposes deploying the best integer count from part (a). Critique the proposal against the deadline. For this calculation, suppose two proposed redesigns have the following responses: sharding the integration queue halves $\ContentionCoefficient$, and repartitioning the migration so interface changes land before caller work begins halves $\CoherencyCoefficient$. For each, find the smallest worker count that meets the deadline, if any, and its cost per attempt, and recommend a design under these assumptions. State what trace or matched intervention evidence would establish the assumed coefficient responses in a deployment.

What’s Next: From coordination to cost

When is the time saved by delegation worth its additional resource use? This chapter answered for one stated workload, charging failed attempts and canceled branches to the accepted tasks they served. That accounting is a special case of a question every deployment faces, for one agent or many. The next chapter opens with the repair team offered a model whose tokens cost a tenth as much and asks why the switch can still raise the price of every repair that ships. Answering it means counting what each accepted task costs across all its attempts, how context reuse, retries, and model choice change that cost, and how concurrent trajectories compete for capacity. The same account then prices delegation itself, without dropping the reservations and unresolved obligations established here.