Card 20 of 40· Develop
Middleware: reusable capability across agents
Logging, authorization and exception handling in one place — and the four points where middleware can intervene.

The syllabus asks you to "design middleware for reusable capabilities across the
solution, including logging, authorization, and exception handling". Three
unglamorous things, and the reason they are on an expert exam is the phrase across
the solution.
Why middleware rather than per-agent code
Logging. Correlation IDs applied uniformly. Eight agents each logging their own
way gives you eight logs and no trace — and you discover this during an incident,
which is the worst possible time.
Authorization. Checked before the tool runs, in one place. A check that each
agent implements individually is a check that some agent eventually forgets, or
implements slightly differently, or skips because that agent was written in a hurry.
Exception handling. Consistent classification of transient versus permanent, and
therefore one retry policy rather than eight subtly different ones.
The common thread: these are things that must be true of every agent, and
anything that must be true of every agent should not depend on every agent
remembering.
Where middleware sits, and what each position buys
Middleware intercepts at four points, and they map exactly onto the four guardrail
intervention points:
Before the model. Inspect and shape the input.
Before the tool. Authorise, budget-check, or block. The highest-value
position, because it sits between what the agent intends and what actually
happens.
After the tool. Scan the result — for injected instructions arriving in
retrieved content, and for credential-shaped strings that a downstream error message
helpfully included.
After the model. Validate the output before anyone sees it.
That third one is the position most implementations do not have, and it is where the
prompt-injection defence actually lives.
Some concrete things worth putting there
Beyond the three named:
Token and cost accounting — the budget from the cost card has to be enforced
somewhere, and the orchestrator's middleware is the natural place.
Secret scanning on tool outputs — a small piece of middleware that catches the
case nobody plans for.
Guardrail trigger counting — so trigger rate becomes a monitored signal rather
than a log line.
Span attributes — including the outcome attribute that makes tokens-per-outcome
computable at all.
The trap
If a scenario says "every agent must do X" — log this, authorise that, redact the
other, count something — the answer is middleware, not "add it to each agent's
instructions".
The instruction-based version is the same category error that runs through this
whole exam. It relies on every agent's cooperation for something that should not be
optional, and it degrades silently as the system grows, because nothing tells you
when the newest agent was written without it.