Cutting the System Apart Without Cutting It to Pieces

The Foundations chapter on multi-agent orchestration taught the mechanism: a coordinator that decomposes, delegates, aggregates, and decides, over subagents that inherit no history. This chapter zooms out to the architect’s altitude. The question is no longer “how does a coordinator invoke a subagent.” It’s “should this system be one agent or several, where do the seams go, and what does drawing them wrong cost me at scale?” Decomposition is a design property you can get right or wrong. Getting it wrong is expensive in ways that don’t show up until production.

Decompose, or don’t: the honest default

Start from the position that one agent is the default, and decomposition is what you justify. A single well-scoped agent is cheaper, faster, and dramatically easier to debug, because there’s exactly one place to look when something misbehaves. Every seam you add is a delegation round-trip that costs latency, a context re-establishment that costs tokens, and a new failure mode where a handoff drops information. The over-engineering trap is real, and it’s the most common architecture mistake in this space. Teams split a system into a swarm of agents because it looks sophisticated. They ship something slower, pricier, and flakier than the monolith it replaced.

So what actually justifies a split? The same forces from Foundations, now read as system properties:

• The context won’t fit or won’t stay focused. One agent’s job can pull in long documents, many tool results, a sprawling conversation. When that fills its context window or degrades its attention, splitting lets each agent keep a small, sharp context. This is the strongest single reason.
• The subtasks want genuinely different tools and instructions. A knowledge-retrieval role needs search and a “ground every claim in a source” prompt; an order-actions role needs database and refund tools and a “never act without confirmation” prompt. Fusing them produces one bloated agent with every tool and a contradictory prompt that’s worse at both jobs.
• Independent work can run in parallel. When subtasks don’t depend on each other, separate agents run them concurrently and the whole task finishes in roughly the time of its slowest branch.
• Different parts have different trust or governance needs. A component that can move money should be isolated behind its own guardrails and audit trail, not entangled with the chatty part that answers questions. A seam here is a security boundary, and that’s a legitimate reason to draw one even when the context would have fit.

If none of these bite, keep it as one agent. “It would be cleaner as microagents” is not a reason; a measured limit is.

Orchestration strategies at system scale

Once you’ve decided to split, how the pieces connect is the next choice. The coordination patterns are the same at scale, but here you’re choosing them for whole services, so read them for their operational consequences:

• Supervisor (hub-and-spoke). One coordinator owns the task and delegates to specialist subagents that don’t talk to each other. It’s the default for the same reason at every scale. All routing and error handling live in one place, so the system is reasonable to debug and structurally free of peer-to-peer loops. Choose this unless you have a specific reason not to.
• Hierarchical. Supervisors of supervisors. When the task decomposes into big chunks that each decompose again, a top coordinator delegates to sub-coordinators that manage their own subagents. It’s the supervisor pattern applied recursively. It earns its extra layer only when the domain genuinely has that nested structure — otherwise it’s just more hops.
• Pipeline (sequential). Agents in a fixed chain, each output feeding the next: extract, then transform, then validate. Right when the stages have a genuine, unchanging order and each truly depends on the last. If the order isn’t fixed, a pipeline forces a rigidity the task doesn’t have.
• Parallel (map-reduce). Fan the same kind of work across many agents, then merge. Right when you have many independent items to process and latency matters. The coordinator owns the fan-out and the merge. Reconciling parallel outputs is where this pattern hides its complexity.

Most real systems combine these: a supervisor at the top, a pipeline inside one branch, a parallel fan-out inside another. Not every component needs to be an agent. Some seams separate an agent from a plain service — the refund workflow, the RAG retriever, a rules engine. Decomposition at architecture scale is as much about splitting agents from deterministic services as it is about splitting agents from each other. The coordinator delegating to a database-backed order service is a cleaner design than an agent given raw SQL access.

Complete and disjoint: the property that tells you the cut is good

Whatever the strategy, the decomposition itself has to satisfy one property: complete and disjoint. Hold every proposed split against it. Every part of the task is covered by exactly one component — no gaps, no overlap.

Two failure modes show up in real designs, and the exam offers both as wrong answers:

