AI agent observability: the signals that reveal what your system is really doing

At 9:42 on a Tuesday morning, my kitchen table had become an incident room. A laptop showed a support agent stuck in a loop, a mug of cold coffee sat beside it, and three browser tabs disagreed about what had happened. AI agent observability is how you turn that chaos into a trace you can actually follow. You need to see the user request, every model call, tool action, retry, handoff, and final answer as one connected system.

The hard part is not collecting more logs. It is deciding which signals explain behavior. After building two live multi-model AI platforms, Ziggyloo and Zentoko, I keep seeing the same pattern: teams monitor uptime and latency, then discover the agent was technically healthy while doing the wrong work for ten minutes.

That gap is where LLM observability matters. A green status page tells you the service responded. It cannot tell you the agent selected the wrong tool, retrieved stale policy text, spent 80% of its budget on retries, or delivered a confident answer after a failed database lookup.

Start with the agent's actual journey

An AI agent is not one request. It is a chain of decisions made across models, tools, memory, queues, databases, and people. If your monitoring treats that chain as a single API call, you lose the evidence you need when something goes wrong.

Think of each run as a production journey with a beginning, a set of turns, and an ending. The trace should let you move from the customer's request down into every meaningful step without opening six unrelated dashboards.

For each run, capture:

• A stable run ID that follows the request across services
• The user intent, tenant, workflow name, and environment
• Every model call, including model name, version, temperature, token counts, and response status
• Every tool call, including arguments, result size, duration, and error type
• Retrieval details such as query text, document IDs, scores, and filter conditions
• State changes, retries, pauses, handoffs, and the final response

The stable run ID sounds boring. It is also the difference between an incident you can explain and one you can only describe with hand gestures.

At a minimum, your trace needs parent-child relationships. The user request is the parent span. The planner call, retrieval operation, tool execution, and response synthesis are child spans. A retry should be visible as another attempt under the same operation, not as a new mystery request floating elsewhere in your system.

This is where OpenTelemetry can help. It gives you a common way to represent traces and spans across services, while tools like Langfuse, Arize Phoenix, Helicone, and Datadog let you inspect LLM-specific data. The product choice matters less than the structure. If your trace cannot answer "what did the agent know at this point, and what did it do next?" it is not giving you enough.

Here's the part most people miss: the conventional advice is to log everything. That sounds sensible until a production agent records full customer messages, complete retrieved documents, private tool arguments, and every internal prompt into one expensive bucket. You do not need every byte. You need the evidence that explains a decision, with redaction and retention rules that match the data.

So the deeper lesson is simple: design observability around the agent's journey, not around the vendor API that happened to receive the request.

The signals that expose bad behavior

AI application metrics should answer more than "is the service up?" They should tell you whether the system is making good decisions under real conditions.

I group the signals into four areas. They overlap, but each catches a different class of failure.

Behavior signals

Behavior signals tell you what the agent decided to do.

Track:

• Tool selection rate by intent and workflow
• Invalid tool-call rate
• Tool-call sequence and loop depth
• Handoff rate to a person or fallback workflow
• Completion rate without an unplanned retry
• Answer refusal rate and escalation reason
• Percentage of runs that end without a usable response

Suppose a billing agent should call a refund tool for a refund request. If it calls the policy search tool instead, latency may stay normal and the HTTP status may be 200. The user still has a bad experience. Tool selection rate by intent will surface that drift much faster than average response time.

Loop depth is another useful signal. An agent that normally completes in four steps but suddenly averages eleven is telling you something. The cause might be a malformed tool result, a prompt change, a missing state update, or a model overreacting to an error. The average can hide this, so inspect the distribution and the longest runs.

Quality signals

Quality is harder to measure, but ignoring it does not make it less real. Connect production traces to evaluation results wherever you can.

Useful quality signals include:

• Groundedness score for answers that rely on retrieved material
• Citation or source-use rate where citations are required
• Structured-output validation rate
• Human correction rate
• Task completion rate measured against the user's actual goal
• Regression rate after a prompt, model, retrieval, or tool change

A structured-output validation rate of 99% can still conceal a product failure if the remaining 1% hits your largest customer or a payment workflow. Slice the data by intent, customer segment, model, document collection, and tool path.

I have found that human correction rate is especially revealing. In a review workflow, count how often someone edits the agent's proposed answer, changes a field, or rejects the recommendation. The correction is not just a quality label, it is a map of where the system's assumptions diverge from the operator's expectations.

Do not reduce quality to one score. A single score is convenient, and convenience has a habit of becoming policy. Keep the underlying events available so you can inspect why a run passed or failed.

Reliability signals

Reliability signals show whether the system can complete work consistently.

Watch:

• Success rate by workflow, not only across the whole product
• Timeout rate by model and tool
• Retry count and retry reason
• Queue age for background runs
• Rate-limit responses from model and tool providers
• Partial completion rate
• Duplicate side-effect rate for actions such as sending, updating, or charging

A 99.5% overall success rate may sound strong. If the failed 0.5% all comes from the workflow that handles account cancellation, it is not strong enough for that workflow. Break the number down until the responsible team can act on it.

Cost signals

Cost is behavior with a price tag. Track it at the run and workflow level, not only at the monthly invoice.

