Designing a multi-agent solution

Multi-agent designs are the thing everyone wants to build and the thing the exam
most often marks wrong. This card is really about restraint: knowing the three
legitimate reasons to split, and recognising when splitting is a way of avoiding a
design problem rather than solving one.

When more than one agent is actually right

Three reasons, and they are structural rather than technical.

Different surfaces. Users are in genuinely different places — Teams, a
website, a contact centre — and one agent cannot be everywhere well.

Different owners. Finance owns one, service owns another. Ownership boundaries
are a legitimate reason to split, and each agent then gets its own lifecycle and
its own entry in the register. This is the reason people forget, because it is
organisational rather than architectural.

Different capability or risk. A read-only advisor is a different proposition
from an agent that moves money. Splitting them lets you constrain the risky one
separately, rather than applying the strictest controls to everything.

When it is the wrong answer

One process, one surface, one owner. Splitting here adds hops, cost and new
failure modes for nothing. Every hop costs tokens and latency.

Splitting to dodge a design problem. Two confused agents are worse than one.
If the single agent is struggling because the task is badly defined, a second
agent inherits the same ambiguity and adds a handoff to it.

The pattern to prefer

Generative at the edges, deterministic at the core. Reason with the user where
flexibility genuinely helps, then execute through an agent flow where the steps
must be reliable.

That sentence is worth carrying into the exam and into real work — it is the
shape most robust production systems end up taking.

How they connect

Agent to capability is MCP.
Agent to agent is A2A, including across vendors.
Agent to business system is a connector or a flow.
An orchestrating parent routes to child agents by description, which is why
those descriptions have to be written carefully rather than as an afterthought.

Exam trap. "One product for a multi-surface problem" is a named distractor
pattern — and so is its opposite. Adding agents is not free: every hop costs
tokens, latency and a place to fail. Split on surface, owner or risk, never for
tidiness.

The one line to carry: three reasons to split — surface, owner, risk. Anything
else and you are adding hops to avoid a conversation about the design.