Evaluation Criteria for AI Agent Observability Platforms

An agent that fails usually makes a bad call quietly, without throwing an error, and everything downstream builds on top of it. It just makes a bad call, quietly, and everything downstream builds on top of it. That's the core problem this piece is about: the tools built to watch web servers and API endpoints for the last two decades were never built to catch that kind of failure, and evaluating an observability platform for AI agents means asking a different set of questions than the ones APM taught engineering teams to ask.

Agent observability as a different engineering problem than APM

APM answers one question well: did the request succeed? Latency, error rate, throughput, uptime. That question made sense for a system where a request comes in, some code runs, and a response goes out. An agent doesn't work that way. It routes between sub-agents, calls tools, retrieves context, chains reasoning steps together, and does this dozens or hundreds of times to answer a single question. The right question for that system isn't whether it succeeded, it's whether it made the right decisions, in the right order, using the right tools, for reasons that hold up under scrutiny.

A single bad decision early in that chain doesn't stay contained. It cascades through every step built on top of it, and by the time the final output lands on a user's screen, it can look completely reasonable while being built on a foundation that's wrong. Standard APM has nothing to say about this. It tracks whether the HTTP call succeeded and how long it took, but it has no way to surface a bad tool selection, a reasoning step that contradicted the one before it, or a workflow that branched down the wrong path three steps ago.

This isn't a hypothetical gap. Surveys on enterprise AI adoption put the share of organizations running agents in production at 57%, and when those same organizations are asked what's stopping wider deployment, 32% point to quality, not infrastructure cost, not latency, not uptime. Quality is the bottleneck, and quality at the decision layer is what conventional monitoring was never designed to see.

Agent failure taxonomy and the observability it requires

Most agent failures don't start with the model. They start with the harness around it: how the prompt specifies the task, how the tool schema is written, how memory gets retrieved, how one agent hands work off to another. Model capability matters less than people assume once you look closely at where things actually break.

UC Berkeley's MAST taxonomy on multi-agent LLM failures backs this up with hard numbers. Specification issues, meaning ambiguous or incomplete instructions baked into the prompt or task design, account for 41.8% of failures. Inter-agent misalignment, the breakdowns that happen at the handoff point between sub-agents, account for another 36.9%. Together these two categories account for the overwhelming majority of agent failures, and neither one appears in a log that only records whether the final output looked right.

A separate analysis of 1,675 agent runs across five different LLM models, from the OpenRCA research, found that hallucination in interpretation occurred in 71.2% of failure cases and incomplete exploration in 63.9%, and these rates held steady regardless of which model tier was running underneath. Swapping one model for another, or a smaller model for a bigger one, doesn't fix this. The failure lives in the workflow logic.

A 2025 arXiv preprint on multi-agent systems adds two more failure types: step repetition, where an agent redoes work it already did, showed up in 17.14% of failures, and a mismatch between the reasoning an agent stated and the action it actually took showed up in 13.98%. Both are invisible if you're only checking whether the final answer was correct. Catching them requires a trace of every step.

The five criteria that matter for agent observability

Multi-turn conversation tracing. The question to ask a vendor is whether the platform captures a full agent session, every turn, every tool call, every reasoning step, as one linked object. Agent failures are often emergent: no single span looks wrong on its own, but the trajectory across ten turns has drifted somewhere it shouldn't have. A platform worth using groups sessions natively and lets you replay the whole thing, rather than making you stitch it back together from scattered request logs.

Tool use and function calling observability. Tool invocations need to show up as first-class records, with their own inputs, outputs, latency, and failure states, not buried inside a larger LLM call. The most common silent agent failure is a tool called with the wrong parameters that still returns something plausible-looking, which then flows into a downstream response that passes every check while being wrong. Some production agents can execute 15 or more LLM calls across multiple chains to answer one user request; if tool capture isn't happening at each of those steps, most of the failure surface is invisible by default.

Non-deterministic path visualization. Agents don't take the same path twice. Feeding the same prompt in twice can produce two different tool call sequences, two different branching decisions, and two different intermediate outputs. Debugging that requires seeing the distribution of paths across runs, not staring at one trace and assuming it's representative. Look for session graphs or execution trees that let you compare trajectories side by side.

Pre-deployment simulation for multi-turn scenarios. Some failures only appear across a conversation: misalignment that compounds turn over turn, tool selection that drifts once the conversation gets long enough to put pressure on context. Single-turn eval suites, the industry default for a long time, are blind to this by construction. A platform that supports persona-based simulation, and lets you re-run from any step in a simulated conversation, is testing something closer to how the agent will actually be used. Notably, multi-turn simulation before deployment remains rare across the platforms in this space, which says something about how immature this part of the tooling still is.

Root cause attribution. This one is hard enough that it gets its own section below, but the short version: locating the step where something broke and diagnosing why it broke are two different problems, and most platforms are only built for the first one.

What separates platforms that do root cause attribution well

Finding the step where an agent went wrong isn't the same as knowing why. A bad prompt, a wrong task decomposition, and a logical deadlock between two sub-agents all produce failures that can look identical at the step where they occur, but they need completely different fixes. Most existing tooling stops at the first problem: it can point to the step, but it can't tell you what to do about it.

