Chapter 9Control and coordination

Control patterns structure task execution, how the system advances from a goal to a result. Coordination patterns structure interaction among agents, how multiple agents combine to do work no single agent could do alone. Both are extensively cataloged elsewhere; Anthropic’s Building Effective Agents defines the canonical workflow shapes (prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer), Gulli (2025) treats them with framework code, and the CSIRO catalog formalizes them in the academic literature.

This chapter is therefore compressed. It enumerates the patterns by name with one-sentence Intent, names the forces (Chapter 3) they balance, and develops the architectural commitments each pattern entails. For full hands-on treatment, see the bibliography (Chapter 21).

The chapter’s argument is short:

Editorial position Most production agentic systems should be single agents with tools, possibly orchestrated; multi-agent coordination is over-prescribed and under-justified.

This argument is developed at the end of the chapter. The patterns are cataloged first; the decision table near the end is the keeper, the operational answer to which pattern do I reach for, and a reader short on time may jump to it directly.

Pattern topologies

Five shapes recur through the catalogs below — three control topologies and two coordination topologies. The figure is a visual index; the commitments that follow unpack what each shape requires in bounds, governance, and trace discipline.

Control patterns

Control patterns structure how an agentic system advances through a task. They are the deterministic skeleton inside which the agent’s probabilistic decisions happen.

Architecturally, control patterns are realized as the classic primitives of execution structure: finite state machines (FSMs) and directed graphs, most often acyclic. The nodes are steps, agentic or deterministic, and the edges are conditional routing logic. A sequential pipeline is a degenerate straight line; a router is a branch; an evaluator-optimizer loop is the one shape that is deliberately cyclic, bounded by an iteration cap. Frameworks such as LangGraph and AWS Step Functions are explicit graph engines for exactly this reason. Naming the underlying graph keeps the discussion grounded in ordinary, rigorous software architecture rather than novel agentic vocabulary. These same engines double as durable execution substrates, persisting each step so a long-running agent survives the loss of the compute running it; Chapter 18 develops that operational role.

Sequential pipeline (prompt chaining)

Intent. A linear chain of stages, each consuming the previous stage’s output.

Forces. Predictability over adaptability. Latency is the sum of stages.

Architectural commitments. Stages have explicit input and output schemas. Each stage is a deterministic transformation or a single bounded model call. Failure of a stage aborts the chain or routes to a defined fallback.

When to use. When the task decomposes cleanly into discrete stages whose order is known at design time. Document processing pipelines, code-review pipelines, structured generation tasks.

Anthropic name. Prompt chaining. Read Anthropic Building Effective Agents for the canonical treatment.

Router

Intent. Classify the input and dispatch to one of several specialized downstream components.

Forces. Predictability and specialization over generality.

Architectural commitments. The classifier itself is testable; its decisions are part of the trace. Downstream components are independent. Misclassifications have a defined fallback (a default route, an escalation, a refusal).

A router is typically fire-and-forget: it classifies the input, dispatches to the chosen downstream component, and its own job is done; it does not wait for or synthesize the result. This is the key lifecycle difference from an orchestrator (below), which delegates, blocks on the worker’s response, and combines results. The distinction changes how the operation is traced and budgeted: a router’s cost and latency end at dispatch, while an orchestrator owns the cost and latency of the whole delegated subtree.

When to use. When the input space partitions into clear classes with distinct handling. Customer support triage; multi-domain assistants where one model per domain outperforms one model for all.

Read more. Anthropic Building Effective Agents; Gulli (Routing chapter).

Parallelization

Intent. Run multiple subtasks concurrently, then aggregate results.

Forces. Latency over cost (more parallel calls). Variance reduction (via voting aggregation).

Architectural commitments. Aggregation rule is explicit (concatenate, vote, judge, merge). Failure semantics handle partial completion (best-of-N succeeded; quorum reached; abort if too few succeeded). Cost budget governs the parallelism factor.

When to use. When subtasks are independent or when variance reduction via voting is worth the cost. Self-consistency reasoning; multi-perspective drafting; parallel retrieval.

Read more. Anthropic Building Effective Agents; Gulli (Parallelization chapter).

Orchestrator–worker

