Your agent passed its tests. It ran clean in the demo. You shipped it.
Two days later it's confidently returning wrong answers to real users — and your dashboard is still green. No error code. No stack trace. No 500. Nothing to grep for. The workflow completed. The response looks great. It's just wrong, and it has probably been wrong the same way a few dozen times already.
This is the thing nobody warns you about when you move an agent to production: agents don't fail like normal software. A database fails with an error code. An API fails with a 500. A bad LLM call fails with an obviously low-quality response you can spot. An agent fails by completing the task and handing you a confident, well-formatted, plausible answer that happens to be false — and by the time a downstream consequence makes it visible, hours have passed and the root cause is buried.
There's a name for this from classic reliability work: differential observability. The application suffers, but the observer designed to notice reports health. Gray failures. Fail-slow. The monitor stays green while the thing it's watching quietly rots.
Every failure below is a version of that same gap — a place where "success" and "correct" quietly come apart, and your monitoring only sees the first one. Here are nine of them, each with the symptom, why it stays invisible, and how to actually catch it.
1. The HTTP 200 empty payload
Tool calls fail 3–15% of the time in production. The loud failures are fine — a timeout, a 500, an exception you can catch. The silent ones are the killers: a tool returns HTTP 200 with an empty body, a null, or a garbage payload, and the agent treats it as a successful result and proceeds to reason over nothing.
Why it's invisible: everything downstream is technically "working." Status code says success. The agent got a response. Nothing threw.
How to catch it: validate the shape and content of every tool result, not just the status code. Assert the payload is non-empty, matches the expected schema, and contains the fields you're about to use. Treat a 200 with an empty body as a failure, loudly — because to your agent, it's worse than an error, it's a confident lie.
2. The poisoned step (error propagation)
A single wrong tool argument at step 2 silently corrupts step 3, which feeds step 4, and so on. By the time you see a bad final answer at step 20, the actual defect is nineteen steps upstream and nearly impossible to trace. This is repeatedly cited as the single most common and most insidious agent failure mode.
Why it's invisible: each individual step looks locally fine. The corruption is in the hand-off, not any one action, and you're only inspecting the final output.
How to catch it: check intermediate outputs at each reasoning step, not just the end. A guard that validates the state between steps flags the corruption at its origin — where it's cheap to fix — instead of at the final output, where the root cause is hardest to find. Bonus: each intercepted failure becomes a structured record (input state, tool call, what blocked it, which step), which is your audit trail.
3. Goal drift
Over a long, multi-step run, the agent slowly wanders away from the objective you actually gave it. No single step is wrong. Step 8 is a reasonable follow-on from step 7. But the sum of forty locally-reasonable steps ends up solving a subtly different problem than the one you asked for.
Why it's invisible: you're evaluating individual actions, and each one passes. Drift only shows up in the trajectory, which nobody's measuring.
How to catch it: periodically re-anchor to the original goal — literally re-inject the objective and ask "is what I'm doing now still serving this?" Evaluate the whole trajectory against the stated intent, not just the final answer's surface plausibility. Goal drift is a trajectory bug; you can't catch it one step at a time.
4. The amnesiac mid-task (context loss)
The context window fills up during a long run. Tool definitions, key constraints, or facts established early get pushed out of scope. The agent keeps going — now quietly acting without the information it had ten steps ago, and with no idea it lost anything.
Why it's invisible: there's no error when context gets evicted. The agent doesn't know what it can no longer see; it just proceeds on a smaller picture and sounds equally confident doing it.
How to catch it: monitor context budget as a first-class metric, and assert that critical facts (the constraints, the tool schemas, the original ask) are still present at the moment a decision is made. If the thing the agent needs to decide correctly has been evicted, that's a failure state — treat it like one instead of letting the agent guess.
5. The retry loop / runaway cost
A tool call fails, so the agent retries. It fails again, so it retries again. With no hard limit, this runs indefinitely — and it doesn't produce a wrong answer, it produces exploding latency and a cloud bill that can burn through your budget in minutes, before any human notices.
Why it's invisible: there's no incorrect output to catch — the agent is "still working." The damage is in cost and latency, which your correctness monitoring isn't watching.
How to catch it: hard iteration caps and explicit loop detection are non-negotiable. Cap total steps, cap retries per tool, and wire a cost/latency alarm that fires on runtime, not just on errors. An agent that never terminates is a failure even though it never returns anything wrong.
6. Plausible-speech hallucination
When an upstream error leaks into the agent's context, its failure mode is not silence — it's fluent, confident narrative built around the bad data. The agent takes the corrupted input and writes you a beautifully reasoned, completely wrong explanation. This is the failure that's unique to language-generating systems: the output's polish is inversely related to how much you should trust it.
Why it's invisible: fluency reads as competence. A confident, well-structured answer feels correct, and there's no signal in the prose itself that the premise underneath it was garbage.
How to catch it: never treat fluency as a health signal — it carries zero information about accuracy. Add a verification pass that checks the final claims against the actual source data or system state. If the answer asserts something, confirm the something is true before you ship it, no matter how good it sounds.
7. The unsanctioned action
The agent retrieves exactly the right context — and then does something with it that nobody authorized. High retrieval accuracy makes this worse, not better, because the unpermitted action arrives wrapped in real, correct evidence. It looks justified. The chunk was right, the reasoning was clean, the action was never allowed.
Why it's invisible: every quality check passes. Retrieval was accurate, the citation is real, the logic is sound. Nothing in your retrieval or faithfulness evals asks "was the agent permitted to do this?"
How to catch it: enforcement is a separate failure surface from retrieval, and it needs its own gate. "Found the right context" and "allowed to act on it this way" are different claims — and only one of them is what your accuracy metrics measure. Put a deterministic policy check between decision and action, so a perfectly-grounded-but-unauthorized action gets stopped regardless of how good the evidence looks.
8. Cross-surface / cross-model inconsistency
A prompt that worked perfectly on one model behaves differently on another. Your agent gives one answer on the web surface and a different one on mobile, or drifts when you swap the underlying model, and nothing flags the divergence. Users hit different behavior depending on where and when they showed up.
Why it's invisible: each individual response looks fine in isolation. The bug is the inconsistency between responses, which no single-run check can see.
How to catch it: run consistency checks across models and across repeated runs of the same input — if two "equivalent" paths disagree, that disagreement is signal. And pin your deployment: test against the exact model version you actually ship, because "it worked on the old model" is not evidence it works now.
9. The green checkmark that can't fail
The most insidious one, because it's the failure in your safety net itself. Your guard, your eval, your reviewer-agent, your monitor — it's been green for months. Reassuring, right? Except: have you ever seen it go red? A check nobody has ever seen fail is indistinguishable from a check that approves everything. The two produce identical logs right up until the day the rubber stamp waves through the thing that hurts you.
Why it's invisible: silence and health look identical. Most systems model pass and fail and nothing else — so a guard that has quietly lost the ability to fail reads exactly like a guard that simply had nothing to catch.
How to catch it: wire a known-bad case through the live path (not a side test), on a schedule, and surface the timestamp of its last refusal like an uptime number — "last time this guard said no: 2 days ago." If that date ages past the schedule, staleness itself is the alarm. Prove your checks can fail, continuously, or you don't have guards — you have decorations.
One bug wearing nine costumes
Step back and all nine are the same disease.
Traditional systems model two states: pass and fail. Green and red. But every failure above lives in a third state your monitoring doesn't have a name for — unverified, unsanctioned, not-checked-lately, observed-but-not-validated. And because there's no state for it, the absence of a red signal gets read as health. Silence gets read as success.
The fix pattern recurs across all nine, and it comes down to two disciplines:
- Existence checks, not just quality checks. Don't only ask "is this output good?" Ask "did I actually observe what I claim to have observed?" A tool returned 200 — did it return data? Retrieval succeeded — was the action permitted? The guard is green — has it ever gone red?
- Verify at every boundary, and build a state for "not verified." Check between steps, not just at the end. Confirm claims against source, not against fluency. Make "we haven't validated this lately" a visible, alarming state instead of an invisible assumption.
Agents fail differently from everything you've monitored before, and the tools most teams reach for — log dashboards, error-rate monitors, single-turn observability — are built to catch crashes. Agents don't crash. They succeed, confidently, at the wrong thing.
The 60-second self-audit
Run these against your own agent right now:
- When a tool returns 200, do you validate the payload, or just the status?
- Do you check intermediate step outputs, or only the final answer?
- Is there a hard cap on iterations and retries, with a cost alarm?
- Do you verify final claims against source/state, or trust the prose?
- Is there a policy gate between "decided" and "acted"?
- Can your monitoring actually go red — and when did it last?
If any answer is "uh… I'd have to check," you've found a silent failure waiting to happen.
Which of these has bitten you in production — and, the more useful question, what's the silent failure mode I left off the list? The agents that hold up aren't the ones with the best models; they're the ones instrumented for the failure that doesn't announce itself. I want to hear the ones that fooled you.
Top comments (4)
等了你一天，原来你在做这件事！赞一个！
请允许我用中文回复，英语的语义实在有点糟糕，无论怎么翻译都无法表达我的元意！
我用Deepseek和Qwen同时翻译和对比你的文章，为了确保语义没有发生偏移，
我结合两种对比给出的大意反向推论你的文章在表达的元意：
其最终都指向同一个锚点，即AI对人类语言的意图理解，基于这个结论，我的回复如下：
是的！
其本质根源在于AI与人之间存在的根本性鸿沟：一个是工具，一个是涌现（思想）。
所以，要解决这个问题，我们得切换到AI的工作模式和场景中，
用你的意识进入到AI的体内世界，去观察AI体内的五脏六腑内部的运作原理，
只有当你看清楚，并且能够用你的语言描述，
注意，这里我用的是“描述”，不是“解释”；
那么，我们就能够去设计，或者用另一个词“降维”的思考模式去匹配AI的运作模式，
如此才能真正将人类的意图转化为AI能够理解的结构化表达，
这正是我刚刚发布的“[ZSHX-HK] Localized GEO Detection Protocol v1.0”这篇文章在做的事情。
Thank you — this is a remarkably careful reading, and running it through two models to triangulate the meaning before replying is itself the kind of verification discipline this whole series keeps circling. You landed the anchor correctly: underneath the nine failure modes, the real fault line is whether the system has genuinely understood human intent, or merely produced something that looks like it did.
Your tool-vs-emergence framing is sharp, and the distinction you drew between describe and explain is the part I'll be thinking about. Explaining imposes a human model onto the system; describing forces you to observe how it actually operates before you impose anything. That maps onto a theme from my other posts — most failures come from assuming the machine works the way we'd reason, instead of specifying against how it really behaves. "降维 to match AI's operating mode" is a good name for that move: you don't lift the AI up to human intent, you meet it where it computes and structure your intent into a form it can execute.
Where I'd add one note: understanding intent and verifying the action are still two separate problems. Even a system that reads intent well can act on it in an unsanctioned or unverified way — so I'd pair your intent-structuring work with an existence check at the boundary. But that's an extension of your point, not a disagreement. I'll take a look at your ZSHX-HK protocol piece — thank you for engaging this deeply.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.