Observability For AI Agents Has To Move From The Request To The Decision

The views and opinions expressed are those of Srinath Gopinath and do not represent the official policy or position of any organization.

A reliability dashboard can show every light green while the system continues to get things wrong. In classic site reliability engineering that rarely happened, because the questions were deterministic: Is the service up? Did the request return? How much latency? Each one can be checked on every call, and a 200 meant what it said. But agents break that assurance. A task can finish clean, return a 200, and still be wrong underneath. Uptime carried reliability for a decade; it no longer says whether the work was right. Reliability has to move up a layer to the decision the model made.

Srinath Gopinath is a reliability and observability leader in banking with close to two decades in regulated financial services, and a doctoral researcher studying how engineering practices can be steered toward sustainable, cost-disciplined outcomes. His background is in site reliability engineering, DevOps, and release governance, the disciplines built to measure whether a system stays inside its limits. He's now working through how those disciplines have to change when the thing being measured can return a clean result and a wrong answer at the same time.

"Your reading could always be green. You could always get a 200, and the AI is still hallucinating underneath it," Srinath said. What he's after is the signal that sits below the status code: whether the model reasoned correctly, kept its context, and stayed with its sources. Building the observability to see that, he argues, is the central reliability problem of the agent era, and almost none of the existing tooling is pointed there.

• Two signals, not one: The mistake Srinath runs into most is treating an up signal as a correctness signal. They're different measurements, and the agent era needs both. "You end up needing two separate signals rather than one," he said, "something deterministic that tells you the system stayed inside its limits, and something sampled that actually judges the output." The deterministic half is the familiar work. The sampled half is new, because the golden signals that SRE has leaned on—latency, traffic, error rate, saturation—all keep returning tidy numbers whether or not the model underneath them is reasoning soundly. That's why the answer sits in a governing layer above the telemetry rather than in one more metric on the existing dashboard.

• Log the decision, not the output: Traditional incident response assumes you can reproduce a failure in a lower environment. A hallucination refuses to cooperate, because by the time anyone tries to recreate it, it's gone. Srinath's workaround is to instrument a different thing entirely. "People generally log outputs in applications, but log your decisions made by the LLM," he said, then score those decisions against a benchmark captured while the agent ran in a supervised mode. The gap between the two becomes an error budget, a deviation the team agrees to tolerate before it acts. Set that budget at five percent, and anything inside it runs untouched; anything beyond it pulls a human in to look. Building the benchmarks and monitoring to support that is the part most teams haven't started.

• Consequence over frequency: Counting errors misses the point when the errors aren't equal. A hallucinated email and a hallucinated instruction to delete a database are both single failures, and only one of them ends a career. "Tag all these destructive actions and rank them, maybe from R0 to R6," Srinath said. "The higher-tier destructive actions should be curbed. You want the human to come into the loop and see, is this the right action, and if not, cut it right there." He gates the irreversible calls so an agent can't proceed without a person, and incident response shifts in the same direction, from restart-the-service toward halt, contain, roll back, backed by a kill switch someone has rehearsed. There's also a lever that didn't exist before, which he calls contracting autonomy: instead of only blocking a release, a misbehaving agent gets pushed back down to requiring approval for its actions, a dimmer switch where there used to be an on-off toggle.

That machinery raises an obvious question, which is who or what does the judging, and it's where Srinath is most careful to separate the honest answer from the clean one. The appeal of an automated reviewer is that it scales, but a single reviewer can hallucinate as readily as the thing it's checking. His research is aimed squarely at how far that approach can actually be trusted, and the answer is bounded in a way most vendors gloss over.

• The ceiling on automated judges: The instinct is to convene a panel of models that cross-check each other and promote only the findings several of them agree on. If their mistakes were independent, confidence climbs fast, roughly ninety percent at three reviewers and near-certain within a few dozen. "But real models don't fail independently. They share training data and tend to get the same things wrong," Srinath said, which flattens the curve well short of the theory. The ceiling is set by how correlated the errors are, not by how many judges get added, landing somewhere between the high nineties when correlation is low and the high eighties when it isn't, and never quite reaching certainty. That's enough to move a person from reviewing everything to auditing a sample and handling exceptions on lower-risk changes. It isn't enough to take a human off sign-off for anything regulated or irreversible.

• Consolidate before the sprawl sets in: The last risk is self-inflicted. Teams are standing up overlapping agents in silos, each one rebuilding its own governance and cost controls or skipping them, driven partly by an internal race for the flashiest agent. Srinath's remedy starts with an inventory and a hard look at which use cases actually justify AI, since the technology carries real cost in both compute and the governance overhead around it. Consolidating the overlap into shared capabilities means the control plane gets built once instead of five times, which closes off five separate risk surfaces instead of one. Cost belongs in the same view, because a top-tier model rewriting routine email when a cheap one would do is a reliability concern now too, not a separate finance problem.

Pulled together, Srinath's argument is that the pieces aren't separate initiatives. Reliability and cost are the same problem seen from different angles, and both get enforced in the same place. "Governance isn't really a document. It's the runtime layer sitting around the model," he said, the place where actions get risk-tiered, irreversible calls get gated, budgets get capped, and telemetry finally reaches the decision instead of stopping at the request. Gone are the days, he added, when agents were just experimentation; they're in prime time now, and the instrumentation has to catch up to that fact.