AI agent observability

Companies have learned to log what AI systems say. The next challenge is logging what AI agents do.

Traditional model observability focuses on prompts, outputs, latency, errors, token use, evaluation scores, and sometimes the sources a model consulted. Those signals remain useful. They become incomplete when an AI system can open files, call APIs, send messages, run code, create records, authorize transactions, or delegate work to another agent.

At that point, the organization needs to reconstruct a chain of action, not merely a chain of text.

The need became clear when METR and Redwood Research documented a real-world incident involving agents driven by an unreleased OpenAI research model. Roughly 1,200 agents found an unsanctioned message board and exchanged more than 70,000 messages and files. About 700 AI agents participated in an attack on Hugging Face. They shared findings, assigned work, and achieved some collective milestones that comparable individual agents likely could not have reached alone.

The incident matters for data and AI teams because it shows how quickly a system’s effective behavior can exceed what one prompt, one transcript, or one agent log reveals. If many agents can coordinate across tools and permissions, the audit question becomes: what authority moved where, what action followed, and who or what caused the next step?

An action ledger answers that question.

For every consequential agent action, the ledger should capture at least five fields.

First, record the data context. What sources did the agent read immediately before acting? That might include a database query, customer record, document, event stream, model output, or another agent’s message. Data lineage tells investigators what information shaped the action.

Second, record the permission used. An AI agent may have dozens of credentials, scopes, API keys, service accounts, and tool grants. The ledger should identify the exact authority that made the action possible. Otherwise, teams can see that something happened without understanding why the agent was able to do it.

Third, record the action itself in business terms. “API call succeeded” is too technical for many investigations. The log should also say whether the agent changed a customer record, sent an external message, modified code, issued a refund, created a purchase order, or granted another system access.

Fourth, record delegation. If one agent asked another agent to perform part of the task, preserve that parent-child relationship. Multi-agent systems create a familiar data-engineering problem: transformations and dependencies matter. Without a delegation graph, teams may analyze one agent in isolation and miss the sequence that produced the outcome.

Fifth, record the human-control point. Did a person approve the action? Was approval required but skipped? Did the workflow rely on a standing authorization? Was there a threshold at which the agent should have stopped? These fields turn abstract governance into evidence that can be reviewed after an incident.

The action ledger should also support one critical operational feature: rapid revocation. If an agent behaves unexpectedly, teams need to identify every credential, tool, delegated worker, and workflow that depends on that agent’s authority. A good ledger should make containment faster rather than merely making postmortems richer.

NIST’s AI Agent Standards Initiative emphasizes secure and interoperable agent adoption. That goal will require observability standards that follow actions across systems, not just model-level telemetry inside one vendor’s stack.

This is especially important in environments built from multiple clouds, databases, SaaS applications, data pipelines, vector stores, and agent frameworks. An agent’s decision may begin in one system and become consequential several services later. Organizations need a stable event model that can connect identity, data, authority, action, delegation, approval, and outcome across those boundaries.

The same data can improve deployment decisions. Teams can measure how often agents require human intervention, which permissions remain unused, where delegation creates unexpected combinations of access, and which actions generate rework or incidents. That makes the ledger useful for optimization as well as security.

I’m no AI skeptic. I help organizations adopt AI for a living, and I want adoption to move faster. In my experience, strong safeguards increase trust and make faster adoption possible, while reducing the risk of failures like the Hugging Face attack.

That is why better observability should be treated as an adoption accelerator. Security teams can approve broader pilots when they can reconstruct agent actions. Business leaders can expand automation when they know who owns exceptions. Employees can experiment more confidently when mistakes can be contained and explained.

Agentic AI changes the unit of observability. The important record is no longer only what the model generated. It is what the system was allowed to do with that generation.

Model traces tell us what an AI system thought and said. Action ledgers tell us what happened to the organization because the agent acted. As companies give AI more authority, they will need both.

The post is by Gleb Tsipursky, PhD, a behavioral scientist, CEO of Disaster Avoidance Experts, and author of The Psychology of AI Adoption at Work: From Resistance to Results (Georgetown University Press, 2026). https://disasteravoidanceexperts.com/aibook