Observability and monitoring components

The syllabus asks you to specify observability components and monitoring components
as two separate things. They get run together in conversation, and separating them
is the point of this card.

Observability answers: can I see inside it?
Monitoring answers: is it still good?

You need both, and neither gives you the other.

Observability — the three named

Cross-service trace correlation. One identifier threading a web request through
an orchestrator, through four agents, into a tool and out to a downstream service.
Without it you have five separate logs and no story — and reconstructing what
happened means reading timestamps and guessing.

Structured logging of agent reasoning paths. Not just what happened but why
the agent chose it — which tool, with which arguments, and what it considered and
dropped. This is the part that does not exist in ordinary application logging,
because ordinary applications do not make choices.

Agent replay capture. Enough state to reproduce a run. This matters more than
it sounds, because you cannot re-run a probabilistic system from a log line and get
the same behaviour. If you want to debug a specific failure rather than a class of
failure, you have to have captured enough to recreate it.

Monitoring — a different list, about behaviour

Cross-agent coordination tracking. Is the team actually progressing, or handing
work back and forth politely and never concluding? This is the failure that produces
no exception at all.

Behavioural drift and quality regression detection. Degradation with no code
change. Needs a fixed evaluation set on a schedule — live traffic structurally
cannot see it, because the input moves at the same time as the behaviour.

Automated remediation for known failure patterns. With the standing rule that
every automated remediation needs a manual override and a loud signal, or you find
out about the underlying problem months later with the evidence gone.

Compute components

The syllabus asks for compute that meets "scalability, reliability, operational
efficiency, security, and cost requirements". Four practical readings:

Scalability — concurrency limits, spawning limits, batching.
Reliability — durable execution for anything long-running.
Operational efficiency — the least you can manage that meets the need, which is
the argument for a prompt agent where one will do.
Cost — right-size per step rather than per system.

Developer tooling

Easy to skim past, and it is an explicit bullet: dev containers, Visual Studio Code
extensions, CLI, dependency management, and AI instructions.

That last item is the interesting one. Instructions to the coding assistants your
team uses are being treated as part of the development environment — versioned,
shared, and reviewed like any other configuration. Which is consistent with the
theme running through this whole exam: the prompt is an artefact, wherever the
prompt happens to live.

The trap

A scenario about quality falling with nothing deployed is a monitoring question,
and no amount of tracing detail answers it.

Perfect observability tells you exactly what the system did on any given run. It
cannot tell you that what it did got worse — for that you need a baseline, held
still, measured on a schedule. The two are complementary and they are not
substitutes, which is precisely why the syllabus lists them as separate bullets.