Intent. A central agent decomposes a task and delegates to specialized worker agents, then synthesizes their results.

Forces. Specialization and bounded authority over coordination complexity.

Architectural commitments. Workers have narrow, declared capabilities. The orchestrator’s delegation is bounded (it cannot ask a worker to do something the worker is not declared to do). Cross-worker communication is mediated by the orchestrator, not direct. The orchestrator is itself bounded (Chapter 5).

When to use. When the task decomposes into specialist subtasks (a coding system decomposing into plan, edit, test, review). The most common multi-agent shape in production.

Read more. Anthropic Building Effective Agents; Gulli (Multi-Agent Collaboration chapter); Augment Code 2026 catalog.

Evaluator–optimizer

Intent. A generator produces a candidate; an evaluator critiques it; the generator revises; repeat until the evaluator accepts.

Forces. Quality over latency and cost.

Architectural commitments. The evaluator is independent (different model, different prompt, or evaluates against test execution). Iteration is bounded. The evaluator’s verdict has defined semantics (block, modify, annotate). The final commit is reviewable.

When to use. When quality dominates latency. Code generation with tests as the evaluator. Drafting with style validators. Plan generation with feasibility checks.

Read more. Anthropic Building Effective Agents; Andrew Ng (Reflection); Gulli (Reflection chapter).

Event-driven agent

Intent. An agent is triggered by external events rather than by direct user interaction.

Forces. Asynchrony over interactivity; centralization over emergence.

Architectural commitments. Unlike routing or chaining, which structure the task itself, event-driven operation structures the invocation lifecycle: it is a trigger model, not an execution topology, and a triggered agent still uses a router or a chain once it wakes. The defining commitment is decoupling ingestion from reasoning: event sources are validated (events themselves can be attacker-controlled), triggered tasks are bounded (Chapter 5) and observable, and state is durable across event arrivals.

When to use. Operations automation, incident response, monitoring agents, batch processing in response to file arrivals or queue messages.

Read more. Gulli (chapter on event-driven shapes).

Handoff

Intent. Transfer control from one agent to another at defined boundaries.

Forces. Specialization over coordination complexity.

Architectural commitments. Handoff is explicit and traced. State passed across the boundary is structured (no implicit prompt history). The receiving agent’s bounds apply from the moment of handoff.

When to use. Customer support escalation; multi-stage workflows with distinct expertise. OpenAI’s Agents SDK and Anthropic’s Agent SDK both treat handoff as a primitive.

Read more. OpenAI Agents SDK documentation; Anthropic Agent SDK documentation.

Saga (compensating actions)

Intent. A sequence of actions, each with a defined compensating action, executed such that partial failures can be undone.

Forces. Adaptability and recoverability.

Architectural commitments. Each action has an inverse or compensating step. Failure triggers compensation in reverse order. The compensating steps are themselves tested. One requirement is specific to LLM sagas: where a traditional database saga simply reverses a row, an agentic compensating step often needs to understand why the original action was taken in order to compensate correctly. The state payload handed to a compensating step must therefore include the failing agent’s reasoning trace and relevant episodic memory (Chapter 7), not just the action’s parameters, otherwise the compensator acts blind.

When to use. Any irreversible-action sequence where partial failure is recoverable. Multi-step provisioning, multi-step refunds, multi-step migrations.

Read more. Microservices patterns literature (Richardson, Microservices Patterns); applied directly to agentic systems.

The interrupt signal (cancellation propagation)

Intent. Let a user or monitoring layer halt a running agent immediately and deterministically, and have that halt reach every operation the agent has in flight.

Forces. Recoverability and cost control against the fact that a reasoning loop runs asynchronously, out of the user’s direct reach.

Architectural commitments. The bounding layer (Chapter 5) stops an agent that breaches a limit; this pattern stops one that a human has judged wrong while watching its trace (Chapter 13). Closing the interface is not cancellation — the backend loop keeps spending and acting. The architecture must carry an explicit, asynchronous interrupt signal, and on receipt it does not ask the agent to stop; it terminates the reasoning loop deterministically. The signal propagates downward: it severs the open connection to the model provider so the in-flight generation is not paid for, and it cancels any long-running tools executing on the agent’s behalf. A partially completed action sequence triggers its compensating saga (above); the trace records a session.aborted_by_user event so the abort is auditable rather than a silent gap.