• Incomplete (gaps). You split so finely, or drew the boundaries so carelessly, that some part of the task belongs to no component. A question arrives that the knowledge agent thinks is the order agent’s job and vice versa, and it falls through the crack. Coverage has holes nobody owns, and those holes are invisible until a user finds one.
• Overlapping (duplication). Two components claim the same responsibility. Both retrieve the same documents, or two agents both try to answer the same sub-question. You pay for the work twice and then have to reconcile two possibly-conflicting outputs — and reconciliation is itself a new place to be wrong.

“Complete and disjoint” is the test that rules out both. Trace a representative set of inputs through your decomposition and confirm each is handled by exactly one owner. If you can’t say which component owns a given case, the cut isn’t done.

The cost of cutting too finely

Over-decomposition is the failure architects with good instincts commit. They know decomposition is a virtue, so they overdo it. Each additional agent adds concrete, compounding costs:

• Latency stacks. Every delegation is a round-trip. A supervisor calling a sub-coordinator calling three subagents is several sequential model calls deep before any real work happens. Depth in the hierarchy is latency you can feel.
• Tokens multiply. Each agent re-establishes its own context — its system prompt, the task packaged into its invocation, its tool results. Split one agent into five and you’ve roughly quintupled the context overhead. None of them share the coordinator’s history: that’s the isolation rule, and it cuts both ways.
• Failure surface grows. Every seam is a handoff that can drop or garble information, and every agent is another thing that can loop, stall, or misjudge. More agents means more independent ways for the run to fail and more places to search when it does.
• Reasoning is harder to trace. A user-visible wrong answer in a ten-agent system means reconstructing which agent decided what across ten isolated contexts. The debuggability that made the supervisor pattern attractive erodes as you multiply the spokes.

The judgment call: prefer the coarsest decomposition that still satisfies complete-and-disjoint and keeps each component’s context focused. Merge two agents that always run together and share a concern; they’re one agent wearing two hats. Split only where a real force from the earlier list demands it.

The bookshop platform, decomposed

Apply the whole method to the support platform. Does it warrant decomposition? Yes, and for reasons from the list, not for flavor. The knowledge role and the order-actions role want genuinely different tools and prompts: retrieval-and-grounding versus act-with-confirmation. And the money-touching part deserves its own governance boundary.

So the shape is a supervisor: a support coordinator that reads each customer message and delegates. It routes knowledge questions to a knowledge-retrieval agent — RAG over policies, catalog, and help docs, grounding-focused and read-only. It routes account actions to an order-actions agent with the lookup_order and process_refund tools, behind the refund workflow and its human gate. The coordinator owns routing and aggregation. The two specialists never talk to each other, which keeps the whole thing debuggable and loop-free.

Is that decomposition complete and disjoint? Walk the inputs. “What’s your return policy” is knowledge, one owner. “Where’s my order A17” is order-actions, one owner. “My order is late and I want a refund” is order-actions — lookup then refund workflow — one owner. The coordinator must route the whole request there, not split it, or the refund falls in a gap. A vague “help, I’m frustrated” the coordinator handles directly by clarifying, rather than blindly fanning it to both and paying twice. Two specialists, cleanly partitioned, is the right coarseness. A fourth agent for “greetings” or a fifth for “small talk” would be over-decomposition. Those are turns the coordinator handles itself, not seams worth the round-trip.

What the exam is really checking

Domain 1 decomposition items describe a complex system and ask how to structure it, and both directions are traps. Some credit the answer that over-splits — a swarm where one agent and a service would do. You avoid those by remembering the compounding costs and the “coarsest cut that works” rule. Others describe a decomposition with a gap or an overlap and ask what’s wrong. The answer is that it isn’t complete-and-disjoint, and you name which. The through-line is judgment, not enthusiasm: decompose for a measured reason, connect with the debuggable supervisor pattern unless the task demands otherwise, and hold every cut against complete-and-disjoint. An architect who splits for sophistication fails these items; one who splits for necessity passes them.

Next: choosing a model as an architect — matching model capability to each component’s job, cost, and latency budget.