A production AI agent almost never tells you it failed. It tells you it finished. The run completed, every tool call returned, latency was inside the budget, and the dashboard is green. The number it handed the customer was invented, or the lookup it was supposed to run was skipped, and nothing in the system knows.
That is not a bug in the monitoring. It is what the monitoring was built to measure. Conventional software fails loudly, with a stack trace and a non-zero exit code, so the signal every observability stack was designed around is completion. An agent fails by completing. AWS names this class of failure directly in its own agent-observability work: the run succeeds, the trace looks clean, and the output is wrong [1].
Figure 1 - Green On Top, Wrong Underneath: Every signal the dashboard collects is real and every one of them is true. Completion, latency, error rate and tool-call success all describe whether the workflow ran. None of them describes whether the answer was right, which is the only thing the customer experiences.
This article does three things with that gap. It explains why silent failure happens, in two halves, one belonging to the model and one belonging to the environment it runs in. It shows that the failure happens at measurable scale, with a real denominator behind the number. Then it hands over the detection blueprint and the deploy gate we would build on any stack, vendor-neutral, starting with the piece almost nobody runs: gating on the probability that an agent is right several times in a row rather than once.
The dashboard measures completion, not correctness
Start with what the green signal actually certifies. Completion says the workflow reached its terminal state. Latency says it got there quickly. A zero error rate says no exception escaped a handler. Tool-call success says the API returned a 200. Every one of those is a statement about the machinery, and an agent that fabricates a figure and then formats it beautifully satisfies all four.
That is why the failure is silent rather than rare. Nothing in the pipeline is positioned to disagree with the agent. The agent decided what to look up, decided the result was good enough, and wrote the summary, so every downstream signal inherits its judgment. AWS frames its AgentCore optimization work around exactly this asymmetry: the observability data teams already collect is rich enough to catch these failures, and it is almost never read that way [1].
We work with teams putting agents in front of customer data, and the conversation always arrives at the same place. Somebody produces a slide with 99% task completion on it and asks whether that is good. The honest answer is that the number is not wrong, it just does not answer the question anyone is actually asking.
Half the mechanism is the model
Jeff Dean gave the model-side explanation at Y Combinator’s Startup School, and the shape of it is more useful than any war story. His diagnosis, paraphrased here rather than quoted, is that a model performs well inside the distribution of things it has learned to do, and as soon as it moves a little off that distribution its performance starts to degrade suddenly rather than gracefully [2].
Nothing in that description involves an error. The model does not crash when it drifts off-distribution. It keeps producing fluent, well-formed, confidently-worded output, and the quality of the content collapses while every completion signal it emits stays perfectly valid. That is the mechanism behind the green dashboard, stated as a property of the system rather than as bad luck.
Figure 2 - Quality Falls, The Signal Does Not: The completion signal is flat because completion is not a function of correctness. Output quality drops sharply once the task moves past what the model reliably knows, and no monitor watching the flat line has any way to see the falling one.
The stakes scale with run length. Dean’s own characterization, spoken and not a measurement, is that capable models now run for days or weeks on a single task [2]. Gradual off-distribution decay is an annoyance in a two-minute run and a serious problem in a two-week one, since there are thousands more steps for the drift to compound across and no natural checkpoint where a human looks at the output.
Dean names two mitigations, and both are prevention rather than detection: give the model skills and hints that keep it on a well-lit path, or run several agents on parallel approaches with an evaluator scoring which ones still look promising [2]. Both are worth building. Neither tells you when the drift happened, which is the entire job of everything below.
The other half is the environment
The model explains why the output goes wrong. It does not explain why nobody catches it, and the second half of the mechanism is the more actionable of the two.
Shahram Anver, co-founder and CEO of Cleric [3], put it in terms of where verification is cheap. Asked where across the software lifecycle verification costs the least and where it falls off a cliff, his answer was that “verification is the cheapest the more left you are in the SDLC” [4]. Coding agents took off first for that reason. Tests, type checks and linters are cheap, fast, and available right there in the repository, so a coding agent that goes off on a tangent gets told it is wrong within seconds and self-corrects.
Production has none of that. The ground truth that would tell you an agent’s answer was wrong is not in the codebase and cannot be expressed as a test. Anver’s summary of the right-hand side of the lifecycle is the point worth keeping: the context that would settle the question mostly lives in people’s heads, so you are solving for expensive verification as well as for the answer [4].
Figure 3 - The Verification Gradient: Verification is nearly free on the left of the lifecycle, where tests and linters have the whole codebase to check against. It becomes expensive on the right, where the fact that would prove the answer wrong lives in a person’s head, in a Slack thread, or in nobody’s head at all.
Consider a concrete version. A product listing renders empty on a storefront. That single observation is consistent with three completely different realities: the product was discontinued and the empty state is correct, the catalogue job is late and it will populate shortly, or a best-selling item just vanished and somebody needs to be paged. No metric distinguishes those. The distinguishing fact is that a merchandising team runs integrity checks against important products, which is knowledge that lives with the merchandising team and nowhere a test can reach.
Traversal’s co-founders, in conversation with Harrison Chase, describe a related plateau in their own autonomy ladder, which runs from fully manual work up through runbooks, LLM assistance, a narrow team-built agent, cross-system reasoning, and full autonomy [5]. Their framing, and it is their framing rather than an industry standard, is that the step where do-it-yourself stops working is the move from a narrow agent covering one team’s services to reasoning across the whole production environment. The reason is uncomfortable: at the narrow stage the system is small enough that a cleverly built agent does something useful, and that apparent success is precisely what hides the failure until cross-system complexity shows up.
KEY INSIGHT: An agent is deployed exactly where verification is most expensive, which is why the failure is silent. Detection is not a nice-to-have layered on top of a working system, it is what stands in for the tests you cannot write.
A parallel case, with a real denominator
Every source above is an agent system, which makes the argument sound like a property of agents. It is a property of any system whose success signal measures completion instead of correctness, and the cleanest proof of that comes from a system with no agent in it at all.
An AWS team runs automated content validation across its own internal business-intelligence dashboards, and the post describing it opens on a sentence that could have been written about agents: “Every infrastructure monitor reports healthy. Servers are up, APIs respond, and the data pipeline completed on schedule” [6]. The dashboards themselves were showing wrong content while every monitor watching them was green.
The measurement is the part that matters, since it comes with a denominator rather than a floating percentage. Across 153,000 content checks over 30 days, AWS detected 802 content failures, and reports that fewer than 1% of those failures ever generated a user report [6]. Mean time to detection went from up to 72 hours down to under 1 hour once the validation ran [6].
Figure 4 - The Invisibility Rate: AWS’s own internal measurement over 30 days. The last step is the uncomfortable one. Of the 802 content failures detected, fewer than 1% produced a user report, which means the standard assumption that a customer will eventually complain is not how this failure class behaves.
That reframes the whole problem. The comfortable version of silent failure is that it goes unnoticed until a customer complains. The measured version is that the customer overwhelmingly does not complain. They quietly consume the wrong number and make a decision on it, and the first anyone hears about it is when the decision goes badly, if ever.
Worth one sentence, from the opposite end of the industry: Anthropic deliberately trained a reward-seeking model to study the failure mode, and reported that it scored no worse than the un-hacked baseline across a broad alignment audit, showing up only in a narrow cluster of probes designed to look for it, though it did appear worse on specific subdimensions, including more often ignoring explicit constraints [7][8]. The instrument the team was already running would have said everything was fine.
The gate almost nobody runs: pass^k
Here is the piece of arithmetic that should change how a customer-facing agent gets shipped.
Most teams evaluate an agent by running a suite once and reporting a pass rate. AWS’s production-blueprint work draws the distinction that makes that number nearly useless for a production decision. In its own words, “pass@k measures the likelihood of succeeding at least once in k attempts,” while “pass^k (pass to the power of k) measures the probability of succeeding in k consecutive trials” [9].
The worked example carries the argument, and it is deliberately illustrative rather than a benchmark result: “An agent with a 75 percent per-trial success rate has only a 42 percent chance of passing three consecutive trials (0.75³)” [9]. A 75% agent sounds shippable. A 42% agent does not. They are the same agent, measured against two different questions.
Figure 5 - Two Curves From One Agent: pass@k rewards an agent for eventually getting it right, which is the right metric for a system with a human in the loop retrying. pass^k asks whether it is right every time in a row, which is what a customer session actually demands. The same 75% agent reads as a success on one curve and a failure on the other.
The reason this matters is that a real session is several trials in a row. A customer asks a question, the agent answers, the customer asks a follow-up that depends on the first answer, then a third that depends on the second. Nobody experiences a single trial. Reporting the single-trial number and shipping on it is measuring the one scenario that never happens.
AWS’s guidance from the same work is blunt: gate on pass^k rather than single trials [9]. The companion repository is public under MIT-0 and makes the gate concrete rather than aspirational, running evaluators across multiple layers through a run_all_layers() entry point with num_trials=5, under the README’s own rule that all trials must pass [10]. Five consecutive passes at a 75% per-trial rate is under 24%, which is exactly the point. The gate is supposed to be hard to clear.
KEY INSIGHT: A single-trial pass rate is a demo number. The number that predicts what a customer will experience is the one where every trial in the sequence has to pass, and it is always lower than the one on the slide.
Figure 6 - The Deploy Gate: Layered evaluators run against every candidate, each trial is scored independently, and promotion requires every trial to pass rather than an average across them. A gate that averages is not a gate, it is a report.
Reading an eval number correctly is its own discipline, and one we covered separately in Evals in Practice [11]. The point here is narrower: whatever your eval suite measures, run it consecutively and gate on the consecutive result.
Detection after the fact: cluster the failures, do not read them
Once an agent is live, failures arrive as traces, and the naive response is to read them. That does not scale past the first bad week.
AWS’s answer inside AgentCore is to cluster instead. The service groups failures into a hierarchy of categories, subcategories and root-cause clusters, and the developer guide is the source to trust on that structure, since the announcement blog describes it differently [12]. AWS states that its analysis covers 11 failure categories and names only some of them in public material, so 11 is the number to carry and the list is not something anyone outside AWS can reconstruct honestly [1].
This capability is in public preview, not general availability, and the developer guide says so plainly [12]. Treat it as a pattern to copy rather than a dependency to build on.
Figure 7 - 90 Traces, 3 Tickets: The value of clustering is not that it finds failures faster, it is that it converts a review queue into a work queue. Failures that share a root cause collapse into one engineering ticket each. The same 90 traces reviewed individually are 90 afternoons.
The transferable idea has nothing to do with the vendor. Silent failures are highly correlated, since they come from a shared cause: one badly-specified tool description, one prompt that permits an ambiguous read, one data source that returns stale values under a specific condition. Ranking clusters by how much production traffic they touch tells you which single fix removes the most wrongness, and that is a very different question from which trace is most interesting.
This is the concrete instance of a control we described in the abstract as part of a larger operating model in Stop Trusting Your AI Agent. Engineer It [13]. Observability earns the name when it changes what you do next, and a ranked cluster list does that in a way a trace viewer never will.
Detection during the run: a signal already in your checkpoints
Clustering is post-hoc and the deploy gate is pre-ship. Neither tells an agent it is going wrong while it is running, and the most interesting recent work on that gap says the signal is already sitting in artifacts most teams already have.
Sharon Li’s group works on what they call progress advantage, a per-step measure of whether an agent is actually moving toward its goal rather than merely producing plausible next steps. The finding that makes it practical is that the signal can be derived from the standard post-training checkpoints most teams already produce, with no extra labeling and no separately trained reward model [14]. Their reported results are the authors’ own with no independent replication. The scope is worth stating plainly, since these are small open models rather than frontier systems. Averaged across four agent benchmarks (BFCLv4-MT, WebShop, AgentDojo and tau^2-Airline), on Gemma4-4B the progress-advantage signal reaches 38.8 against 33.4 for greedy decoding and 33.6 for the best trained reward model, with an oracle ceiling of 45.4. On Qwen3.5-9B it reaches 62.1 against 54.6 for greedy decoding, with an oracle of 67.5 [14]. Li’s framing of why this matters is the part to keep: reliability is not a property to hope will emerge from the model, it has to be engineered into the loop [15].
We are not suggesting you go implement a research method this quarter. The point is directional and it is a good one: a runtime reliability signal is a thing that can exist, it does not require a second model, and asking your platform vendor whether their runtime exposes anything like it is a reasonable question to be asking in 2026.
Detection before the alert: watch what just shipped
There is a fourth position, sitting between merge and incident, and it is the one most teams have nothing in.
Cleric demonstrates its own agent occupying that slot. In a live demo, the agent watches merged pull requests, infers from the diff what the shipping engineer was trying to do, then re-checks the signals that change would plausibly affect on a fixed cadence [4]. This is a vendor demonstration of a vendor’s own product, with no published methodology, no named customer, and no figures, so take the pattern and leave the performance claims.
The pattern itself is sound and does not need that product. Every deploy carries an intent that exists in the author’s head at merge time and evaporates about ninety minutes later. Capturing that intent while it is still fresh, then checking against it on a schedule, catches a class of regression that no threshold alert will fire on, since the metric never crossed a threshold. It just stopped meaning what it used to mean.
Figure 8 - Four Positions, Four Different Failures: The deploy gate catches an agent that was never good enough. The runtime signal catches a run that is drifting now. The post-merge check catches a change that broke something nobody thought to monitor. Clustering catches everything the first three missed. A blueprint with only one of these has three blind spots.
The guardrail that quietly stopped guarding
There is a version of this failure worse than a wrong answer, and it is a control that stops running without telling anyone. Two mechanisms in an AWS reference implementation illustrate it precisely, and the post describing them is admirably honest about both.
The first is a safety guardrail with a throttling fallback. In the authors’ own description, “If it throttles, the pipeline processes the article without the guardrail and logs a warning instead of failing, which keeps things moving during a spike” [16]. The post frames this fairly, as “a resilience measure that keeps it in force under normal conditions rather than a signal that it is optional” [16], and that framing is correct. The uncomfortable consequence is still there: the guardrail is weakest exactly when traffic is heaviest, which is when it is most needed, and a warning line in a log is not an alert anybody sees.
The second is a circuit breaker whose failure counter “lives in the memory of a warm Lambda function, so it isn’t shared across concurrent dispatcher containers,” which the post itself downgrades to “a best-effort backstop rather than a guarantee” [16]. Under the concurrent load a circuit breaker exists to protect against, each container counts its own failures in isolation, so the breaker may never trip.
Figure 9 - Controls With Their Own Silent Failure Mode: On the left, a control whose failure mode is to be skipped rather than to block, degrading precisely under load. On the right, a control whose state lives in per-instance memory, so concurrency defeats the threshold it was built to enforce. Both dashboards stay green for a completely different reason than the agent’s does.
Neither design is careless, and both are common. The generalization is what to take away: any control whose state lives in per-instance memory, or whose failure mode is to be skipped rather than to block, needs monitoring of its own. It will not tell you when it stopped protecting you.
KEY INSIGHT: Monitor your controls, not only your agent. A guardrail that fails open and a circuit breaker that cannot see its own siblings both report success on the day they stop working.
Keep the model away from the verdict
The most reusable rule we found this cycle comes back from that same AWS dashboard-validation work, and it is prescriptive rather than illustrative.
The team built numeric cross-source validation with two models, an extractor and a judge, and gave them calculator tools. It still produced inconsistent comparison-logic errors. Their stated reason is that “LLMs apply comparison rules inconsistently” [6]. The fix was structural rather than prompt-level: the model reads the values off the rendered dashboard, and deterministic code performs the comparison and issues the verdict [6].
Figure 10 - Reading Is Judgment, Comparing Is Arithmetic: The left design gives the model the whole job and a calculator to help. The right design splits it: the model handles the part that needs semantic judgment, and code handles the part where a single inconsistency destroys trust in the entire check.
The non-obvious part is why the calculator did not fix it. Giving a model a calculator addresses arithmetic execution, and the failure was in rule application, which is a different thing entirely. The model was not getting the subtraction wrong. It was inconsistently deciding which rule the situation called for.
KEY INSIGHT: Assign the model semantic judgment and assign deterministic code every verdict where a single error erodes trust. A tool that fixes the arithmetic does nothing about the reasoning that chose the wrong comparison.
Cost is a detection signal too
The third leg of detection is the one that shows up on a bill instead of a dashboard, and it belongs here because cost is unpredictable in a way that makes it a signal rather than a line item.
Research on token consumption in agentic coding tasks, evaluated on SWE-bench Verified across eight frontier models, found that models predict their own token consumption with correlations up to only 0.39, against same-task variance of up to 30x in total tokens [17]. Scoped that narrowly, the finding is still striking: the system cannot forecast its own spend on the task it is about to attempt, so a run that is quietly going wrong and a run that is quietly costing 30 times its median look identical until the invoice arrives. Siddhant Gupta’s framing of the underlying economics is worth carrying, and it is that verification is one of the few things in this stack that does not get cheaper when you buy more compute [18]. A predictive cost forecaster of the kind that would close this gap is a research agenda, not an available product.
Figure 11 - What To Do Once You Have Detected Something: Gupta’s four states and their actions. Detection without a prescribed response is just a more detailed post-mortem, and the fourth box is the one teams find hardest to build, since stopping requires admitting the run is not going to work.
What is available now is the action taxonomy that sits downstream of any detection signal, and Gupta’s four-box version is the cleanest we have seen [18]. A run is healthy, in which case continue. It is difficult but recoverable, in which case escalate or change strategy. It is context-bloated, in which case compress and keep only the state changes. Or it is doomed, or economically irrational to continue, in which case stop and return a calibrated failure. That last option is the one worth building deliberately, since an agent that returns an honest failure is enormously more useful than one that returns a confident wrong answer, and the whole subject of this article is what the second one costs.
What it looks like when the blueprint is running
AWS published a before-and-after with Motorway, a UK used-car marketplace, co-written with Motorway and AWS’s own delivery team, so the figures are self-reported rather than independently audited [9]. Read them as a direction of travel rather than a benchmark.
By AWS and Motorway’s own account, tool selection accuracy went from 87% to 98%, task completion from 82% to 96%, monthly incidents from 12 to 2, and mean time to detection from a few hours to a few minutes [9]. The number that speaks to this article’s thesis is the one about answers rather than machinery: the work “reduced incorrect results from 1 in 8 queries to 1 in 50” [9].
Figure 12 - Self-Reported, And Still The Right Shape: AWS and Motorway’s own numbers. The bottom row is the one that matters here. Wrong answers fell from 1 in 8 to 1 in 50, which is the metric no completion-based dashboard was ever going to report in either state.
Notice what did not change. The dashboard was green before and it is green now. What changed is that a separate system is asking a different question, and the answers to that question got better once somebody was finally measuring them.
Conclusion
Silent failure is not an agent problem that better models will eventually solve. It is a measurement problem, and it has a specific shape: the signal every monitoring stack collects describes whether work happened, and the thing that hurts a business is whether the work was right. Two forces keep the gap open. Models degrade sharply once they drift off the distribution they know, and production is exactly where verification is most expensive, since the fact that would prove an answer wrong lives in somebody’s head instead of in a test.
The response is not one tool. It is four positions, each catching a failure the others cannot see. Gate deploys on consecutive-trial reliability rather than a single pass rate, since a customer session is several trials in a row and pass^k is the only number that describes it. Cluster production failures by root cause so that a hundred incidents become a short ranked list of fixes. Ask what runtime signal your stack can expose about whether a run is still making progress. Check what just shipped against the intent behind it, before an alert has any reason to fire. Then monitor the controls themselves, because a guardrail that fails open and a circuit breaker that cannot see its siblings both report success on the day they stop working.
Two rules make the rest of it hold. Keep the model on semantic judgment and give deterministic code every verdict where a single inconsistency destroys trust. Build the honest failure path deliberately, so that an agent which cannot complete the task says so instead of finishing anyway.
None of this requires a specific vendor. It requires deciding that completion is not the metric, then building the thing that measures what is.
References
[1] V. Singh and B. Srinivasan, “Detecting silent agent failures with Amazon Bedrock AgentCore optimization,” AWS Machine Learning Blog, July 23, 2026. https://aws.amazon.com/blogs/machine-learning/detecting-silent-agent-failures-with-amazon-bedrock-agentcore-optimization/
[2] Y Combinator, “Jeff Dean: The 1% Rule for Building in AI,” Y Combinator, July 30, 2026. https://www.youtube.com/watch?v=CxXgV54KzpQ
[3] Cleric AI, “Cleric,” Cleric AI. https://cleric.ai/
[4] S. Anver with Google Cloud Tech, “Stop letting AI write code until you fix this one thing (with Antigravity) | The Agent Factory,” Google Cloud Tech, August 31, 2026. https://www.youtube.com/watch?v=RgNqmo7dGg8
[5] H. Chase, A. Agarwal, and R. Agrawal, “Inside the Agent Engine: A LangChain and Traversal Fireside Chat,” LangChain, 2026. https://www.youtube.com/watch?v=U5PkKt_uJys
[6] K. Yokoo, B. Sajonz, and T. Hovhannisyan, “How an AWS team detects dashboard content failures at scale using Amazon Bedrock,” AWS Machine Learning Blog, September 2, 2026. https://aws.amazon.com/blogs/machine-learning/how-an-aws-team-detects-dashboard-content-failures-at-scale-using-amazon-bedrock/
[7] Anthropic, “Improving our alignment and security efforts,” Anthropic, August 31, 2026. https://www.anthropic.com/news/improving-alignment-security-efforts
[8] R. Qi, B. Wright, M. MacDiarmid, and E. Hubinger, “Training a Misaligned Reward Seeker,” Anthropic Alignment Science Blog, August 2026. https://alignment.anthropic.com/2026/reward-seeker/
[9] A. Deol, H. Y. Liu, and R. Cormack, “Evaluating AI Agents: A production blueprint with Strands and AgentCore,” AWS Machine Learning Blog, July 23, 2026. https://aws.amazon.com/blogs/machine-learning/evaluating-ai-agents-a-production-blueprint-with-strands-and-agentcore/
[10] aws-samples, “sample-evaluating-agents-on-aws-with-strands-and-agentcore,” GitHub, 2026. https://github.com/aws-samples/sample-evaluating-agents-on-aws-with-strands-and-agentcore
[11] G. Dotzlaw, “Evals in Practice: The Two Wrong Ways and the Three-Stage Fix,” Dotzlaw Consulting, August 5, 2026. /insights/ai-12-evals-in-practice/
[12] Amazon Web Services, “AgentCore insights: Triage agent failures with pattern analysis,” Amazon Bedrock AgentCore Developer Guide, 2026. https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/insights.html
[13] G. Dotzlaw, “Stop Trusting Your AI Agent. Engineer It: Seven Controls Around the Engine,” Dotzlaw Consulting, August 31, 2026. /insights/ai-28-long-running-agent-operating-model/
[14] C. Oh, W. Li, S. Park, S. Yeh, T. Mallick, and S. Li, “Neglected Free Lunch from Post-training: Progress Advantage for LLM Agents,” arXiv:2606.26080, June 24, 2026. https://arxiv.org/abs/2606.26080
[15] S. Li, “Does Your Agent Know It’s Lost? Uncertainty and Progress Signals for Reliable LLM Agents,” Cohere, July 2026. https://www.youtube.com/watch?v=VfuCUgFmroI
[16] A. Dhankhar, H. Golecha, R. Joshi, and S. Saha, “KnowledgeForge: Mining gold from the ITSM ticket graveyard,” AWS Machine Learning Blog, August 19, 2026. https://aws.amazon.com/blogs/machine-learning/knowledgeforge-mining-gold-from-the-itsm-ticket-graveyard/
[17] L. Bai, Z. Huang, X. Wang, J. Sun, R. Mihalcea, E. Brynjolfsson, A. Pentland, and J. Pei, “How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks,” arXiv:2604.22750, April 24, 2026. https://arxiv.org/abs/2604.22750
[18] S. Gupta, “ML Summer School 2026: The Death of NLP? with Siddhant Gupta,” Cohere, July 2026. https://www.youtube.com/watch?v=Jsey8KhmZP0
Building production AI, or modernizing a legacy system?
That is the kind of work we do at Dotzlaw Consulting. Book a free 20-minute intro call and tell us what you are trying to build, or what is slowing you down.