What is AI agent observability?

AI agent observability is the practice of watching production AI agents the way you would watch any other production system: knowing what each one costs, whether it is still running on schedule, and whether the output it produces is still good. It overlaps with general LLM observability, but the unit of analysis is the agent run, not the API call.

A web service crashes loudly. An agent rarely does.

Traditional APM tools (Datadog, New Relic, Sentry) track requests, latency, exceptions, CPU. Those failure modes are loud. An AI agent fails in three quieter ways, and none of them light up an APM dashboard. The agent quietly stops firing. The token bill creeps. The output gradually gets worse. By the time someone notices, the gap is weeks old.

The three failure modes

  • Silent breakage. A scheduled agent stops firing after a deploy. The cron job was removed during a refactor; no exception was thrown. The team finds out eleven days later when a customer complains the dashboard is stale. How to catch a silent agent walks through the detection.
  • Cost without attribution. The provider bill jumps from £2,400 to £8,900 in a month. The team has one API key shared across every agent. Three engineers spend a day bisecting which agent ate the spike. We reconstructed this incident in the anatomy of an £8,900 token bill.
  • Quality drift. A prompt change ships on Monday. By Wednesday the agent's average rubric score has dropped from 4.2 to 3.8. Support tickets arrive on Friday. The rollback fixes the future. Nothing fixes the past. Quality drift is the longer write-up.

All three were on the dashboard the whole time, as the absence of a run, a line pulling away from its neighbours, and a distribution sliding. Three blind spots puts real numbers on each.

What an agent observability stack actually captures.

Everything derives from one record per agent run, with the steps inside it. The table is the complete list; a team that records these seven signals can answer every question in the rest of this page.

per run · what to record 7 signals
SignalWhat it answersWhere it comes from
Run status and timingDid it run, did it finish, how long did it takeSDK wraps the run; client-side run ID before any network call
Model callsWhich provider and model, how many input, output and cached tokensAuto-captured from the provider client, or OpenTelemetry GenAI spans
Tool callsWhat the agent asked each tool and what came backSDK instrumentation or GenAI tool spans; payloads optional
Child runsWhat a whole customer request cost when one agent calls anotherParent run ID propagated to the sub-agent
TagsWhich customer and which feature this run servedSet in your code at run start; rollups are retroactive
ScheduleWhether a scheduled agent ran inside its expected windowCron expression and tolerance window per agent; a heartbeat for jobs that cannot host an SDK
OutputWas the result good, and is quality trending downFinal output recorded; checks and rubrics score it after the fact

Cost is deliberately not in the list. It is derived at ingest by pricing the token counts against a rate card, so the client never sends a cost number and a provider price change does not require a redeploy. The glossary defines each of these terms: agent run, parent run, schedule freshness, rate card.

Cost, monitoring, and quality. One event per run.

For every agent you put in production, three signals matter. They share a common primitive: one telemetry record per agent run, capturing inputs, outputs, tokens, cost, status, and timing. From that one record, the three views fall out naturally.

Cost attribution

  • Tokens broken down by agent, customer, and feature. Tag customer_id and feature at run start so rollups are retroactive. What is AI cost attribution? is the full definition.
  • Server-side pricing from a rate card per (provider, model). The SDK never sends a cost number; mistakes about your own bill are impossible.
  • Cache-aware accounting. Prompt-cache reads on Anthropic and OpenAI cached_tokens are priced separately from fresh input.
  • Cost-per-successful-run as the headline metric, because cost over all runs hides loops and failures.
  • Anomaly detection on a 14-day baseline so a doubled spend pages you before the invoice lands.

Live monitoring + schedule freshness

  • Every finished run lands in the dashboard within a second, with status, latency, cost, and error signature.
  • Scheduled agents have a cron expression and a tolerance window. A missed run pages the on-call route within the grace period.
  • p95 latency rolled up across 24h / 7d / 30d. A sudden move usually means a model swap or a longer prompt. Why your agent's p99 is lying to you covers what the percentiles hide.
  • Every run lands with its status (success, failed, timeout), so a bad deploy is obvious at a glance.
  • Run-level traces. Tool calls, LLM calls, parent and child runs, and the actual output. Step through any run.

