Foundations 4 closed on a provocation: the signals that matter for AI systems — quality, cost, and safety — extend observability into a measurement layer that distributed tracing alone cannot cover. But it also flagged a harder problem waiting downstream. When the thing you're measuring stops being a single model call and starts being an agent that reasons, selects tools, evaluates intermediate results, and decides what to do next, the measurement infrastructure we've described so far isn't enough. The observability surface area multiplies as the causal chains get longer, and the traditional debugging assumptions (chiefly: that you can follow a request linearly through a system and find where it went wrong) break down entirely.
This post is about what must replace those assumptions.
With a single LLM call, you provide input, you get output (albeit stochastically), and evaluation is relatively straightforward: compare what came out to what you expected. The feedback loop is tight, the execution path is fixed, and the AI observability instrumentation requirements are well-understood.
An agent, however, reasons about the task in front of it, selects a tool, evaluates the intermediate result, and decides whether to call another tool, return an answer, or re-plan. Each iteration of the loop modifies the state that the next iteration operates on. Because it's a product of the agent's reasoning at each step, the execution path is not knowable in advance.
This is the tricky part about AI agent debugging. The observability problem doesn't just get a bit harder with added complexity, it compounds; every decision point in the loop is a place where something can go subtly wrong without a siren going off, and every iteration makes the earlier decisions harder to audit.
Run the same agent twice on identical input, and the executions may diverge. With each variation, different intermediate contexts, token costs, and outputs are produced from the same starting conditions.
This is a consequence of how agents are built. Model outputs are probabilistic, tool selection is conditional on reasoning over those outputs, and the agent's own self-evaluation of intermediate results introduces another probabilistic step. Non-determinism is baked right into the design.
The ramifications for AI agent observability are stark: without stored traces that capture the full decision chain — not just inputs and final outputs, but the reasoning, the tool selections, the intermediate results, and the branching logic that tied them together — reproducibility is essentially impossible, and debugging becomes an exercise in guesswork. You cannot rerun the failure to investigate it, which greatly compounds the difficulty of cost attribution, governance, performance investigations, and almost everything else.
Traditional distributed tracing was designed for a specific kind of system: a request that flows through a sequence of services, each of which contributes a span to a shared trace. Service A calls service B, which calls service C, and the trace is a linear (if complicated) record of that call chain that shows up on a dashboard somewhere.
The execution of AI agents isn't linear, it's kaleidoscopic — branching, recursive, and conditional. This means that standard trace visualizations become unreadable at any meaningful complexity. But the deeper problem is that the trace structure itself — the parent-child relationships between spans, the sequential flow, the exception-based error handling — was never designed to capture reasoning or decision logic. A missing span can be as important as a failed span. A clean trace does not prove correct execution. The fact that the workflow ran without throwing an error tells you almost nothing about whether the agent did the right thing.
Agentic debugging is hard because the failures themselves rarely manifest as “failures” with traditional metrics. Latency looks normal. Error rates look normal. The output quality is degraded, or the cost is spiraling, or a compromised input has propagated silently through the chain, and none of it trips an alert.
Naturally, there are many ways to characterize the failure surfaces of AI workloads, but five failure modes in particular recur often enough to deserve a name (and also figure prominently in our upcoming webinar). These are discussed in more detail in the sections below.
Here, each AI agent in a chain succeeds individually, but the workflow fails collectively because small errors multiply across steps. Tool selection logic that looks correct in isolation can produce compounding errors across a pipeline. This is the hidden math behind long agent chains: even high per-step reliability degrades quickly when the steps are sequential and the errors don't cancel, and human review of such AI workloads just doesn’t scale enough.
This is an issue related to Compound Reliability Decay, but focused less on long sequences of activity and more on how multiple agents operate together. The problem is that AI agents interpret ambiguous instructions differently, producing conflicting outputs, duplicate work, or inconsistent decisions across parallel branches. One agent acts on one interpretation of the task while another acts on a different interpretation, resulting, finally, in output quality that is inconsistent. This is a primary reason multi-agent systems become expensive, brittle, and suffer from low reliability as they scale.
Token spend rises faster than expected because each handoff, retry, and context passage adds overhead. Branching execution that expands into hundreds of sub-calls when stopping conditions aren't triggered belongs here. As it turns out, a workflow can simultaneously be technically functional while being completely unsustainable economically.
One compromised input or one compromised agent can affect everything downstream when trust boundaries between agents are weak. Prompt injection propagates through the chain, for example, while untrusted content gets treated as trusted state because the receiving agent has no way to distinguish between the two. Put more abstractly, inter-agent communication must be thought of as an attack surface, not just a message bus, and traditional infrastructure security controls don't cover it.
An agent keeps retrying a failing tool call until it hits token limits. The same near-identical trace repeats with no termination condition. The workflow consumes budget and makes no progress, often silently, until someone notices the bill.
None of these are exceptions that traditional tooling catches. The failures live in the reasoning and coordination layer, not the infrastructure layer, and that's a different surface than the one error rates and latency percentiles are usually pointed at.
This is where the gap between “I see everything happening” and “I know what to fix” is most acute. A degraded multi-agent output might have dozens of candidate failure points across the execution graph — any of the agents involved, any of the tool calls they made, any of the handoffs between them, any of the intermediate reasoning steps that shaped a downstream decision. Because clean traces don't narrow the candidate set, and because standard error signals don't fire on reasoning failures, you (or your long-suffering engineer) is left staring at an enormous trace and guessing where to start.
Engineers can realistically investigate a small handful of issues per day. The Three Issues Problem is the structural constraint we've named throughout this series, and agentic systems are its sharpest expression. You have time to investigate three candidates. Which three? The diagnostic distinctions that matter — tool misuse versus model error versus orchestration error, local failure versus emergent failure, bad input versus bad routing versus bad reasoning — are exactly what intelligent prioritization has to reason about on the engineer's behalf. Without that prioritization layer, observability produces noise at a rate that outpaces any team's ability to act on it.
The tooling landscape for agentic observability is early. LangSmith provides trace visualization for LangChain and LangGraph workflows, while a bevy of emerging eval metrics frameworks are being extended with reasoning-quality scoring. These are useful, and they represent real progress, but graph-native trace visualization that handles branching and recursive execution is still immature. What’s more, cross-agent causal analysis (i.e., the ability to follow a degraded output backward through agent boundaries to its origin) remains largely unsolved, and automated remediation across the failure modes named above is where the frontier actually sits.
What today’s AI engineering teams need is tooling that doesn't just surface issues, but tells you which ones to investigate first, and why. As it happens, this is the ground Prove AI is working to map. To be clear, the argument isn't that existing tools don't work; it's that the hardest part of the problem is closing the loop between observation and action in systems where both the execution path and the failure surface are non-deterministic, and this is where the category is moving.
Agentic systems are where the gap between monitoring and observability is most consequential. They're also where the gap between observability and remediation matters most. Knowing what failed, across dozens of candidate causes, in a system whose execution you cannot deterministically replay, is only useful if it leads to a fix. The final post in this series traces that full arc: monitoring to observability to remediation, and why the last step is where the real leverage is.