Yesterday we made every call non-deterministic by design (reasoning models, variable thinking budgets, parallel sampling). The hidden cost of that: you can no longer ship and forget. The discipline that turns “sometimes brilliant, sometimes broken” into a product you can sell to a Fortune 500 is observability — tracing every span, evaluating every output, alerting on every regression. This is the operational layer of the agent stack.
Core Concept
From Logs to Traces — Why Agents Need a New Operational Stack
Classical microservices observability rests on three pillars: logs (what happened), metrics (how much / how fast), and traces (the causal path through a distributed call). For agents, those three pillars are necessary but nowhere near sufficient. An agent run also has semantic state (what the LLM was thinking about), quality signals (was the output correct?), and tool-mediated side effects (the agent updated a CRM record — was that the right record?). Agent observability is the practice of capturing all of this in a way you can query, alert on, and replay.
Analogy first. Treat each agent run like a flight data recorder. A traditional API request is a single voltage reading: in, out, status code. An agent run is a flight: takeoff, climb, three weather diversions, two passenger inputs, one tool malfunction, landing. If you only log “flight completed” you have no idea whether the captain made good decisions or got lucky. You need the full cockpit voice recorder, the autopilot trace, and an independent reviewer scoring each decision afterwards. That’s a trace plus an online eval.
Mechanism. The dominant data model is borrowed from distributed-tracing standards (OpenTelemetry) and extended by AI-specific conventions. A trace represents one end-to-end agent run. A trace is a tree of spans, where each span is a unit of work with a start time, an end time, a parent, and key/value attributes. The standard span types for agents now include: llm (a model call, with prompt, response, tokens, model name), tool (an external API call with input args and output), retriever (a RAG fetch with query, retrieved docs, scores), chain (a programmatic step), and agent (the outer loop wrapping all of it). The OpenTelemetry GenAI semantic conventions, in active development through 2025-2026, are standardizing the attribute names (gen_ai.request.model, gen_ai.usage.input_tokens, etc.) so traces become portable across vendors.
The three observability layers for agents
Tracing — the structural layer
What did the agent do, in what order, and how long did each step take?
A nested tree of spans capturing every LLM call, tool invocation, retriever hit, and sub-agent message. Auto-instrumentation libraries (OpenInference, OpenLLMetry) wrap framework SDKs so you don’t hand-roll spans. The output is a trace_id you can paste into your dashboard and replay the run end-to-end — including the full prompt, full response, and tool I/O for each step.
Evals — the quality layer
Was the output any good? On what dimensions? Compared to what?
Two flavours. Offline evals run a curated dataset against your agent on every change — like unit tests for behaviour. Online evals run as a sidecar on production traffic, scoring every real interaction with a rubric. The dominant scoring engine is LLM-as-a-judge (Zheng et al., NeurIPS 2023), where a strong model judges your agent’s output against a structured rubric. New in 2025: Agent-as-a-Judge (Zhuge et al.) — the judge is itself an agent, with tools, that can verify code by running it.
Telemetry — the operational layer
What's drifting, what's failing, and which user is affected?
Cost-per-trace, p50/p95/p99 latency, tool error rate, eval-score distribution over time, prompt-version-pinned regressions. Aggregates over traces and evals to drive alerting. This is where AgentOps platforms (Langfuse, Phoenix, AgentOps, W&B Weave) compete on dashboards, slicing, drift detection, and integration with paging systems.
Why this is harder than classic APM
A typical web request has a binary outcome (200 or 5xx) and bounded shapes. An agent run has a continuous outcome (“how good was the answer?”), unbounded text inputs and outputs, and a long-tailed cost / latency distribution thanks to reasoning budgets and tool retries. You can’t define an SLO on http.status_code; you have to define it on a learned signal — a judge model or a regex on a rubric’s pass criteria. Pass^k (from τ-bench) generalizes pass@k for agents: you run the same task k times and report the fraction where all k attempts succeed. That’s your reliability number.
The other compounding problem is multi-agent observability. When agents call sub-agents call tools call other agents, your trace tree fans out by an order of magnitude. Conventional dashboards drown. The newer pattern (W3C trace context propagation through MCP / A2A protocols, plus OpenInference semconv) preserves a single root trace_id across boundaries so you can ask “what did Agent A do that made Agent B fail?” without stitching logs by hand.
# Anatomy of one agent run as a trace
trace = run-7e2c (root, 12.4s, $0.043, eval=0.81)
|— span: agent.plan (llm, 2.1s, 1.2K in, 480 out)
|— span: tool.search_docs (retriever, 0.4s, 6 hits)
|— span: agent.reason (llm, 5.8s, 12K thinking, 320 out)
|— span: tool.create_ticket (api, 0.9s, side-effect=true)
|— span: agent.verify (llm, 3.0s, 4K thinking)
|— span: judge.online_eval (llm, async, score=0.81)
// 1 trace, 6 spans, 2 LLM, 2 tool, 1 retriever, 1 judge
A useful test: if a customer complains “the agent did the wrong thing for ticket #4823 yesterday at 3:14 pm”, can your engineer answer in under five minutes by pasting one ID into a search box? If yes, you have observability. If no, you have logs.
Papers to Know
Four Papers That Built the AgentOps Vocabulary
Published
Seminal
NeurIPS 2023 Datasets & Benchmarks Track
Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
Lianmin Zheng, Wei-Lin Chiang, Ying Sheng, et al. (UC Berkeley, UCSD, CMU, Stanford) · arXiv 2306.05685
Established that a strong LLM (GPT-4) can match human majority preference at over 80% on open-ended chat — the same agreement rate as two humans agreeing with each other. Introduced MT-Bench (a multi-turn benchmark) and Chatbot Arena (crowdsourced anonymous head-to-head). Catalogued the failure modes of LLM judges: position bias, verbosity bias, self-enhancement bias.
Why it matters: Made “LLM-as-a-judge” the default scoring engine for online evals. Every observability platform now ships a built-in judge feature; this paper’s biases are the ones you must mitigate (randomize order, normalize length, never use the same model to judge itself in self-play).
arXiv 2306.05685
Recent
arXiv preprint, 2024 (Sierra)
τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains
Shunyu Yao, Noah Shinn, Pedram Razavi, Karthik Narasimhan (Sierra) · arXiv 2406.12045
Built a benchmark with realistic databases, domain APIs, and a simulated user, scored by comparing the final database state against an annotated goal state. Showed even gpt-4o succeeds on under 50% of retail tasks and is wildly inconsistent (pass^8 under 25%). Introduced the pass^k metric: probability that all k independent attempts succeed.
Why it matters: Reframed agent eval from average accuracy (which papers over unreliable systems) to reliability under repeated trials. Pass^k is now the metric every serious observability platform exposes by default; if your dashboard only shows pass@1, you’re lying to yourself.
arXiv 2406.12045
Recent
arXiv preprint, 2024 (Meta AI / KAUST)
Agent-as-a-Judge: Evaluate Agents with Agents
Mingchen Zhuge, Changsheng Zhao, Dylan Ashley, et al. (Meta AI, KAUST — Jürgen Schmidhuber) · arXiv 2410.10934
Argued that LLM-as-a-judge collapses the entire trajectory into one final-answer score, ignoring the step-by-step nature of agentic work. Replaced the judge with another agent that can plan, run code, and inspect intermediate state. On a code-generation eval (DevAI, 55 dev tasks) the agent-judge matched human reviewers far better than an LLM-judge baseline at a fraction of the cost.
Why it matters: Online evals are starting to look agentic themselves. The implication for botlearn.ai: your judge stack will become a build-vs-buy decision on its own — the agent that grades student exercises is its own product surface, not a config flag on Langfuse.
arXiv 2410.10934
arXiv preprint
2024 (CSIRO Data61)
A Taxonomy of AgentOps for Enabling Observability of Foundation Model based Agents
Liming Zhu, Qinghua Lu, Liming Dong et al. (CSIRO Data61) · arXiv 2411.05285
A systematic mapping study of seventeen AgentOps tools that produces a taxonomy of the artefacts and data that should be traced across an agent’s lifecycle — design, deployment, monitoring, and decommissioning. Names what the OpenTelemetry GenAI semconv group has been formalising in parallel: prompt, plan, tool I/O, memory state, environment side-effect, and outcome attribution.
Why it matters: Gives you the canonical checklist for what your observability stack must capture. If your platform doesn’t have a column for any of the taxonomy nodes, you have a blind spot — and that’s usually where the gnarly post-mortems live.
arXiv 2411.05285
Community Pulse
What the People Building This Are Saying
Harrison Chase — LangChain (April 2026)
Chase has argued through 2026 that observability and evaluation are not two products but one operational discipline: the trace of an agent run is the dataset for the next eval, and the next eval result is the alert for the next trace.
Position summarised from the LangChain post “Agent Observability Powers Agent Evaluation” and “How we build evals for Deep Agents” (Mar 26, 2026, co-authored by Trivedy, Daugherty, Yurtsev, and Chase). Source: blog.langchain.com.
Andrej Karpathy — X / Twitter (Dec 27, 2025)
In a long thread on the velocity of new agent infrastructure, Karpathy listed observability alongside agents, sub-agents, prompts, contexts, memory, modes, permissions, tools, plugins, skills, hooks, MCP, LSP, slash commands, workflows, and IDE integrations — and noted he had never felt so far behind on tooling.
Paraphrased from his Dec 27, 2025 X post. The signal: tracing is no longer optional infra — it’s a primitive on the same shelf as “tool” and “memory.”
Greg Brockman — X / Twitter (2026)
Brockman has framed the two big themes of AI in 2026 as enterprise agent adoption and scientific acceleration — both of which raise the bar on observability, since enterprise procurement and scientific reproducibility both demand auditable run histories.
Paraphrased from his 2026 thesis post on X. The product implication: every enterprise agent RFP now has an auditability column.
Simon Willison — simonwillison.net (2026)
Willison has consistently pushed the line that the bottleneck for shipping useful agents in 2026 is not raw model capability but the willingness to invest in evals — specifically, the unsexy, domain-specific datasets that let you tell whether last week’s prompt change broke anything.
Position aggregated from his “evals” tag posts and his 2026 LLM predictions piece. The takeaway: evals are a moat, not a chore.
The vendor-neutral pattern that’s winning in 2026: instrument with OpenInference / OpenLLMetry, route via OTLP, store in your platform of choice. Avoid platforms whose pricing only makes sense if you forklift your tracing in.