Quality scoring with drift detection

  • Deterministic checks at zero LLM cost: JSON schema, regex, length bounds, required fields, tool-call assertions.
  • LLM-as-judge runs a rubric written in plain English against a sampled subset of runs, at a sample rate you set per rubric. LLM-as-judge in production covers where it goes wrong.
  • Rubric versioning. Every edit creates a new version; scores are tagged with the version that generated them.
  • Drift detection on the distribution, not single scores. A single 2/5 is noise; the mean dropping from 4.2 to 3.8 over a week is signal.

The unit of analysis is the agent, not the API call.

Three categories of tool get sold for this job, and they watch three different things. APM watches the process. LLM observability watches the model call. AI agent observability watches the run: several model calls, a few tool calls and some control flow, rolled up into one record you can ask agent-level questions of.

apm · llm observability · agent observability compared
QuestionAPMLLM observabilityAI agent observability
Unit of analysisRequest, process, hostOne model callOne agent run, with its steps
Failure it catchesExceptions, 5xx, latency, CPUSlow or errored calls, token spikesMissed runs, cost pulling away from baseline, output getting worse
Cost viewInfrastructureTokens per callCost per agent, customer and feature, priced from a rate card
Quality viewNoneManual trace review, offline evalsChecks on every run, rubrics on a sample, drift on the distribution
A 200 with a wrong answerGreenGreenFlagged by the evaluation
ExamplesDatadog, New Relic, SentryLangfuse, LangSmith, Helicone, ArizeAgent Ping

The categories overlap at the edges. Datadog and Sentry now ship LLM views, and the tracing tools are adding agent concepts. Beyond Sentry and Datadog and Sentry for AI agents draw the boundary in detail.

Where OpenTelemetry fits, and where it stops.

OpenTelemetry is the vendor-neutral way to get the signals out of your agent. Its GenAI semantic conventions define how a model call and a tool call are recorded as spans, with standard attribute names for provider, model, token usage and tool name, and OTLP carries them to any backend that speaks it. If your stack already exports traces, agent observability can ride on the same pipeline.

What the conventions leave to the backend

  • Cost. A span carries token counts, not money. Someone has to price them against a rate card and keep the rate card current.
  • Absence. A scheduled agent that never ran produces no spans. Detecting the gap needs a schedule to compare against, which no trace can carry.
  • Quality. The output is an attribute on a span. Whether it was any good is a judgment the backend has to make, with checks and rubrics.

Agent Ping accepts OTLP directly and maps GenAI spans to runs and steps, so a team already on OpenTelemetry keeps its instrumentation and gets the three views on top. OpenTelemetry for AI agents has the attribute list and a code sample; the OpenTelemetry integration docs cover the endpoint.

One event per run, captured at the edge. Everything else derives.

The smallest thing that works is a single event per agent run, captured by an SDK that never blocks the agent. From that event, the three views (Spend, Pulse, Verify) are derived. Most teams build a v0 of this themselves before deciding what to buy.

What the SDK looks like

example · python sdk 2 lines 
import agentping
agentping.init(api_key=os.environ['AGENTPING_API_KEY'])

with agentping.run('support-triage', customer_id='acme-corp') as run:
    response = agent.handle(ticket)
    run.set_output(response)

The run ID is generated client-side before any network call. Telemetry sends on a background thread with a 2-second hard timeout. If the service is unreachable, the agent runs as if no SDK is installed. Per-framework setup is in the guides: LangGraph, CrewAI, the OpenAI Agents SDK, Vercel AI SDK, n8n and the rest.

What's in the run event

  • run_id (client-generated UUIDv7, available before any network call)
  • agent_id, team_id, optional customer_id and feature tags
  • started_at / finished_at (client time) and received_at (server time)
  • status: success / fail / timeout
  • Per-provider call records: provider, model, input_tokens, output_tokens, cached_tokens
  • Tool calls, child run IDs (for multi-agent traces), final output

The tools, by what they were built for.

