- A production study of 22 LLM-agent incidents found the system could be wrong for 13 hours to 60 days while 4,286 unit tests and 827 governance audits stayed green.
- Roughly 70% of failures were discovered by humans reading agent outputs rather than by alerts, tests, or audits.
- Silent failures commonly followed a three-part pattern: an unpredictable trigger, an architectural amplifier that magnified it, and a concealer that kept reporting success.
- The core problem isn’t insufficient test count but unobserved seams between components where correctness isn’t asserted.
- Tests and audits function mainly as regression engines (preventing known bugs from returning), not as predictors or smoke detectors for novel failure modes.
A June 2026 study followed 22 production incidents inside a live LLM agent runtime. In most of them the system was already broken while every automated check, all 4,286 unit tests and 827 governance audits, reported green.
The failures stayed silent anywhere from 13 hours to 60 days. Around 70 percent were caught by a human actually reading the agent's output, not by an alert or a failing test.
The fix is not more tests. Tests catch the regressions you already named, and agents break in the seams between components where no test is watching.
Green stopped meaning working
The paper is titled "When Errors Become Narratives," and it does something most agent research does not. Instead of scoring a model on a benchmark, one engineer instrumented a real system they run in production and wrote down every time it broke for two months.
The system is not a toy. It runs about 40 scheduled jobs, calls 8 different LLM providers, and is guarded by 4,286 unit tests and 827 declarative governance checks. That is more test coverage than most teams ship with. And it still had 22 incidents reach production between April 9 and June 2.
The unsettling part is not the count. It is the definition the author had to invent to describe them. Every one of these incidents had a silent failure phase, a stretch where the system was degraded or flat-out wrong while all automated indicators stayed green. The error existed somewhere in the logs. It just never reached a human in a form they could act on.
Those silent stretches ran from 13 hours on the short end to 60 days on the long end. Two months of an agent quietly doing the wrong thing, with a dashboard full of green checks the entire time.
The three-layer shape of a silent failure
The most useful thing in the paper is the anatomy. Nearly every incident broke down into the same three layers, and once you see them you cannot unsee them.
First a trigger, the external spark. A Unicode surrogate byte in some input. A line the model was supposed to emit that it silently dropped. Small, specific, the kind of thing you would never write a test for because you did not know it could happen.
Then an amplifier, an architectural flaw that spreads the small problem into a large one. In one case, stdout logging that got captured inside a command substitution, so a stray log line became part of a command's arguments. The trigger was tiny. The architecture turned it into a real fault.
Then a concealer, and this is the layer that makes it an agent problem. The concealer is an absence that hides the failure. A status file that keeps writing "ok" regardless of what actually happened. A check that confirms the job ran but never confirms the job was right. The concealer is why the dashboard stays green. Something in the system is cheerfully reporting success while the work underneath it is broken.
Trigger, amplifier, concealer. The trigger you cannot predict. The amplifier is a design smell you can hunt for. The concealer is the one worth losing sleep over, because it is the reason nobody knew.
Your tests are a regression engine, not a smoke detector
The detection numbers are where this stops being academic. Across the incidents, human observation, someone actually looking at what the agent pushed, caught roughly 70 percent of the failures. The unit tests and governance audits caught close to zero percent of this class. All 4,286 tests stayed green through most of these incidents while the system was broken.
The author's audit of their own defenses is blunter still. On the incidents they checked, prevention beforehand worked in 0 out of 15 cases. Blocking the same bug from coming back afterward worked in 13 out of 15. Their conclusion is one line worth taping to a wall: audits are regression engines, not prediction engines.
That is not a knock on testing. It is a description of what testing is. A test encodes a failure you already understand. It is fantastic at making sure a known bug never returns. It is structurally incapable of catching a failure mode you did not think to write down, and agents generate those constantly, because the surface area is enormous and the inputs are open-ended natural language.
For years we treated a green test suite as evidence the system works. For agent systems, a green suite is evidence the system does not fail in the specific ways you have already imagined. Those are very different claims, and the gap between them is where the 60-day outage lives.
Why the distance matters
One more finding ties it together. The author noticed that how far a failure sat from human view predicted how long it stayed silent. The incidents that lived deepest in the seams between components, the handoffs where no single test runs because the test owns one side or the other but not the join, were the ones that festered longest.
This is the real lesson for anyone running agents in production. Your monitoring was designed around the places a human touches the system. The UI. The API response. The obvious job that fails loudly and pages someone. Agents do most of their damage away from those places, in the plumbing between a tool call and the next tool call, where the only witness is a log line nobody reads.
The old model assumed a person would eventually look. A user would notice the wrong output, file a ticket, and the loop would close. When an agent is both the producer and the consumer of most of these intermediate steps, no human is in the loop to notice. The system talks to itself, believes itself, and reports green.
What to actually do about it
Do not read this as "add more tests." The study is a direct argument that more tests of the kind you already write will not catch this. Coverage went up and the silent failures kept coming.
Three things are worth doing instead. First, hunt your concealers. Go find every status file, health check, and success flag in your agent pipeline and ask a hard question of each one: does this confirm the work was correct, or only that the code ran without throwing. Most of them only prove the second, and every one of those is a place a failure can hide.
Second, put a human back in the view, on purpose. The single highest-yield detector in the study was somebody reading the agent's actual output. That does not scale to every run, but it scales to a sample. Pull a handful of real agent outputs a week and look at them with your own eyes, not through a metric. You are checking the thing the metrics structurally cannot see.
Third, instrument the seams, not just the endpoints. The failures lived in the handoffs between components. That is exactly where most teams have no assertion at all, because each component's tests stop at its own boundary. A cheap check on the shape and sanity of what crosses between two agents will catch more than another hundred unit tests inside either one.
This is one engineer's study of one system, and I would not overclaim from an n of one runtime. But the shape is going to feel familiar to anyone shipping agents, and the core finding travels. When the worker is a machine that never gets tired and never files a ticket, "all checks passed" and "the system is working" quietly stop being the same sentence.
Sources: When Errors Become Narratives: A Longitudinal Taxonomy of Silent Failures in a Production LLM Agent Runtime, and VentureBeat on untracked agent failures in production.
Treat “green” as a weak signal and invest in observability that checks correctness, not just job completion. Look specifically for concealers—status files, success flags, and governance checks that can say “ok” even when outputs are wrong—and redesign them to fail loudly when invariants break. Add end-to-end canaries and lightweight human-in-the-loop review for high-impact outputs, and hunt architectural amplifiers (like logging or parsing paths that can contaminate commands) before they turn tiny triggers into long silent outages.