When to use. Any interactive or long-running agent a human can observe, and any system where in-flight work carries cost or side effects. A cancellation token threaded through the loop and into every tool call is the baseline; treat it as infrastructure, not a feature.

Read more. Cooperative-cancellation and structured-concurrency literature (cancellation tokens and context propagation), applied to the agent loop and the tools it calls.

Coordination patterns

Coordination patterns govern interaction among autonomous agents. They are the patterns that distinguish a multi-agent system from a single agent with tools.

Supervisor–worker

Intent. A supervisor monitors workers, providing oversight without performing the work itself.

Forces. Bounded autonomy at scale; oversight without coordination overhead.

Architectural commitments. The supervisor reads worker traces; it does not redo the work. Intervention semantics are explicit (correct, escalate, abort). The supervisor is itself bounded.

When to use. Fleets of similar agents where centralized real-time review is impractical and post-hoc oversight is the realistic model.

Read more. Gulli (Multi-Agent Collaboration chapter).

Peer collaboration

Intent. Symmetric agents collaborate as equals, exchanging messages and producing joint output.

Forces. Emergence over centralization; flexibility over predictability.

Architectural commitments. Inter-agent messages pass through the governance layer (Chapter 6), agent-to-agent channels are an attack surface. Termination conditions are explicit (otherwise peers can loop indefinitely). Trace discipline applies to inter-agent messages.

When to use. Rare in production. Used effectively when the problem is genuinely decompositionally symmetric (multi-perspective research, debate).

Read more. Gulli (Multi-Agent Collaboration chapter); literature on debate and multi-agent reasoning.

Committee (voting)

Intent. Multiple agents independently solve a task; results are aggregated by voting.

Forces. Variance reduction over cost.

Architectural commitments. Agents are genuinely independent (different prompts, models, or context). Aggregation rule is explicit (majority, weighted, judge). Cost budget governs the committee size.

When to use. Self-consistency at the multi-agent scale. The distinction from parallelization (a control pattern, above) is substantive, not cosmetic: parallelization runs several samples of one agent, while a committee runs genuinely independent agents, different models, prompts, or context, so it reduces correlated error, not merely sampling variance. Especially valuable for high-stakes one-shot decisions.

Read more. Self-consistency literature; Gulli (Self-Consistency).

Debate

Intent. Two or more agents argue opposing positions; a judge renders verdict.

Forces. Variance reduction; coverage of failure modes.

Architectural commitments. Role isolation (an agent does not see opposing turns in ways that compromise the dialectic). Bounded rounds. Independent judge. Final verdict has defined semantics (decision, recommendation, flag for human review).

When to use. Legal review, safety review, adversarial testing of plans. Costly; reserved for genuine value.

Read more. Du et al., Multi-Agent Debate (2023); Gulli (Debate chapter).

Swarm, auction, and consensus (rarely justified)

Three coordination shapes appear in the catalogs and almost never in production: swarm, many agents advancing a shared goal through shared state; auction/bidding, agents bidding for tasks by declared capability; and consensus, multiple agents agreeing before an irreversible action. Each carries substantial architectural commitments if adopted: a shared memory bus with convergence detection for swarm, auditable bids and capability verification for auction, and explicit quorum rules and testable agreement for consensus. The 2024–2026 production record supports a cautious conclusion: all three are over-prescribed, common in research demos, and rare in deployed systems. Resist them unless the problem’s structure specifically demands them. Where the requirement they address is genuine, a more reliable construction usually exists: consensus on an irreversible action is more often met by a single agent with strong governance (Chapter 6) and an approval gate than by multi-agent agreement; dynamic allocation is more often met by an orchestrator with declared worker capabilities than by an auction. See Gulli and the CSIRO catalog for the shapes in full; treat them as a last resort, not a default.

The multi-agent caution