Most of the market started somewhere else and added agents later. Knowing the starting point tells you what each tool is good at before you read a feature list.

  • Tracing-first. Langfuse, LangSmith, Helicone and Arize started as LLM call tracers and prompt tooling for the development loop. Excellent for stepping through one trace; agent-level alerting, cost per customer and schedule monitoring are later additions or absent.
  • Eval-first. Braintrust and similar platforms started with offline evaluation and scorers you write. Strong on quality in development; production monitoring is the add-on.
  • Session replay. AgentOps records a Python agent session so you can replay it after the fact. Debugging-oriented; no judgment of output quality.
  • APM add-ons. Datadog and Sentry added LLM and agent views to existing platforms. Right if you are already paying for them and want traces in one place; cost attribution and quality are thin.
  • Run-first. Agent Ping starts from the production run and the three questions above: what did it cost, did it run, was it good. Alerting on degradation is the point, not the trace viewer.

The best AI agent monitoring tools in 2026 goes through each with pricing and overhead; the comparison pages linked above take them one at a time.

Before an agent goes live, six things to be true.

  • Every run produces one record with a client-generated ID, a status and token counts, and the SDK cannot block or crash the agent.
  • The run is tagged with the customer and the feature where the code knows them, so cost per customer is a query rather than a project.
  • Every scheduled agent has a schedule and a tolerance window registered, and a missed run pages a person.
  • Each agent has a spend baseline and an alert on deviation from it, not just a monthly budget.
  • Deterministic checks run on every output, and a rubric scores a sample, with drift alerting on the distribution.
  • Someone owns the alert route, and the first page has been tested end to end.

The longer version, with the questions to ask of each item, is the production-readiness checklist for AI agents.

Is AI agent observability just LLM monitoring under a new name?
No. LLM monitoring is about the API call: tokens, latency, prompt content. AI agent observability is one level up. The agent is the entity that matters and the run is the unit of analysis. An agent may call zero or fifty LLMs during a single run, and the question is whether the agent did its job, not whether each call was fast.
What should an AI agent observability tool capture?
One record per agent run, and inside it the steps: every model call with provider, model and token counts, every tool call with what was asked and what came back, child runs when one agent calls another, timing, final status and the output itself. From that record come the three views that matter in production: cost per agent, customer and feature; whether scheduled agents actually ran; and whether output quality is holding. Prompt text is optional and many teams keep it out.
Do I need a tool, or can I build this myself?
You can build it. The primitive is one event per agent run capturing inputs, outputs, tokens, cost, and timing. Most teams find the build cost (ingest pipeline, rate card per provider and model, alert routing, dashboard, SDKs in every language they use) exceeds the cost of buying. The non-blocking SDK is harder to write correctly than it looks.
How is this different from APM like Datadog or Sentry?
APM watches exceptions, latency, CPU, request counts. An AI agent rarely throws an exception when it is broken; it returns a wrong answer with the same confidence as a right one. APM stays green. Agent observability watches the agent itself: did it run, did it cost what we expected, and was the output still good.
Does OpenTelemetry cover AI agent observability?
Partly. The OpenTelemetry GenAI semantic conventions define how to record model calls and tool calls as spans, with standard attribute names for provider, model and token usage, and OTLP gives you a vendor-neutral way to ship them. What the conventions do not define is what to do with the spans: pricing them, noticing that a scheduled agent never produced any, or judging whether the output was good. Those live in whatever backend receives the traces. Agent Ping accepts OTLP and does all three.
Does telemetry slow down my agent?
A well-written SDK never blocks the agent. The run ID is generated client-side before any network call, telemetry sends on a background thread, and the network call times out hard at 2 seconds. If the observability service is unreachable, the agent runs as if no SDK is installed.
What providers does cost attribution support?
Any provider you put on the rate card. Defaults ship for every Anthropic and OpenAI model. Cache-aware accounting (Anthropic prompt-cache reads, OpenAI cached_tokens) is priced separately from fresh input. Custom or self-hosted models work the same way once you add a rate card row.
How do you score quality without a labelled dataset?
Two layers. Deterministic checks (JSON schema, regex, length bounds, required fields, tool-call assertions) run on every output at zero LLM cost. LLM-as-judge runs your rubric, written in plain English, against a sampled subset of runs, and every rubric edit is versioned so scores stay comparable as the rubric evolves.

How Agent Ping implements each of the three.

The features page walks through Spend, Pulse, and Verify with the specifics: rate card, alert routes, rubrics, drift detection thresholds. The docs go one level deeper into the API and SDK contract.

Features → Spend docs → Pulse docs → Verify docs →