AI agent observability: the nine fields to log on every run, the six alerts that catch failures early, and how long to keep any of it

The question that separates an agent programme in production from one in permanent pilot is whether anyone can answer, for a given run last week, what the agent read, what it decided, what it did, what it cost, and whether a person signed off. EY's September survey of senior AI executives found 91 per cent of organisations using agentic AI in pilot or deployment, 81 per cent worried about AI-enabled attacks by third parties and 75 per cent worried about a public AI failure damaging their reputation. The worries are reasonable. The remedy for both is the same unglamorous thing: a record.

Anthropic gave a sense of what the record looks like at scale in September, disclosing that roughly 30,000 agents perform research and engineering work on its internal platform at any moment, that every action passes a real-time monitor, and that about 0.002 per cent of more than a billion agent decisions in August were blocked. Vendors have noticed the gap in the market: Alation and Airrived both shipped agent observability products the same month, and every control plane we wrote about in October has observability as one of its six functions. You do not need any of them to start. You need a schema, a few alerts and a retention policy.

What should you log for every agent run?

Nine fields, captured for every run and every step within it, in a store you can query. Together they answer the five questions above and satisfy most of what an auditor or a regulator will ask.

The run identity: a unique run ID, the agent's name and version, the identity it ran under, who or what triggered it, and when. The input: the request or event that started the run, with personal data redacted or tokenised where your data protection review requires. The model: provider, model name and exact version, temperature and other settings, and the system prompt version, because the prompt is code and changes to it need a diff. The steps: every model call and every tool call in order, with the tool name, the arguments, the result and the time taken. The decisions: where the agent chose between branches, what it chose and, where the model gives one, the confidence. The approvals: any human checkpoint, what the person was shown, who they were, what they decided and when. The outcome: what the run produced, whether it completed, and any error. The cost: input and output tokens per call, the price applied, and the run total, in money as well as tokens. And the lineage: which data sources the run read, which systems it wrote to, and which upstream run or event it depends on.

The OpenTelemetry project's semantic conventions for generative AI give a vendor-neutral way to name most of these, and most agent frameworks emit something close to them already. The work is usually in adding the fields the frameworks leave out: the identity, the approvals, the money and the lineage. Those four are the ones people ask about after an incident.

Log the tool result as well as the tool call. A run that misbehaves usually did so because of something it read, and the prompt injection cases that reach production are only diagnosable if the poisoned document is in the trace.

Which alerts catch agent failures early?

Six, and the order matters because the first three cost nothing to build once the nine fields exist. Cost per task drifting above its baseline, per agent, comparing this week's median to last month's: it catches the prompt change that doubled the token count, the model version that started thinking longer, and the loop nobody noticed. Steps per task drifting upward, which is the earliest sign of an agent losing its way and the surest sign of a retry loop. Tool error rate rising, per tool, which catches upstream API changes before the agent's output quality tells you.

Then three that need a little more. Egress to a new destination: any tool call that sends data to a domain, address or account the agent has not used before, which is the signature of exfiltration and also of a well-meaning integration change nobody registered. Quality score drift on a sampled golden set, run daily against the production configuration, from the evaluation harness, with an alert when the score drops below the threshold you set at release. And personal data appearing where it should not: a scan of traces for the identifier patterns your redaction should have caught, because redaction fails silently and the DPDP Rules make the failure expensive.

Every alert needs an owner who will act on it within a working day, or it becomes noise within a month. The register of agents should name that owner per agent, and the alert should go to them rather than to a channel.

What should the dashboard show a manager?

Four numbers per agent, weekly: runs completed, cost per completed run, the share of runs that needed a human, and the golden-set score. Below them, the trend for each over the last twelve weeks and the list of open alerts. Nothing else on the first screen.

Those four numbers describe the economics of the agent in the terms a budget owner uses. Runs completed is volume. Cost per run, against the cost of the same task done by a person, is the ROI calculation reduced to one line. The share needing a human is the autonomy the agent has earned; it should fall over time and any rise is a question. The golden-set score is quality, and the release history annotated on its trend line shows which change helped and which hurt.

Engineers need the trace viewer underneath: search by run ID, by customer identifier where lawful, by tool, by error, with the full step sequence and the ability to replay a run against a new model version. That view is for diagnosing. The four numbers are for deciding, and the mistake most teams make is showing managers the trace viewer.

How long should you keep agent logs?

As short as debugging and audit can tolerate, and decided by your privacy obligations before your storage budget. Traces contain whatever the agent read, which for most business agents means customer names, contact details, account numbers and the content of their messages. Under the DPDP Rules from May 2027, that is personal data held for a purpose, and retention beyond the purpose is a breach of Rule 8. The Rules also expect security logs kept for a year for breach detection, which pulls the other way.

The reconciliation most teams land on has three tiers. Full traces with inputs and tool results for a short window, of the order of 30 days, long enough to diagnose the incidents that get reported and short enough that erasure requests rarely hit it. Redacted traces, with identifiers tokenised and the structure and metrics intact, for a year, which serves the security and audit purpose without holding the personal data. And the aggregates, cost, volume, quality and approvals per agent per day, kept indefinitely, because they hold no personal data and they are the history the programme will be judged on.

Write the retention period into the register alongside the owner, and build the deletion job before the first trace is written, because a retention policy that depends on someone remembering to run a script is not a policy.

What does this cost to build?

Less than a month for a team that already has a logging pipeline, and most of that month is deciding the schema and the alert thresholds rather than writing code. The agent frameworks emit traces. OpenTelemetry collectors route them. Any log store you already pay for can hold them. The evaluation harness, if you built it before launch as we keep insisting, already produces the quality score. The cost figures come from the gateway that every model call should already pass through.

What the month buys is the ability to answer the question at the top of this piece, and with it the ability to give an agent more to do. Every step of autonomy a business hands to an agent is a step it has to be able to check, and the checking is only possible if the record exists. The companies in EY's survey that worry about a public failure are right to. The ones that will avoid it are the ones that can see the small failures first.

Frequently asked

What is AI agent observability? AI agent observability is the practice of recording what an AI agent read, decided, did, cost and had approved on every run, in a form that people can query and alert on. It extends application observability with fields specific to agents: model and prompt versions, tool calls with arguments and results, decision points and confidence, human approvals, token cost in money, and data lineage. It is one of the six functions of an agent control plane and the one that makes the others auditable.

What should be logged for an AI agent? For every run and each step within it: the run identity and the agent identity it ran under; the input; the model, version and prompt version; every model and tool call with arguments, results and timing; the decisions and any confidence scores; human approvals with what the approver saw; the outcome and errors; the cost in tokens and money; and the lineage of data read and systems written. The OpenTelemetry semantic conventions for generative AI provide standard names for most of these fields.

How long should AI agent logs be retained? Long enough to diagnose incidents and satisfy security audit, and no longer than data protection law allows for the personal data the traces contain. A common pattern is full traces for around 30 days, redacted traces with identifiers tokenised for a year to meet security log expectations such as those in India's DPDP Rules, and aggregate metrics per agent per day kept indefinitely. The retention period should be recorded in the agent register and enforced by an automated deletion job.

Related reading

• Do you need an AI agent control plane?
• Building evaluation harnesses for production AI systems
• India's DPDP Rules reach AI systems on 13 May 2027
• Prompt injection defence for AI agents with tools
• Flat-rate AI is ending for agents. How to budget when every loop is metered

An agent you can see is an agent you can give more responsibility to, and an agent you cannot see is one you will eventually have to switch off. Designing the run record, the alerts and the retention tiers, and wiring them into the agents you already run, is part of every AI agents engagement we take on.