AI agents are causing failures that companies still cannot track

Did you know there is a type of production incident that engineering teams are not monitoring yet? This happens because it doesn't fit into any failure analysis model we know. Here's the issue: an AI agent takes an action that seems correct based on its context, but if the context is incomplete, the entire infrastructure can be affected. When reviewing the incident, three different teams might argue whether the failure was caused by the agent or the infrastructure, because we never connected these two concepts.

The problem is real and no longer just theoretical. Today, a large portion of organizations already use some type of AI agent in production, and many plan to expand this. This leads us to a crucial point no one is capturing: failures that occur amid these numbers. Agents are working, they are not cancelled, but they are generating events in the infrastructure that no one has classified as a risk.

I have experience building large-scale infrastructure automation systems, starting at Cisco and later at Splunk. During this time, I patented an intent-based chaos engineering methodology. And you know what I saw repeatedly? Companies treating autonomous agents and chaos engineering as separate disciplines. They are not. This separation is creating the next wave of major production incidents.

The decision agents don't make

To understand why this is important, we need to see what's broken in enterprise chaos governance before adding agents to the equation. Mature engineering teams have already invested in chaos engineering programs, with simulations and impact control. When a human engineer starts a chaos experiment, they make a critical assessment: they check if the system can absorb the disruption at that moment. They check dashboards, analyze error budget consumption, and assess if dependencies are stable. It's not perfect, but at least someone asks the right question before taking any action.

Now, introduce an autonomous agent that can restart services, redirect traffic, or automatically scale resources. That human questioning disappears. The agent sees an anomaly and acts. That action is a chaos event. There is no checking of SLO consumption, impact calculation, or human judgment about whether that is the best time to stress the system, which might already be overloaded.

A classic example: an agent detects high latency in a microservice and decides to restart the service cluster. The action seems correct based on the agent's training data. But it doesn't see that other services are handling traffic spikes, the connection pool is highly utilized, and a dependent database is rebuilding an index. The restart triggers a domino effect on the recovering service. What started as a latency spike, which the agent was designed to solve, turns into a cascade it was never designed to model.

Absorption capacity is a resource most systems ignore

The problem is that enterprise systems lack a common language for absorption capacity — the real-time estimate of how much additional stress a system can handle before breaking SLO commitments. Chaos engineering programs manage this implicitly, with human judgment and static thresholds that trigger too late. Agents don't manage this at all.

Through research with site reliability engineers and platform engineers, I developed a resilience budget model. The core idea is to treat absorption capacity as a consumable resource, continuously recalculated, rather than a static threshold that shouldn't be crossed.

This resilience budget is based on four live signals: the SLO burn rate, the P99 latency trend, the saturation state of dependencies, and application behavioral signals. Every chaos experiment consumes this budget. Every agent action does too. In organizations where multiple teams might be running experiments simultaneously, the budget is shared. Without a shared consumption ledger, two teams could create a combined blast radius that neither planned for. Add autonomous agents acting outside this ledger, and the accounting collapses.

Where language models help, and where they fail

Some organizations are experimenting with language models to generate chaos hypotheses from dependency graphs and incident reports. The problem is that even with this help, we still face a communication vacuum between what these models can predict and what actually happens when an autonomous agent makes a decision. And that's where we need to be careful, because that's exactly where the danger lies.