The R2Act research illustrates the gap concretely. Even the strongest RAG-based LLMs tested reached 91.4% to 99.7% accuracy at identifying which service was responsible for a failure, a diagnosis task. But recovery validity, meaning whether the fix applied afterward actually worked, sat at just 36.8% to 60.3%. Knowing where the fire started doesn't mean you know how to put it out.

What seems to close that gap is connecting attribution to recovery in a closed loop, rather than treating them as separate steps. On the GAIA benchmark, a closed-loop attribution-and-recovery approach repaired 13 of 73 failed tasks in a single rerun. A decoupled self-correction baseline, tested against the same failures, fixed between 4 and 6. Overall task accuracy on that benchmark went from 55.8% to 63.6% once attribution and recovery were tied together. The lesson here isn't subtle: correction applied without a grounded diagnosis of the root cause is closer to guessing than fixing, and the data backs that up directly.

Good attribution architecture tends to share a few traits. Every intermediate belief state that shaped a later decision gets captured as its own artifact, rather than being inferred after the fact from what went in and what came out. Causal graphs need to be time-aware and account for concurrency, since a linear trace, read top to bottom, will misattribute blame in any scenario where multiple agents are acting at once. And counterfactual replay, the ability to intervene on one specific step and rerun the trajectory to see how the outcome shifts, sometimes called Causal Agent Replay, separates platforms that can explain a failure from platforms that can only point at one.

Platform scores against these criteria

Maxim AI launched in 2024 as a full-stack platform covering simulation, evaluation, and production observability in one interface. Its tracing is native at the session level, and it's one of the few platforms that supports multi-turn simulation before deployment; failure clustering is only partial. Distributed tracing follows the complete path from user input through tool call to final response, and quality checks in production combine custom rules, deterministic evaluators, statistical checks, and LLM-as-a-judge scoring. The more distinctive piece is the feedback loop: production failures get pulled into Maxim's Data Engine and converted into evaluation datasets that feed back into pre-deployment simulation, so the system that catches production mistakes is the same one that trains the next round of testing. Evaluations can run at the session, trace, or span level, which matters for multi-agent systems where the failure could live at any of those layers. SDKs cover Python, TypeScript, Java, and Go, alongside a no-code UI for product and QA staff, and the platform lists Thoughtful, Mindtickle, and Atomicwork among its deployments. Prompt management runs through something called Playground++, letting teams version and deploy prompt changes without touching code, and the platform carries SOC 2 compliance with granular access controls.

Arize AX grew out of MLOps and model monitoring roots, raised a $70 million Series C in early 2025, and counts Uber, PepsiCo, and Tripadvisor among its enterprise customers. Tracing runs on OpenTelemetry spans, tool use capture is span-based, and path visualization and simulation support are limited, and failure clustering capabilities are not fully documented. In 2026, the platform extended into a production feedback loop through something called Signal, a managed agent built into AX that reviews production traces continuously, groups related failures together, and surfaces ranked issues with supporting evidence and suggested fixes. Engineers can inspect nested multi-agent traces, group runs into sessions, evaluate live production traffic, build datasets out of failures, and monitor cost and latency post-deployment. The OpenTelemetry foundation keeps it vendor-agnostic and framework-independent, and there's an open-source counterpart, Arize Phoenix, with unlimited local use and a clear upgrade path to the managed product, though its UI leans data-science-first and asks more of non-technical stakeholders. The platform's OpenTelemetry foundation and data-science-first UI mean it asks more of non-technical stakeholders.

Datadog Agent Observability builds tracing around a native decision-path view, with span capture for tool calls; simulation and semantic failure clustering remain areas to evaluate against your requirements. AI Agent Monitoring maps each agent's decision path, inputs, tool calls, calls to other agents, outputs, as an interactive graph, and an AI Agents Console extends that same visibility to in-house and third-party agent behavior. The workflow covers end-to-end LLM tracing, datasets and experiments, offline and online evaluation, and human review, all inside the tool teams already use for infrastructure. That's the real structural advantage: agent traces sit right next to APM data, infrastructure metrics, and logs already flowing through Datadog, so an engineer can go from a failing LLM span down to the underlying service and infrastructure signal without switching tools. For a team already running Datadog, that consolidation has real value. Simulation and semantic failure clustering are still the gaps.

Cisco and Splunk, following the Galileo acquisition, represent a different kind of consolidation. Cisco announced its intent to acquire Galileo on April 9, 2026, and that deal has since closed, with Galileo now being folded into Splunk's AI Agent Monitoring line. Galileo brought with it Luna-2, its evaluation model, more than 20 metrics spanning hallucination, relevance, safety, and agent behavior, plus real-time guardrails. The integration into Splunk is still in progress, and tracing, tool use capture, path visualization, and simulation capabilities are still taking shape. Galileo brought real-time guardrails covering hallucination, relevance, safety, and agent behavior, which represent a distinct approach to catching failures compared to others on this list. The pitch here is correlating agent traces with the broader enterprise security and infrastructure telemetry that Splunk already handles, which is a similar consolidation argument to Datadog's but aimed at a different stack. Since the integration into Splunk is still in progress, teams evaluating this option should weigh product continuity and roadmap clarity as the acquisition settles in, rather than assume feature parity with what Galileo offered as a standalone product.