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, the parts that do not change with the framework or the model. 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/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 contributing to a shared goal via shared state; auction/bidding, agents bidding for tasks by declared capability; and consensus, multiple agents agreeing before an irreversible action. Each carries real architectural commitments if adopted, a shared memory bus with convergence detection for swarm, auditable bids and capability verification for auction, explicit quorum rules and testable agreement for consensus. The honest production record is that all three are over-prescribed, common in research demos and rare where the work must hold up, and the book’s recommendation is to resist them unless the problem’s structure demands them specifically. 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 honest reading of the 2024–2026 production record is that the dominant successful shape is a single agent with a constrained tool surface and strong governance, or an orchestrator with several bounded specialist workers (commonly referred to as sub-agents or atomic-agents). 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.

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. They apply equally to single-agent and multi-agent systems. An orchestrator–worker pattern is a control pattern that happens to involve multiple agents; a sequential pipeline is a control pattern that may involve one agent or several.

Coordination patterns are about agent-to-agent dynamics, how multiple agents combine. Peer collaboration, debate, swarm, auction, consensus are coordination patterns proper. They presuppose that the system has more than one agent and that the agents interact meaningfully (rather than being independent workers in an orchestrator pattern).

This distinction matters because the architectural commitments differ:

• Control patterns are about deterministic skeleton.

• Coordination patterns are about inter-agent governance, channel security, and convergence.

Confusing the two, treating a coordination pattern as a control pattern, leads to under-governance of the inter-agent channels. Many “multi-agent” production incidents trace to a coordination pattern adopted for its control properties without the architectural commitments of coordination.

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.