Why AI agents crash in production: the architecture problem

On 2026 11 8, a developer writing in DEV Community's AI section published "Why AI Agents Break Rules: Five Failure Modes and Defense-in-Depth Guardrails" (originally hosted on tamiz.pro). The author had logged every rule violation observed across one year of running agents in production, and grouped the failures into five categories, including hard-constraint violations , forgetting constraints buried in long context , and tool-signature hallucination. The article's central claim is that agents do not break rules because they are rebellious but because they are probabilistic text generators wrapped around deterministic systems; the boundary between those two worlds is where compliance tends to fail. The author's conclusion is that agents fail not at the level of intent, but at the level of architecture, and therefore proposes a set of defense-in-depth engineering practices aimed at keeping agents inside an operable boundary.

On 2026 11 9, the same developer returned to DEV Community's AI section with "AI Agent Demos Run Fine. Why Do They Fall Apart in Production?", extending the earlier argument. He notes that building an agent that works in a demo is no longer particularly difficult: connect an LLM to a few tools, give it a task, add some memory, and something impressive can run surprisingly quickly. The picture changes once the same agent is moved into a real environment. Sometimes it calls the wrong tool, sometimes it repeats an action, sometimes it gets stuck on what should have been a simple problem. His diagnosis again points away from the model itself and toward the architecture around it, especially the temptation to let the LLM control every link of decision-making, execution, error handling and result verification, where it arguably should not.

Taken together, the two posts describe a single line of argument rather than separate events: an observation drawn from a year of production logs, formalized into five failure modes and a defense-in-depth approach , then reframed the next day as a practical account of the demo-to-production gap. The point of consistency is that these failures are read as architectural design problems, not signs that the underlying model is insufficient. What remains open in the material is how specific guardrails map onto specific failure categories. Progress so far: the developer has published analysis and recommendations but has not, in either post, offered measured results of deploying those guardrails.