60 — Chaos Engineering for AI

Concept overview

Chaos engineering evaluates system behavior under deliberately introduced faults. For AI agents, faults include slow model responses, malformed tool output, stale retrieval, dropped streaming connections, duplicate events, and process termination between an external effect and its recorded receipt. The experiment tests an architectural claim, not simply whether the service can be made to fail.

A useful experiment names a steady-state measure, a fault, an expected containment boundary, and an automatic stop condition. Begin with deterministic fixtures and isolated environments; expand exposure only after observability and recovery are credible. Testing hallucination handling requires labeled semantic perturbations, not random text presented as a realistic failure model.

Why it matters in production

Proof of concept

A prototype can inject a deterministic timeout into one tool and verify a visible, bounded failure response.

Production

Production-readiness testing combines seeded replay, contract violations, crash injection, and assertions about duplicate effects and data boundaries.

Enterprise scale

Enterprise programs schedule controlled exercises, limit affected tenants, rehearse rollback, and convert every discovered weakness into a repeatable regression scenario.

Architecture components

Experiment controller

Selects scope, fault duration, eligible traffic, and emergency stop conditions.

Fault injector

Introduces transport, process, dependency, or semantic faults at known boundaries.

Steady-state monitor

Measures user-visible completion, latency, queue growth, and business invariants.

Replay fixtures

Provide reproducible tasks with expected evidence and allowed outcomes.

Recovery observer

Verifies that the system returns to acceptable operation after injection stops.

The architecture, mapped

flowchart TD
 H["Hypothesis and stop conditions"] --> B["Baseline task replay"]
 B --> I["Inject duplicate delivery"]
 I --> W["Agent workflow"]
 W --> L["Effect ledger"]
 L --> V["Assert one business effect"]
 V --> R["Remove fault and verify recovery"]
 W --> S["Abort on unsafe invariant"]

Runtime flow

1. 1

   State the hypothesis

   Specify which workflow should remain available or recoverable under one concrete fault.

2. 2

   Establish baseline

   Run representative tasks and confirm telemetry can distinguish normal variability from failure.

3. 3

   Constrain exposure

   Select an isolated test tenant or small approved traffic slice and configure abort thresholds.

4. 4

   Inject the fault

   Apply the failure at a documented point with an experiment identifier in traces.

5. 5

   Evaluate invariants

   Check duplicate actions, missing evidence, deadline behavior, and recovery status alongside availability.

6. 6

   Stop and learn

   Remove the fault, verify recovery, and preserve the failing case as a regression test.

Testing rebooking recovery before a disruption

Travel operations · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

A travel-service agent proposes rebooking options and reserves approved alternatives.

The problem

A timeout after reservation can trigger a duplicate booking during retry.

Agent requirement

Demonstrate that recovery reconciles the original reservation before issuing another command.

Architecture

A test supplier adapter creates a reservation but suppresses its response; the agent uses an effect ledger and stable booking key.

Runtime

• The experiment injects the response loss for a synthetic traveler.
• The recovery worker queries the original booking key and attaches its existing receipt.

Failure scenario

If two bookings appear, the experiment stops, releases test reservations, and records the exact event sequence.

Operational impact

Measure invariant violations, detection time, and recovery duration; passing one experiment supports only the tested fault and workload conditions.

Architecture tradeoffs

Failure scenarios & recovery

Common architecture mistakes

Injecting failures without a hypothesis

Define measurable expected behavior first.

Testing only HTTP errors

Include duplicate events, malformed content, and ambiguous side effects.

Declaring success from eventual response

Assert business invariants and recovery time explicitly.

When to choose this pattern

Choose it when

• Use before relying on automatic recovery controls.
• Use after changes to retry, failover, or persistence behavior.
• Use for workflows with costly external side effects.

Avoid it when

• Avoid uncontrolled experiments with real irreversible effects.
• Do not start with broad production exposure and weak telemetry.
• Do not equate one successful drill with universal resilience.

Architecture checklist

• Write a falsifiable resilience hypothesis.
• Define safe synthetic identities and data.
• Set independent abort controls.
• Tag traces with experiment identifiers.
• Assert effect and evidence invariants.
• Turn discovered failures into repeatable tests.

Related concepts

• 35 — Adversarial Prompt Testing
• 41 — Idempotent Tool Execution
• 49 — Timeout Policies
• 51 — State Rollbacks
• 52 — Model Redundancy / Multi-Provider Failover
• 59 — Cascade Failure Prevention

Primary references

• AWS Builders Library: Timeouts, retries and backoff with jitter
• AWS Builders Library: Making retries safe with idempotent APIs
• Kubernetes: Liveness, readiness and startup probes