The editorial position that opens this chapter is the coordination-layer instance of the centralization-versus-emergence argument developed in Chapter 3: multi-agent coordination is over-prescribed, and the dominant successful shape in the 2024–2026 production record is a single agent with a constrained tool surface and strong governance, or an orchestrator with several bounded specialist workers. The force analysis in Chapter 3 gives the reasons: multi-agent traces are harder to read and debug, inter-agent communication is an attack surface (Chapter 6), coordination overhead is real, failure modes multiply (Chapter 11), and cost-effectiveness is rarely measured. Builders who adopt orchestrator–worker also need the identity and message-contract substrate developed in Chapter 14.

The architectural recommendation that follows from them is short: start with a single agent. Add an orchestrator with workers when the task decomposes cleanly and the decomposition reduces failure modes. Add peer coordination only when the problem has dialectical structure that genuinely benefits from it. Resist coordination shapes that exist to make the architecture diagram interesting.

Uncertainty across handoffs

Multi-agent shapes add a failure mode that envelope checks cannot see and final-output evaluation often misses. One agent produces a speculative inference: the anomaly is probably a retry storm, the ticket most likely concerns the billing migration. A downstream agent receives the conclusion without the evidence or the hedging that produced it, restates it while acting on it, and hands it on again. After two or three hops the claim reads as established fact — no step validated it, but every step repeated it. The final output is coherent and confidently worded, and it rests on a guess no component ever checked.

Evaluating the final prose alone cannot catch this, and even an outcome check (Chapter 12) misses it whenever the resulting state looks acceptable: the laundering happened in the middle. Detection is a process check over the trace — a grader that flags a claim acted on without provenance, or an inference-to-action transition that skipped validation — and that check is possible only if the handoff schema carries epistemic status in the first place.

The architectural response is to make handoff state carry epistemic status, not only content. The handoff pattern above already requires structured state; the structure must distinguish an observation (a tool returned this), an inference (an agent concluded this), and a decision (an agent chose this), and each claim carries its provenance and validation status as fields the receiving agent can read and the trace can record. Where uncertainty affects what the receiver may do with a claim, it is represented as structured metadata rather than as a prose qualifier, because a hedge written in prose is one fluent paraphrase away from disappearing.

Two enforcement points make the discipline hold. A transition from inference to external effect — an agent about to act on a claim it did not itself verify — passes through deterministic validation or an authoritative lookup first, the same gateway discipline that governs any consequential action (Chapter 6). And shared memory does not promote an inferred claim into semantic memory on any agent’s say-so: promotion goes through the ingestion and curation gate of Chapter 8, so the fleet cannot cache its own guesses as facts.

A caution on implementation: model-reported confidence is not a calibrated probability, and a schema field holding a model’s self-assessed confidence records fluency, not reliability. The property worth engineering is plainer — whether the claim carries evidence, and whether the receiving agent can tell verified state from unverified inference.

A decision table

For practitioners, the question is which pattern do I reach for. The table below summarizes the architectural call by task properties. It is not exhaustive — every system has constraints the table cannot anticipate — but it captures the recommended defaults.

Reach for coordination patterns only when the problem genuinely admits, and benefits from, multi-agent structure.

Control vs. coordination

A clarifying distinction: control patterns are about task structure — how a task is decomposed and executed — and apply equally to single-agent and multi-agent systems; an orchestrator–worker is a control pattern that happens to involve multiple agents. Coordination patterns are about agent-to-agent dynamics — how multiple agents interact — and presuppose more than one agent interacting meaningfully rather than independent workers in an orchestrator. The distinction matters because the commitments differ: control patterns are about deterministic skeleton; coordination patterns are about inter-agent governance, channel security, and convergence. Confusing the two — adopting a coordination pattern for its control properties without the coordination commitments — leads to under-governed inter-agent channels, the trace of many “multi-agent” production incidents.

Summary

Control and coordination patterns are well-documented elsewhere; this chapter catalogs the architecturally significant ones and develops the commitments, schemas, bounds, governance, trace discipline, that each entails. The chapter’s strongest position is that multi-agent coordination is over-prescribed: production systems are most often well served by a single agent or an orchestrator with bounded workers, with peer coordination reserved for problems whose structure justifies it.

The next chapter takes up the Skills layer, the runtime mechanism by which agents are extended without code changes. Skills change what the agent can be asked to do; they do not change the architecture of control, coordination, bounding, or governance. The chapter places them in context.