Useful cost signals include:

• Input and output tokens by model and workflow
• Cost per completed task
• Cost of failed and retried runs
• Cost by tenant or customer segment
• Retrieval volume and reranking cost
• Tool calls per successful outcome
• Percentage of runs that exceed the expected budget

A run that costs $0.08 may be fine for a high-value workflow. The same run is a problem if it happens 40 times during a retry storm. Tie cost to outcome. Cost per successful task tells you far more than raw token spend. (And yes, that distinction matters the moment you try to explain the bill to a finance team.)

Build a signal path, not a dashboard museum

A common failure in AI production monitoring is collecting useful data and burying it under twelve dashboards. The team has a latency chart, a model chart, a retrieval chart, a billing chart, and a tool chart. During an incident, someone asks which request caused the bad answer. Everyone starts searching.

I prefer one primary run view with links out to specialized detail. The top layer should answer four questions quickly:

• What was the user trying to accomplish?
• What path did the agent take?
• Where did the path slow down, fail, or repeat?
• Did the user receive a correct and complete result?

Then make the important transitions visible. A model span should link to its prompt version and model configuration. A retrieval span should link to the selected documents and scores. A tool span should show sanitized arguments, result status, and downstream request ID. A handoff should show why the agent stopped and what context the human received.

This is your Signal Path. It is the route from user intent to system action to user outcome. Once you define it, every event has a job. It either explains a decision, measures a risk, or supports a repair.

Do not sample away the failures. A low-cost sampling policy can keep most successful traces while retaining every timeout, tool error, safety block, high-cost run, and human correction. Keep a small random sample of successful runs for comparison too, because without that baseline you cannot tell whether an unusual failure is truly unusual.

Privacy belongs in the design from the beginning. Redact payment data, passwords, access tokens, and unnecessary personal information before data reaches the observability store. Hash identifiers when you need to connect events without exposing raw values. Set retention by use case. Debugging data does not need to live forever.

And make traces searchable by product terms. "Workflow equals refund" is more useful to an operator than "service equals agent-runtime." Technical labels help engineers, but operators think in customer goals.

Turn observability into an operating habit

Instrumentation alone does not improve a system. Someone has to look at the signals, decide what matters, and change the product.

Create a small weekly review of production runs. Pick a sample of successful tasks, failed tasks, expensive tasks, and human-corrected tasks. Review the trace alongside the final outcome. You are looking for repeated causes, not isolated weirdness.

A useful review asks:

• Did the agent have the information it needed?
• Did it choose the right next action?
• Did the tool return a result the model could use?
• Did the system recover when a step failed?
• Did the final answer match the user's real goal?

Link each recurring issue to an evaluation. If an agent repeatedly picks the wrong tool for a known intent, add that case to the eval set. If retrieval returns an outdated policy, fix the corpus and add a freshness check. If the model invents a result after a tool timeout, add a test that requires an explicit failure state.

This creates an Incident-to-Eval Loop. Production behavior supplies real cases. Evals prevent the same case from disappearing after a quick patch. The loop is where AI production monitoring becomes product work instead of passive reporting.

Set alerts around changes in behavior, not only absolute thresholds. A 20% increase in tool retries may matter even when the total stays below your old alert limit. A sudden drop in citation use may matter even when answer latency improves. Baselines should be segmented by workflow, because normal behavior differs across tasks.

What I'm telling you is that the distance between a system error and a user-visible failure is one of the most important things to track. A failed retrieval call may be recoverable. A wrong account update is not. Rank alerts by blast radius, not by how dramatic the log message looks.

The practical starting point is small. Instrument one workflow deeply. Give every run a trace. Capture model, retrieval, tool, retry, cost, and outcome data. Review ten good runs and ten bad ones. Then fix the missing signal you noticed.

You do not need a perfect observability platform before launch. You need enough visibility to learn without guessing. That is a fair standard, and most teams can meet it.

FAQ

What is AI agent observability?

AI agent observability is the practice of capturing and connecting the signals that explain an agent's behavior in production. It includes traces for model calls, tool use, retrieval, memory, retries, handoffs, latency, cost, and final outcomes.

What should an agent trace include?

An agent trace should include a stable run ID, user intent, model calls, prompts or prompt references, tool arguments and results, retrieval details, retries, state changes, errors, and the final outcome. Sensitive data should be redacted before storage.

How is LLM observability different from normal application monitoring?

Normal application monitoring tells you whether a service returned an error or exceeded a latency limit. LLM observability also needs to explain probabilistic decisions, token usage, retrieved context, tool selection, response quality, and whether the answer actually solved the user's task.

Which AI application metrics should I monitor first?

Start with task completion rate, tool selection accuracy, retry rate, failure rate by workflow, latency, cost per successful task, and human correction rate. Add retrieval quality and groundedness when the agent depends on external knowledge.

A production agent can be available, fast, and wrong. If you have ever stared at a clean log while a customer reports an impossible answer, you are not missing some obvious engineering trick. The system was simply telling you too little.

Start with one real workflow and make its journey visible. Once you can see what the agent saw, chose, tried, and returned, improvement stops being a guessing game.

The model is only one part of the product. The trace is how you learn what the whole product is actually doing.