Decompose the goal: workflow, agent, tool

Almost every architecture question on this exam is really the same question wearing
different clothes: given this goal, what should actually be built? And the
instinct most people bring to it is wrong in a specific, predictable way — they
reach for an agent too early.

So the first thing worth fixing is the order you try things in.

Workflow, then agent, then tool

A workflow is a set of deterministic steps. The path is known in advance, and
it runs the same way every time. That is not a limitation — it is the whole point.
If you can draw the steps and they do not change, no agent is needed and adding
one only introduces a way for the process to go somewhere you did not intend.

An agent is for the part that needs interpretation. Something has to be decided
that cannot be written down as a rule — reading an unstructured request, weighing
two options, working out which of five systems holds the answer.

A tool is one call to one system. And this is the part people skip: most steps
are tools. Looking up an order, sending an email, writing a record — none of that
needs judgement. It needs doing.

Try them in that order and you will build much less than you first imagined, which
is usually the right outcome.

When a step earns its own agent

Once you have decided you need agents at all, the next trap is deciding how many.
There are exactly three good reasons to split work into a separate agent.

Reasoning. It has to decide something, and the decision cannot be expressed as
a rule.

Boundary. It needs different permissions from the rest of the system, and
isolating it is the security control. This is the most under-used of the three,
and often the most defensible.

Containment. It has to be able to fail on its own, without taking the rest of
the system down with it.

If you cannot name which of those three a split buys you, do not split. The bad
reasons are easy to recognise once you say them out loud: the diagram looks
better, it mirrors the org chart, or it is really just one API call with an agent
wrapped around it.

What each extra agent actually costs

It is worth being concrete about the price, because it is usually invisible at
design time and very visible in production.

Every additional agent adds a context boundary to cross, which means a payload
you have to design deliberately. It adds another set of logs that has to be
correlated with the others before anyone can reconstruct what happened. It adds
another failure mode, and in agentic systems those tend to be silent rather
than loud. And it multiplies tokens, because every hop re-sends context.

None of that is a reason never to use multiple agents. It is a reason to make each
one justify itself.

The trap

"Design a multi-agent solution" is the name of the exam domain. It is not a
licence to use many agents.

When a scenario offers you a four-agent design and a one-agent-with-four-tools
design, the more sophisticated answer is usually the wrong one — expert-level
exams reward knowing when not to reach for the powerful thing. Ask which of
reasoning, boundary or containment the extra agents buy. If the answer is none of
them, the simpler design is correct.