Chaos engineering for agent systems means deliberately injecting realistic failures — a slow or failing tool call, an unreachable model provider, a guardrail service that stops responding, a malformed model response mid-task — into a controlled environment to verify that your fleet degrades the way you designed it to, rather than the way it happens to. The practice borrows its name and its discipline from classic chaos engineering, but the failure catalog is different, because an agent's dependency graph and its correctness model are both different from a conventional service's.
This is the practical, adversarial-to-your-own-system companion to the failure-mode design in high availability for an AI control plane: that post tells you what your fail-open and fail-closed decisions should be; chaos engineering is how you find out whether the system actually implements them.
Why agent systems need a different chaos catalog
Classic chaos engineering — killing an instance, partitioning a network, filling a disk — tests failures in infrastructure that agent systems have too, and those experiments are still worth running. But an agent's task can fail or degrade in ways that have no analog in a conventional request-response service:
- A tool call succeeds technically but returns unexpected data, and the agent proceeds on bad input rather than the call simply erroring out.
- A multi-step task is interrupted partway through, leaving side effects from the steps that already ran — a partially completed transaction, a message half-sent — that a simple retry from the start would duplicate rather than fix. See cascading failures in multi-agent systems.
- A guardrail evaluation service is unreachable, and the system has to make a decision — fail closed and block the action, or fail open and let it through — under exactly the conditions where the guardrail was needed most. See designing guardrails: block, redact, warn for how that disposition should be decided in advance.
- A model provider degrades rather than fails outright — slower responses, occasional malformed output, subtly lower-quality completions — which doesn't trip a binary health check the way an outright outage does.
- An agent loops or retries indefinitely in response to a failure it doesn't recognize as terminal, turning an availability incident into a cost incident simultaneously.
None of these are instance failures. They're failures in the semantic layer of what an agent does, and they require injecting failure at the tool-call, provider-response, and guardrail-evaluation boundaries rather than only at the infrastructure boundary.
Designing an experiment: blast radius and kill switch first
Every chaos experiment needs two things decided before the failure is injected, not during:
Blast radius. Scope the experiment to a specific agent, organization, or task type in a non-production environment first. An agent system that reacts to injected failure by retrying aggressively or fanning out to a fallback path can turn a contained experiment into an uncontained one if the scope isn't bounded and enforced.
An independent kill switch. The mechanism to stop the experiment must not depend on the component you're breaking. If you're injecting a guardrail-service outage, the kill switch that ends the experiment cannot itself route through that same guardrail service. See rogue AI agents and kill switches for what an effective, dependency-independent kill switch looks like — the same properties that make it a good containment control make it a good chaos-experiment abort mechanism.
Skipping either of these turns the exercise from "controlled chaos" into "uncontrolled incident with extra paperwork."
A failure catalog for agent chaos experiments
| Injected failure | What you're testing | Failure signature if the system is wrong |
|---|---|---|
| Tool call times out mid-task | Does the task resume, retry safely, or fail cleanly? | Duplicated side effects, or a task stuck indefinitely |
| Model provider returns errors | Does the fallback route engage, and is its output acceptable? | Task failures pile up instead of routing to the configured fallback |
| Model provider degrades silently (slow, occasionally malformed) | Does anything notice, given that health checks stay green? | No signal until task success rate erodes and someone happens to look |
| Guardrail service unreachable | Does the blocking-disposition rule fail closed as designed? | An action proceeds that should have been blocked |
| Downstream queue backs up | Does backpressure engage, or do tasks fail outright? | Task failures instead of graceful queuing; see DLQ recovery for failed agent jobs |
| Partial task interruption (kill the worker mid-task) | Is the task resumable from a checkpoint, or does it duplicate work on retry? | Duplicated actions on the resumed attempt |
| Cascading agent-to-agent failure | Does one failing sub-agent bring down the orchestrating task, or degrade gracefully? | Full task failure from a single non-critical sub-agent failure |
Correctness is the metric chaos experiments usually miss
A conventional chaos experiment succeeds if the system stays available — requests keep getting served, error rates stay bounded. For an agent system, availability is necessary but not sufficient. A fleet can stay fully "available" during an experiment — every health check green, every request answered — while quietly producing wrong or lower-quality task outcomes, because agent output correctness is a distribution, not a pass/fail gate.
This means an agent chaos experiment needs an evaluation step alongside the availability check: run your existing task-quality evaluation against tasks completed during the experiment, and compare the success and quality distribution to your baseline. See agent evaluations: scoring quality and regressions and eval datasets and golden sets for agents for the evaluation machinery this depends on. An experiment that reports "no incidents" based on uptime alone, while task quality quietly degraded, has told you nothing about the failure mode that actually matters most for agent workloads.
Where to start
Don't start with an exotic failure mode. Start with the ones your own incident history and threat model already say are plausible:
- Pull your last several incidents — real ones, not hypothetical — and identify which ones involved a dependency failure (tool, provider, guardrail, queue) rather than a code defect. Those are your first experiment candidates, because they're proven to happen.
- Check your threat model documents for failure modes you've already reasoned about but never tested — see threat model: runaway agent spend as an example of a documented failure mode that's a natural chaos-experiment candidate.
- Run the experiment in a non-production environment first, with production-representative traffic patterns if you can arrange them, before ever considering a production game day.
- Graduate to production only for experiments where the blast radius and kill switch have already proven reliable in the lower environment, and only with the same scoping discipline.
A worked example
You suspect your fallback model routing has never actually been exercised under load, only configured. The experiment:
- Scope the blast radius to a single non-production organization with synthetic but representative task traffic.
- Confirm the kill switch — a manual override that stops the experiment and restores normal routing — works independently of the routing path being tested, and verify that before the primary experiment starts.
- Inject a sustained error response from the primary model provider for that scoped traffic.
- Observe: does the fallback engage, does latency change acceptably, and — the step usually skipped — does the fallback's output quality hold up against your evaluation baseline?
- If the fallback works but its output quality is materially worse, you've found a real gap: a fallback that keeps the lights on while quietly producing worse task outcomes is not the safety net it looked like on paper.
- Document the result, fix what broke, and re-run before considering the fallback path validated.
Frequency and ownership
A chaos program that runs once and stops is a snapshot, not a practice. Failure modes that are absent today can appear after a prompt revision, a new tool integration, or a provider change, so the experiments worth repeating are the ones tied to components that change frequently. Assign an owner to each experiment in the catalog — the team responsible for the dependency being tested, not a central chaos team acting alone — so that fixing what an experiment finds has a clear home rather than becoming an orphaned finding in a shared document.
A reasonable cadence: re-run the experiments tied to your most volatile dependencies — the ones with frequent prompt, policy, or provider-routing changes — on a fixed schedule, and re-run any experiment whenever the component it targets changes materially, rather than waiting for the next scheduled cycle. An experiment that hasn't been re-run since the system it tests last changed is testing a system that no longer exists.
What good looks like
A mature agent chaos practice has a documented failure catalog specific to the agent's dependency graph — not just infrastructure kill experiments borrowed from a conventional service. Every experiment has a bounded blast radius and a kill switch verified independent of the failure under test. Correctness, not just availability, is measured during and after the experiment. And the failure modes tested are the ones your own incidents and threat model already flagged as plausible, exercised on a recurring cadence rather than once and filed away.