Intent-Based Chaos Testing Is for When AI Acts Confident and Wrong
An AI agent caused a four-hour outage by mistaking a batch job for an anomaly. It had the right permissions and total confidence. Intent-based chaos testing lets builders spot these failures before production crumbles

Late one night, an observability agent running in production flagged an elevated anomaly score across a cluster. The score sat at 0.87, comfortably above the 0.75 threshold. The agent held valid credentials and access to the rollback service. So it used it. The agent rolled back a scheduled batch job it had never encountered before and triggered a four-hour outage that didn't need to happen.
This wasn't a security breach. No attacker stole a key. Every identity check passed. The agent simply acted within its permissions and made a catastrophic misjudgment. That should unnerve anyone shipping autonomous systems right now.
Context Is the Blind Spot
Most enterprise security programs rest on a simple formula. A valid credential plus authorized access equals a safe outcome. That assumption collapses the moment an AI agent enters the loop. The credential was real. The access was authorized. The decision was still wrong.
The agent had never seen that particular batch job. Its training or context window didn't include the pattern of a scheduled overnight workload. It saw a spike, assigned a high confidence score, and treated normal operations as a threat. We spend enormous energy testing that agents get correct answers right. We spend far less testing what happens when they get wrong answers confidently.
Intent-Based Chaos Testing: Breaking Things on Purpose
Intent-based chaos testing fixes this. Instead of throwing random noise at a model, you deliberately construct scenarios where the context looks risky but is actually harmless. Feed the agent a scheduled job that mimics an intrusion. Present a traffic spike that is actually a marketing campaign. Then watch what it does.
Traditional chaos engineering tests infrastructure resilience. This tests reasoning resilience. You need to know if the agent pauses, escalates, or blindly fires. Proving uptime is not the point. Proving restraint is.
Any builder shipping an agent with write access to a database, a deployment pipeline, or a customer account needs this layer. Vibe coding an agent in an afternoon is now trivial. Testing whether that agent destroys data at 2 a.m. because it misread a log pattern is still hard. Intent-based chaos testing closes that gap.
Build Agents That Know When to Pause
At Botflow, we see builders deploying AI agents that orchestrate real backend tasks. Convex, the reactive database and serverless backend under the hood, gives you durable workflows and real-time state. You can insert human checkpoints or secondary validation steps before an action becomes irreversible. You don't have to let the agent run solo on its first encounter with a new pattern.
Design your orchestration so high-confidence predictions still route through a lightweight approval layer, or at least a log-and-notify hook, when the scenario looks novel. Confidence should prompt a check, not an irreversible action. The rollback service should never sit one hop away from the model's output.
Skip the bureaucracy. Give the agent a memory of normal operations and a mechanism to ask for help when the distribution shifts. That scheduled batch job should have lived in a knowledge base the agent checked before pulling the trigger.
Shipping an agent without testing its confident failures is like shipping a checkout form without validation. Intent-based chaos testing is that validation layer. Build it into your agent's lifecycle now, or your on-call rotation will pay for it later.