In 2025, a widely reported coding-agent incident involved a production database being deleted during an active development session. Public reporting supports the deletion; it does not establish every quoted line later repeated about the incident.
The useful lesson is not that every agent is unsafe or that every mistake can be eliminated. It is that an agent can create side effects faster than a human reviewer can reconstruct them unless permissions, evidence, and recovery are designed into the workflow.
Gartner forecasts that more than 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. That is an analyst forecast, not a measured failure rate for all deployed agents.
Why agents are not software
Traditional software can often be tested against deterministic interfaces. Agent behavior adds model sampling, changing external state, tool permissions, and ambiguous instructions. A test that passed yesterday can fail after the model, prompt, tool, policy, account state, or data changes.
An agent is a policy. The policy makes decisions in a space that shifts every time the data changes. A test that passes today may fail tomorrow, not because the agent broke, but because the inputs changed. A bug that is fixed in one code path reappears in another because the policy generalized the wrong way.
Deploy an agent like software, and a small percentage of runs do things no reviewer approved. At scale, a small percentage is the headline.
The failure modes worth naming
Cascading tool calls. If ten independent steps each succeed 95% of the time, the probability that all ten succeed is about 60%. Real workflows are not always independent, but the example shows why step-level evidence matters.
Silent completion lies. The model produces "task completed" because the model was trained to produce "task completed" when the conversation ends. Whether the task actually completed is a different question. The model cannot tell. The calling code usually cannot tell either.
Infinite loops. An agent asked to research a topic opens ten tabs, asks the same question ten ways, never converges, and burns fifty dollars of inference cost before the watchdog kicks in. If the watchdog kicks in at all.
Tool misuse. An agent asked to "clean up old data" interprets cleanup as deletion. A reviewer would have asked a clarifying question. The agent does not know to.
Each failure can become a reviewed test case when the workflow captures enough evidence. Capture alone does not guarantee recovery; teams still need an executable test, an owner, a release policy, and an operating path for rollback or repair.
What the teams that keep their agents in production actually do
Three patterns show up consistently.
Sandboxing and resource limits. An agent gets a scoped environment, a wall-clock budget, a token budget, and a list of tools it is allowed to touch. A runaway agent hits the limit before it hits production. This is infrastructure, not a policy choice.
A regression bank of reviewed failures. Selected incidents and reviewer overrides can become reusable cases. AuraOne can persist registered cases and imported replay evidence, but coverage is not universal and canonical model execution remains operator-assisted.
Risk-based escalation. High-risk actions should require explicit approval before execution. AuraOne can record criteria, reviewer evidence, and release decisions where the workflow is configured for them; it does not independently guarantee that every external agent action is intercepted.
These three together do not eliminate agent failure. They turn agent failure from an existential risk into an operational one.
What starting narrow actually means
The safer operating pattern is to start with one scope, one data type, and one accountable team. Avoid giving a general-purpose assistant broad access to an entire estate before the organization has tested permissions, failure handling, and approval boundaries.
Expansion criteria should be defined by the program. Override rate, task completion evidence, incident severity, recovery performance, and regression results can all matter. There is no universal two-quarter threshold.
The teams that skip this step are the teams that produce the viral failures.
The uncomfortable tradeoff
An agent with real autonomy and real guardrails moves slower than an agent with no guardrails. Demos are faster without them. Production is slower with them. A team comparing the demo speed to the production speed will conclude the guardrails are the problem.
They are not the problem. They are the product.
The teams that stay in production are the teams that accepted the tradeoff. The teams that shelve their agents in 2027 are the teams that did not.
What to do this quarter
If you are running agents today, three checks.
One. Is every agent action replayable from a captured trace? If the answer is "mostly, except when the model calls a tool that mutates state," the replay story is not real yet.
Two. Is the launch decision checked against the reviewed failures that matter for this workflow? If the regression bank is "the engineer remembers the last few issues," the gate is not real yet.
Three. Is every action above a defined risk threshold escalating to a credentialed human before it executes? If escalation happens after the fact, escalation is not the right word for what is happening.
Three questions do not predict whether a program will survive, but they expose whether the operating record is strong enough to support a release decision.
Source context
- Gartner: More than 40% of agentic AI projects will be canceled by the end of 2027
- TechCrunch: Replit incident context
Ready to deploy agents with real guardrails?