Observability when the system is not deterministic
Traditional monitoring asks whether the system responded. Agentic systems fail while responding perfectly, which is why most teams find out from a customer.
Conventional monitoring is built on a premise that does not hold here: that a working system and a broken one look different. An agent that has started answering from a stale document, or that has quietly begun escalating everything, or that has been talked into a bad action, returns a two hundred with a healthy latency. Every dashboard is green while the system is wrong.
Observability for non-deterministic systems has to watch output quality and behaviour, not just availability. That requires a different instrument set and, more importantly, a different set of alerts.
The three layers to instrument
Treat these as a maturity progression. Most teams have the first, need the second, and only build the third after an incident that could have been caught by it.
| Layer | What it watches | The failure it catches |
|---|---|---|
| 01L1 · Operational | Uptime, latency, error rates, token and step counts per task. | The system is down, slow, or looping and burning budget. |
| 02L2 · Behavioural | Full traces: inputs, retrieved context, tool calls, decisions, escalation and refusal rates. | The system is running but has changed what it does, and nobody decided that. |
| 03L3 · Quality | Sampled outputs scored against a rubric, downstream corrections, user overrides. | The system is running, behaving consistently, and producing worse answers than last month. |
In a deterministic system, silence means healthy. In an agentic one, silence means nobody is looking at the output.
Drift has four sources, and they need different responses
- Model drift: the provider updates a model and behaviour shifts under you. Pin versions where the platform allows it, and re-run the evaluation suite on every version change.
- Data drift: the inputs change shape, a new product line, a new format, a new market. Caught by monitoring the input distribution, not the output.
- Context drift: the corpus the agent reads goes stale or gains a conflicting document. Caught by tracking which sources answers are built from and how old they are.
- Usage drift: people find new ways to use the system it was never scoped for. This is often good news, but it is a scope decision, not something to discover through a failure.
Alert on behaviour, not thresholds
The most useful alerts in an agentic system are rate-of-change alerts on behavioural metrics. Escalation rate up forty percent week over week. Average tool calls per task climbing. A source document suddenly appearing in most answers. Confidence distribution shifting. None of these is an error and every one of them is a system telling you something changed before a customer does.
Build the trace view before you build the alerts. When an alert fires, the first question is always what the agent actually saw and did, and if answering that takes a day of log archaeology, the alert will be ignored within a month.
Make the human correction a signal
Every time a person overrides, edits, or reverses an agent action, that is a labelled example arriving for free. Capture it with the original context attached. Teams that do this accumulate an evaluation set that gets sharper as the system ages. Teams that do not will be constructing one by hand the first time they need to prove the system still works.
Want this graded for your own stack?
A systems audit runs your operation against exactly these dimensions and hands you the report.
Request a systems audit