Chaos Engineering for AI Systems: Deliberate Failure, Before It Chooses Its Own Timing

Chaos engineering is the practice of breaking things on purpose, in controlled conditions, to find out how the system actually behaves — rather than how the architecture diagram says it will.

For AI systems it is unusually relevant, because you have a hard dependency on an external service you do not control, cannot fix, and whose outages are not on your maintenance calendar.

The question is not whether your model provider will have a bad day. It is whether you will find out how your system responds during that day or before it.

The experiment format#

Chaos engineering is not "unplug things and see". It is a hypothesis test:

Steady state:  95% of requests complete in <5s with a grounded answer
Hypothesis:    if the model API returns 503 for 5 minutes, requests queue and
               retry, users see "still working", nothing is lost, and no
               duplicate actions are taken
Blast radius:  test environment, synthetic traffic
Stop condition: any data loss, or queue depth > 1000
Result:        <what actually happened>

Two parts are non-negotiable. State the hypothesis first — otherwise you will rationalise whatever happens. Define a stop condition — otherwise an experiment becomes an incident.

Failures worth injecting#

The provider#

Complete outage. Model API returns errors for a sustained period. Does the queue hold? Does the user see something honest? Is anything lost?

Slow, not down. Harder and more common. Responses take 30 seconds instead of 2. Does anything time out cleanly, or does the whole system stall behind a connection pool?

Rate limited. Sustained 429s. Does backoff work, or does retry storm make it worse?

Malformed responses. Truncated JSON, empty content, an unexpected schema. Does the parser fail safely or corrupt state downstream?

Partial degradation. Responses arrive but are poor. This one has no error to catch, and most systems have no detection for it at all.

Around it#

Retrieval down. Vector store or search unavailable. Does the system refuse honestly, or answer ungrounded from training data? The second is the dangerous behaviour and it is the default.

Retrieval returning nothing. Not an error — an empty result. Does it say "I don't know", or invent?

Tool failures for agents — timeout, error, wrong shape. Does the agent retry sensibly, try another route, or stop silently? Silent give-up is the most common and the worst.

Stale context. The document corpus is a week out of date. Nothing errors and the answers are confidently wrong.

Cost limit reached. Spend cap hit mid-task. Does it stop cleanly or leave work half-done?

The scenario to run first#

If you run one experiment: the model API is unavailable for five minutes during normal traffic.

It is the most likely real failure, it exercises queueing, retry, timeout, user messaging and data integrity at once, and the results are usually surprising. Common findings:

• Timeouts far longer than intended, so threads pile up and unrelated features stall
• Retry without backoff, turning a brief outage into a longer self-inflicted one
• No user-facing message at all — just a spinner
• Non-idempotent operations retried, producing duplicates
• Queued work lost on restart

What "graceful" means here#

Define it before testing:

Running it safely#

Test environment first, always. Production chaos experiments are for mature practices with real observability, not for a first attempt.

Off-peak, with the team present and a stop condition agreed in advance.

Announce it. An unannounced experiment that looks like an incident wastes everyone's time and destroys goodwill for the practice.

Record everything — what you injected, what happened, what surprised you. The surprises are the value.

Fix, then re-run. An experiment that finds a problem and is never repeated has not verified the fix.

The relationship to the incident plan#

Every chaos experiment is a rehearsal. The findings should feed directly into the incident response and the runbooks — and if the experiment revealed that nobody knew who decides, that is a more valuable finding than any technical one.

FAQ#

Isn't this only for large systems?#

No. A small system with one external dependency has a concentrated risk, not a small one. The experiment is proportionally simpler: turn off the dependency, watch what happens.

How is this different from normal failure testing?#

Failure testing checks that a component handles an error. Chaos engineering checks how the whole system behaves when a real dependency degrades — including queueing, user experience and recovery, which unit tests never touch.

Should we run this in production?#

Eventually, and not first. You need monitoring good enough to see the effect and stop it, and a team comfortable with the practice. Test environments answer most of the questions at a fraction of the risk.

What if we find something serious?#

Stop the experiment and fix it — that is a successful experiment, not a failed one. Finding it on your terms is the entire point.

How often?#

Quarterly for anything customer-facing, and after any change to how the system handles failure. Also after adding a dependency, because you have just added a new way to fail.

What else is coming for Chaos Engineering