If you cannot reconstruct one full agent run later, you do not really have AI observability. Here is the practical logging baseline that makes debugging and postmortems possible.
Most teams start AI agent logging the same way they start normal app logging. They log a few requests, a few errors, maybe the final output, then assume they can figure out the rest later.
That breaks fast.
In agent systems, the incident is rarely one model call. It is the chain of model calls, retrieval steps, tool actions, retries, approvals, and fallbacks. If you cannot reconstruct that chain later, you do not really have post-incident review. You have expensive noise.
The practical standard is simpler than it sounds. Log enough to rebuild one agent run from start to finish, correlate every important step, and understand exactly where the failure boundary was. If you need the broader foundation first, start with What Is an AI Agent in 2026?.
A normal service request usually has a cleaner shape. Input comes in, code runs, output goes back.
An agent run is messier. One request may fan out into multiple model calls, a retrieval step against changing data, one or more tool executions, a policy check, a human approval pause, a retry, and a fallback. The final bad answer may be caused by any one of those layers, or by the interaction between them.
That is why agent logging should be trace-first, not line-log-first.
If your team cannot open one trace and see the full decision path, you do not have AI observability yet. This is also why practical ops work tends to overlap with pieces like The 7 Failure Checks Every AI Agent Workflow Should Run Before Production. Logging is not separate from reliability. It is how reliability becomes reviewable.
Think in terms of a run, not a message.
Every run should have a traceable top-level record with linked spans for:
That one run should answer the questions operators actually ask during incidents:
If those answers live across five systems with no shared trace ID, your logging strategy is already failing.
Every run needs durable IDs that survive across services.
Log trace_id, run_id, span_id, parent span, session or conversation ID, user or tenant identifier in safe form, plus the agent name, agent ID, and agent version. Also log prompt template version, system instruction version, tool version, workflow step name, environment, and region.
Postmortems fail quickly when nobody can answer which prompt, model alias, or agent build actually ran.
You should always log the operational metadata around model calls.
That includes provider, endpoint, requested model, actual response model, temperature, top_p, max_tokens, seed when used, and whether streaming was enabled. Also capture finish reason, latency, and time to first chunk.
A bad answer is not always a reasoning problem. Sometimes it is a timeout, a token ceiling, a streaming break, or a hidden model-route change.
AI incidents are often performance incidents.
Log input tokens, output tokens, reasoning tokens when exposed, cache reads and writes when available, estimated cost, retry counts, and total run duration. If you track budgets or escalation paths, tie those records into the same run. That is the operational companion to How to Set Budgets, Rate Limits, and Escalation Rules for AI Agent Workflows.
Without this layer, teams misdiagnose expensive or slow runs as model quality issues.
If tool calls can change the world, they need better logs than your model completions do.
For each tool call, log the tool name and version, calling span, structured arguments with redaction where needed, start and end time, approval state, result code, retry history, and side-effect target such as recipient ID, record ID, ticket ID, or order ID.
Do not bury a database write, outbound message, or destructive action inside a vague debug string. Tools are where auditability becomes real.
If the agent uses RAG, log the retrieval step separately.
Capture the retriever name and version, query or query hash depending on sensitivity, corpus or index version, top-k settings, returned document IDs or chunk IDs, relevance scores when available, and which citations were passed downstream.
This matters because a confident wrong answer may be caused by bad retrieval, stale indexing, or missing context rather than the model itself.
A lot of important operational behavior happens outside the model call.
Log whether the run required approval, who approved or rejected it, what policy gate triggered the pause, whether a human took over, and where the handoff happened. These records should line up with the same trace as the rest of the run, not sit in a separate ticketing or chat silo.
If your workflow uses selective human review, this should connect directly with your human-in-the-loop approval patterns for AI operations and the practical handoff choices in The Best Human Handoff Points in an AI Workflow.
Do not log every failure as LLM error and call it done.
You need a low-cardinality error type, provider error code or HTTP status, retry and backoff history, last successful step, fallback invoked or not, and whether human escalation occurred. Exception messages and stack traces can be useful, but only under policy because they may contain secrets or user data.
The real value is classification. Teams need to distinguish model failure from tool failure, retrieval failure, orchestration failure, timeout, rate limit, policy block, and operator interruption.
This is where teams often get reckless.
The goal is not to log everything. It is to log enough to reconstruct what mattered without turning your observability stack into a data leak.
Use metadata plus redacted content by default. Allow raw payload capture only for explicit debug sessions, sampled incidents, or tightly governed short-retention paths. When full content is unnecessary, store hashes or fingerprints so teams can compare runs without copying sensitive material everywhere.
Log content by policy tier, not by accident.
A few failure patterns show up constantly:
Observability without correlation IDs is just expensive noise.
Use this as the minimum bar before you call an agent system debuggable:
That is the real threshold. Not perfect telemetry. Reconstructable operations.
Every agent run should be reconstructable, explainable, and reviewable.
If your team can answer who, what, which version, which tool, which context, and what failed from one trace, you are in decent shape. If not, debugging will turn into guesswork the first time an agent does something expensive, risky, or weird.
That is the practical standard worth building toward.
This article was researched and drafted with AI assistance, then edited and structured for publication by a human. Logging policy, retention, and redaction decisions should still be set by the team operating the system.