The author analyzed 155 AI agent jobs and discovered that most failures stemmed from infrastructure issues like timeouts and false success signals, not model errors, leading to practices such as asserting on effects and using multiple verification paths.
Everyone warns you that an agent will do the wrong thing. I went back through 155 jobs I had delegated across projects and counted. 14 failed. Not one of them failed because a model misread the task. Eleven were timeouts between 400 and 900 seconds. One was DNS. One was a 529 from the provider. One hit a session limit on the far side, and that one is worth describing, because the process was up, it accepted the job, and the model never ran it. From where I was sitting that looks exactly like slow work until the deadline expires. None of that is what actually cost me days. The expensive class is a tool that returns success and does nothing. A browser fill came back with applied "no" and len 0 while the text was sitting in the field. The same call came back ok on an editor that had ignored it completely. Reading the state back did not save me either, because the reader lied in the other direction: get_state reported an empty textarea no matter what was in it. And in one form the fields filled, both a DOM click and a real mouse click hit the button, and nothing left the page at all, because g-recaptcha-response was empty and the handler never tried. Nothing here is a transport problem. The call succeeded, the response validated, the side effect never happened, and the agent moved on to the next step with a false belief it will now defend for the rest of the run. Two things changed after that. I assert on the effect rather than on the return code, and I read the effect back through a different path than the one that made the change. The second half matters more than it sounds: my two paths lived in the same process, one reading a DOM property and the other reading the rendered accessibility node, and that was enough, because the bug lived in one of them and not the other. The other change is smaller. When a job dies now, the error carries the id of the session that died, so the work can be resumed instead of restarted. Before that the job store would learn the truth from a late answer and the model, which had already been handed an error, never would. If you run agents against real systems, I would like to know what your failure log actually says. I expected mine to be full of bad reasoning and it was full of infrastructure.
The article highlights practical system-level failures in AI agent workflows, such as context bleed and hallucinated details, arguing that these are often infrastructure issues rather than model defects.
Based on interviews with 50+ AI teams, the author highlights that production agent failures often stem from minor prompt or configuration issues rather than deep model problems. The article advocates for adopting software engineering practices like versioning, A/B testing, and experiment tracking to improve reliability.
The article argues that the primary failure point for AI agents in production is not the model itself, but the lack of infrastructure such as stop buttons, billing oversight, and traceability for tool calls.
The author observes that AI agents exhibit human-like failure patterns, such as overconfidence and skipping steps under context pressure, suggesting that system reliability depends more on robust validation and controlled environments than just model intelligence.
Discusses the phenomenon where AI agents appear to succeed at tasks but later reveal failures, highlighting challenges in agent evaluation and monitoring.