AI Agent Observability: Traces, Evals, and Cost Tracking
Observability for AI agents means three overlapping capabilities most enterprises build in the wrong order: tracing every step an agent takes so a wrong output is diagnosable rather than a mystery, running evaluations continuously against production traffic rather than once before launch, and tracking cost per completed task with enough granularity to catch a runaway loop or a model upgrade that quietly triples spend. Teams that build a chat interface first and observability later routinely discover, months in, that they cannot answer basic questions after an incident: which tool call produced the bad data, whether accuracy has drifted since launch, or why last month's inference bill doubled.
Tracing: Recording What the Agent Actually Did
A trace is the complete record of one agent run: every model call with its prompt and response, every tool call with its arguments and result, the reasoning or plan if the architecture produces one, timestamps, and a correlation ID linking the trace to whatever downstream system the agent affected. Without this, debugging a bad output means asking the agent to explain itself after the fact, which produces a plausible-sounding justification that may have nothing to do with what actually happened during the original run. Store traces for at least as long as the underlying business record they affected, and make them searchable by input, output, tool called, and correlation ID, not just by timestamp, since most debugging starts from a downstream complaint, not a trace ID.
- Capture every model call, tool call, and intermediate reasoning step with timestamps in one trace
- Correlation ID linking each trace to the downstream record or transaction it affected
- Retain traces at least as long as the underlying business record, longer for regulated industries
- Index traces by input, output, and tool called so debugging can start from a complaint, not a trace ID
Evals in Production, Not Just Before Launch
A pre-launch evaluation against a golden test set tells you the agent worked on the day you tested it, and nothing about whether it still works three months later after an upstream data source changed shape or a model provider silently updated a model behind a floating alias. Continuous evaluation reruns the golden test set on a schedule, and separately samples live production traffic for human or model-graded review, so drift is caught by a scheduled check rather than a customer complaint. Alert on relative change in eval scores, not just absolute thresholds, since a five-point drop from a previously stable 95 percent is a stronger signal than a single below-threshold reading with no trend behind it.
- Rerun the golden evaluation set on a fixed schedule (daily or weekly, not just pre-launch)
- Sample live production traffic separately for human or LLM-graded review to catch cases the golden set misses
- Alert on relative change (a sudden drop from baseline) as well as absolute threshold breaches
- Version the evaluation set alongside the agent so a score change can be traced to agent or test-set changes
Cost Tracking Down to the Task, Not the Aggregate Bill
An aggregate monthly inference bill tells you almost nothing actionable; cost per completed task, broken out by task type and including retries, tool calls, and any secondary model used for verification, tells you where money is actually going and whether a specific task type is economically viable at all. Track cost trend per task type over time, since a model provider price change, an unnoticed prompt bloat, or a tool loop running longer than intended will each show up as a slow or sudden shift in this number well before it appears as a surprise on the monthly invoice. Set a per-task cost ceiling enforced by the harness, not just monitored after the fact, so a single runaway task cannot silently accumulate a large bill before anyone notices.
Building the Observability Stack Without Overbuilding It
Most enterprises do not need a bespoke observability platform; open-source and commercial LLM observability tools now cover tracing, eval orchestration, and cost tracking adequately for the majority of use cases, and the engineering effort is better spent on the evaluation content itself, building a real golden set from your own data, than on tooling. The exception is regulated environments where trace and eval data cannot leave the network, which usually rules out hosted observability SaaS entirely and pushes the stack to a self-hosted deployment alongside the agent and model infrastructure it is monitoring.
How Netray Instruments Observability From Day One
Netray ships every agent with tracing, a versioned golden evaluation set, and per-task cost tracking as standard delivery artifacts, not an add-on requested after an incident, because a client cannot operate an agent they cannot see inside. For on-premises deployments, the entire observability stack, traces, eval scoring, cost dashboards, runs inside the customer's network alongside the model itself, since sending trace data (which typically contains the same sensitive content as the original task) to a third-party SaaS observability platform defeats the purpose of deploying on-prem in the first place. We set relative-change alerting from launch so drift surfaces as a dashboard signal, not a support ticket three months later.
Frequently Asked Questions
What should be included in an AI agent trace?
Every model call with its prompt and response, every tool call with arguments and result, any intermediate plan or reasoning the architecture produces, timestamps for each step, and a correlation ID linking the trace to whatever downstream record or transaction the agent affected. Without a complete trace, debugging a bad output relies on asking the agent to explain itself after the fact, which produces a plausible answer that may not reflect what actually happened.
How often should AI agent evaluations run in production?
Continuously, not just once before launch. Rerun the golden evaluation set on a fixed schedule, daily or weekly depending on task volume, and separately sample live production traffic for human or model-graded review. Alert on relative change from baseline as well as absolute thresholds, since a gradual drop from a stable score is often a stronger drift signal than a single reading that crosses a fixed line.
Why does AI agent inference cost track poorly at the aggregate bill level?
An aggregate monthly bill hides which task types are actually driving spend, whether retries and tool calls are inflating cost, and whether a specific task type is even economically viable. Track cost per completed task broken out by task type instead, and set a per-task cost ceiling enforced by the agent harness itself so a runaway loop cannot silently accumulate a large bill before it is noticed on the next invoice.
Key Takeaways
- 1Tracing: Recording What the Agent Actually Did: A trace is the complete record of one agent run: every model call with its prompt and response, every tool call with its arguments and result, the reasoning or plan if the architecture produces one, timestamps, and a correlation ID linking the trace to whatever downstream system the agent affected. Without this, debugging a bad output means asking the agent to explain itself after the fact, which produces a plausible-sounding justification that may have nothing to do with what actually happened during the original run.
- 2Evals in Production, Not Just Before Launch: A pre-launch evaluation against a golden test set tells you the agent worked on the day you tested it, and nothing about whether it still works three months later after an upstream data source changed shape or a model provider silently updated a model behind a floating alias. Continuous evaluation reruns the golden test set on a schedule, and separately samples live production traffic for human or model-graded review, so drift is caught by a scheduled check rather than a customer complaint.
- 3Cost Tracking Down to the Task, Not the Aggregate Bill: An aggregate monthly inference bill tells you almost nothing actionable; cost per completed task, broken out by task type and including retries, tool calls, and any secondary model used for verification, tells you where money is actually going and whether a specific task type is economically viable at all. Track cost trend per task type over time, since a model provider price change, an unnoticed prompt bloat, or a tool loop running longer than intended will each show up as a slow or sudden shift in this number well before it appears as a surprise on the monthly invoice.
Put this into numbers
Free interactive tools for exactly this problem. No signup to use them.
AI Agent vs Workflow Automation Selector
Answer ten questions about your use case to find out whether it is better suited to deterministic workflow automation, an AI agent, or a hybrid of both.
Free ToolHuman-in-the-Loop Cost Calculator
Calculate the true monthly cost of human review and rework layered on top of AI agent output, based on review rate, review time, and rework rate.
Free ToolMCP Integration Effort Estimator
Estimate the engineering hours and cost to build MCP servers connecting AI agents to your enterprise systems, based on system count, integration complexity, and auth model.
Terms used in this article
Running AI agents in production without a clear answer to what happened on a specific bad output? Netray will instrument tracing, continuous evals, and cost tracking that runs inside your own infrastructure.
Related Resources
How to Evaluate an AI Agent Before You Trust It
An AI agent evaluation framework for manufacturers: golden test sets, accuracy thresholds, latency budgets, and escalation rules before production.
AI & AutomationMulti-Agent Orchestration Patterns (and When One Agent Is Enough)
Multi-agent orchestration patterns for the enterprise, and the honest case for when a single agent outperforms a multi-agent system on cost and reliability.
AI & AutomationAgentic Workflow Patterns for the Enterprise in 2026
Agentic workflow patterns for 2026: planner-executor, tool loops, and structured outputs, with a framework for choosing the right pattern for your use case.