AgentOps: tracing a system that chooses its own route
Conventional observability assumes the system does the same thing every time. A request arrives, a known sequence runs, and a trace shows where it stopped. An agent decides its own sequence while running, so two identical requests can take different paths, cost different amounts and take different lengths of time while both succeeding. That does not break the system, it breaks the instruments. Latency stops being a number and becomes a distribution with a long tail. Cost per request becomes a function of how many steps the thing chose to take. And the failure that matters most produces nothing at all to alert on: the agent still answers, still returns a success, still responds in a reasonable time, and the answers have quietly got worse. Catching that requires running a fixed set of cases on a schedule, because it is a deliberate measurement rather than a passive metric.
What a useful trace records
Not the list of calls. A trace that enumerates what the agent did answers the wrong question, because the question asked after an incident is why it did that.
Per step, the trace needs four things: what the agent was given at that point, what it decided to do, what came back, and what that changed about the next decision. The fourth is the one routinely omitted and the one that turns a complete record into a diagnosable one. Without it, a reviewer can see that the agent went down a bad path and not where the path diverged.
There is a retention question attached, and it is not optional. These traces are large and they contain whatever data the agent handled, which in most organisations means personal data. Full traces for a short window, sampled traces for longer, and permanent retention only for decisions with consequences is the arrangement that stays both affordable and lawful. It is a decision somebody takes, not a default a tool provides.
The three alerts worth having on day one
Step count above a threshold. The cheapest instrument available and the best leading indicator. An agent that starts taking eleven steps where it took four is telling you something upstream changed, and it says so before the bill does. A hard cap should exist regardless; the alert tells you how often it is being hit, which is the interesting number.
Cost per request above a threshold. The same signal expressed in money, useful because it catches cases where the steps are unchanged and each one got more expensive. It is also the version finance understands, which matters when you need the budget to fix something.
Scheduled evaluation score dropping. The only one that catches silent quality decay. A fixed set of cases, run nightly, scored the same way each time. The first two are proxies; this is the measurement, and a system running without it is not being monitored for quality at all.
Why quality decays without breaking anything
Several causes, none of which raises an error. The provider updates the model behind the system and it behaves slightly differently. An upstream source changes format and retrieval starts returning less relevant context. What users send drifts away from what the system was tuned for.
In each case the agent keeps working. It retrieves something, reasons about it, and answers. The answers are worse and no component in the stack has an opinion about that, because every component did its job.
This is the whole argument for the scheduled run. An organisation without one is waiting for a user to complain, which is monitoring with a feedback loop measured in weeks and a damaged relationship attached to every detection.
Incident review when the cause is a judgement
A conventional incident has a cause you can point at: a bad deploy, a failing dependency, a resource limit. An agent incident often has a cause that is a decision the system made, which was reasonable given what it saw and wrong given what was true.
That changes the review. The question is not what broke but what the agent was given that led it there, and the answer lives in the trace rather than in the logs. Teams whose traces do not carry the reasoning end these reviews with a prompt change and a shrug, which is how the same incident happens twice.
The useful output of such a review is rarely a prompt. It is more often a narrower permission, a lower step cap, or a case added to the evaluation set so the behaviour is caught next time before a user sees it.
Where this sits alongside everything else
AgentOps is not a separate discipline so much as the operational half of running agents at all, and at most organisations it is part of platform or AI engineering until there are enough agents that nobody can hold their behaviour in their head.
The work it depends on is upstream. A system with no evaluation set cannot be monitored for quality, and a system whose permissions were never written down cannot be reviewed when it does something unexpected. Both of those belong to governance and to the build, and no amount of observability compensates for their absence.
