AI Agent Observability: What to Log When Agents Act

Your dashboards probably tell you the agent used 4,000 tokens, took 1.2 seconds, and called three tools. Useful. But when someone asks “why did the staging database restart at 2 AM,” none of that helps. The token count doesn’t say who approved the restart, or whether it can be undone.

That gap is what agent observability closes.

What is AI agent observability?

Agent observability is the practice of recording what an autonomous agent actually did in real systems, in a way you can query, attribute, and trust. It answers operational questions:

• Which operation ran, with exactly which parameters?
• Which agent requested it, and on whose behalf?
• Was it allowed automatically, approved by a human, or refused?
• What was the outcome, and how do we reverse it?

Notice these are not questions about the model. They are questions about consequences. That’s the shift.

How is agent observability different from LLM observability?

The two get confused because they share tooling and vocabulary. They answer completely different questions.

	LLM observability	Agent observability
Watches	The model	The consequences
Core data	Prompts, tokens, latency, cost, tool-call traces	Operations, actors, approvals, outcomes
Answers	”Why did it decide that?"	"What did it do to production?”
Audience	ML engineers tuning quality	Operators, security, auditors
Failure it catches	Bad output, drift, cost spikes	Unauthorized or unsafe changes
Storage need	Sampled traces are fine	Append-only, tamper-evident

LLM observability is genuinely valuable. Tools that trace token usage and tool calls, often built on the OpenTelemetry GenAI semantic conventions, help you debug and control cost. But a sampled trace of the model’s reasoning is the wrong artifact for “prove who deleted the bucket.” You need a durable, complete record of actions, not a sample of thoughts.

What should you log when an agent acts?

Every consequential action should produce a record with these fields. Treat it as the schema for an agent audit trail.

• Actor identity. The specific agent seat, not a shared service account. In AWS this rides along as sts:SourceIdentity, so the event in your CloudTrail names the agent, not a generic role.
• Human on behalf of. Which person the agent was acting for. Attribution to a bot alone is a dead end during an incident.
• Operation and parameters. The typed operation (“reboot RDS instance”) and its inputs, captured before execution.
• Policy decision. Auto-approved, human-approved, or refused, plus which rule decided. This is where you learn what your guardrails are actually doing.
• Outcome. Success, failure, and the cloud provider’s response.
• Reversal state. Enough of the before-state to undo the change. Logging that something happened without the ability to reverse it is regret with a timestamp.
• Integrity. The record should be append-only and tamper-evident, ideally hash-chained, so it holds up as evidence and not just as debug output.

If that list looks like an audit trail, that’s the point. Good agent observability and a good audit trail are the same artifact viewed from two angles: one for operators debugging, one for auditors verifying.

Why token traces are not enough

Three reasons the model-centric view falls short once an agent can act.

Consequences outlive context. A conversation trace expires or gets sampled away. The security group the agent opened stays open. Your record of why it is open needs to last as long as the change does.

Attribution has to reach the cloud. If your model trace says “agent called ec2:AuthorizeSecurityGroupIngress” but CloudTrail shows a shared role, you cannot correlate them under pressure. Attribution needs to be carried into the provider, not just kept in your app.

Prompt injection means intent lies. When untrusted text can hijack an agent’s instructions, the model’s stated reasoning is not trustworthy evidence. What it did, recorded independently of the model, is. This is also why real guardrails live outside the model, and why the observability record has to be produced by infrastructure, not by the agent narrating itself.

Where observability meets governance

Here is the useful realization: if you build the enforcement layer well, you get observability for free. A system that validates every operation server-side has to see every operation to validate it. That same checkpoint is the perfect place to record it.

This is the design behind AI agent governance: agents call typed operations through a control plane, the control plane decides and executes, and every decision lands on an append-only ledger as a side effect of enforcement. You do not bolt observability on afterward. It falls out of the fact that one place saw everything.

A quick self-check

Ask these about your current setup:

• Can I list every cloud change an agent made last week, with parameters?
• Does each change name the agent and the human behind it?
• Can I tell approved changes from refused attempts?
• Can I prove the log was not edited after the fact?
• For any destructive change, can I reverse it?

If you answered “no” to two or more, you are observing the model but not the agent.

How Mesoplane does it

Mesoplane sits between your agents and your cloud, so it is the one place that sees every operation. Each sensitive action becomes a typed, risk-tiered operation, recorded on a tamper-evident ledger with the acting agent’s SourceIdentity, the human behind it, the policy decision, the outcome, and a rollback envelope for destructive changes. That is agent observability as a property of the system, not a dashboard you have to wire up.

If you are still deciding how the agent should reach AWS in the first place, start with giving Claude Code safe AWS access.

Frequently asked questions

What is AI agent observability?

AI agent observability is the practice of capturing what an autonomous agent actually did in real systems: which operations it requested, on whose behalf, whether they were approved or refused, and what changed as a result. It goes beyond model-level tracing to answer the operational question, what happened, and can I trust the record of it.

How is agent observability different from LLM observability?

LLM observability watches the model: prompts, tokens, latency, cost, and tool-call traces. Agent observability watches the consequences: the real operations an agent ran against your cloud or database, who authorized them, and how to reverse them. One tells you why the agent decided something. The other tells you what it did to production.

What should you log for an AI agent?

At minimum: the acting agent identity and the human behind it, the workspace or tenant, the exact operation and parameters, the policy decision (auto-approved, human-approved, or refused), the outcome, and enough before-state to reverse the change. The record should be append-only and tamper-evident so it holds up as evidence, not just as debug output.