[ OBSERVE / AGENT_OBSERVABILITY ]

What is AI agent observability?

AI agent observability is the practice of capturing an agent’s whole decision sequence, the tools it called, the arguments it passed, and the results it acted on, rather than individual model calls. Centurian keeps that sequence as signed, regulator-ready evidence instead of a trace that expires.

The unit is the trajectory

A dispatch agent tenders a load at a rate that turns out to be wrong. You pull the model call that produced the number and it looks fine: sensible prompt, sensible completion, normal latency, normal cost. The error happened two steps earlier, when the agent consulted a stale rate table instead of the live one, and every step after that was a correct inference from a bad input.

That is why the unit of analysis for an autonomous agent is the trajectory rather than the call. LLM observability is necessary and does not cover it, because the reasoning that produced step three lives in the ordering of steps one and two. See trajectory evaluation for how the sequence gets scored rather than just recorded.

Drift hides behind a passing success rate

An agent that has started behaving differently usually keeps completing its task. Success-rate alerting therefore stays green while the route the agent takes to that success changes underneath it. Detection works by clustering trajectories on purpose, team, and platform and flagging the ones that diverge from their peers, which surfaces both the drifting agent and the one that has started misreporting what it did. Neither is visible from an outcome metric alone.

Observability data is not audit evidence

Debug telemetry is sampled, mutable, short-lived, and scoped to one application, and every one of those properties is the right call for diagnosis. Audit evidence needs the opposite on all four: complete rather than sampled, immutable, retained against a regulation’s clock rather than a storage budget, and signed so a third party can verify it without trusting the system that emitted it. Centurian writes each action with valid time and transaction time both, so the record answers what was known and when, not only what is true now. EU AI Act high-risk obligations under Annex III apply from 2 December 2027, and a period you did not instrument cannot be evidenced afterwards.

One view, not one per platform

Every agent platform observes its own agents and none observes the others. An org running agents on Salesforce Agentforce, AWS Bedrock, and custom code therefore holds three partial pictures and assembles the combined one by hand, quarterly, badly. Centurian registers every agent through one MCP front door, so the trajectory record, the cost attribution, and the compliance posture are org-wide by construction. That also closes the discovery gap: agents that never registered anywhere show up as shadow AI when activity signals are reconciled against the registry.

FAQ

What is AI agent observability?

AI agent observability is the practice of capturing an agent's whole decision sequence rather than individual model calls: which tool it chose, what argument it passed, what came back, and what it did next. The unit of analysis is the trajectory, because an autonomous agent's failure usually lives in the ordering of its steps rather than in any single completion.

What is AI agent monitoring?

Monitoring is the alerting half: thresholds on error rate, latency, spend, and policy violations that fire while the agent is running. Observability is the reconstruction half, which is what you need once the alert has fired and someone asks what actually happened. A monitoring stack with no trajectory record tells you an agent misbehaved without telling you why, which stalls the investigation at the moment it starts.

How is agent observability different from LLM observability?

LLM observability watches a call. Agent observability watches a sequence. If an agent tendered a load at the wrong rate, the model call that produced the number may look perfectly reasonable in isolation, because the error was in which tool it consulted two steps earlier. Multi-step autonomy is the whole reason the distinction exists.

How do you detect an agent that is drifting?

By comparing an agent's trajectories against those of agents clustered by purpose, team, and platform, rather than against a fixed rule. A drifting agent usually still succeeds at its task while the route it takes to get there changes, so success-rate alerting misses it entirely. Trajectory anomaly detection flags the change in route, which is also how an agent that has started misrepresenting what it did becomes visible.

Does agent observability produce audit evidence?

Not by default, and assuming it does is a common and expensive mistake. Observability data is typically sampled, mutable, retained for weeks, and scoped to one application, all of which are correct choices for debugging. Audit evidence needs the opposite: complete rather than sampled, immutable, retained against a regulation's clock, and signed so a third party can verify it without trusting the system that produced it.

Does it work across agents from different vendors?

That is the point of doing it at this layer. Each platform observes its own agents well and none of them observes the others, so an org running agents on Salesforce Agentforce, AWS Bedrock, and custom code has three partial views and no combined one. Centurian registers every agent through one MCP front door, so the trajectory record and the cost record are org-wide rather than per-vendor.

Get early access →

First agent free, forever · No credit card