Game Days for Agents: Rehearsing the Failure You Can't Reproduce

Classic chaos engineering rests on a quiet assumption: if you inject the same fault twice, you get the same failure twice. Kill the pod, watch the failover, fix the gap, kill the pod again to confirm. The entire discipline — hypothesis, blast radius, steady-state metrics — presumes a system deterministic enough that the experiment is repeatable.

Agent systems break that assumption at the root. Inject a tool timeout into an agent run and the model reroutes its plan — one time it retries, another time it substitutes a different tool, a third time it confidently fabricates the result it never fetched. Run the identical fault against the identical prompt and you get a different trajectory, because the failure path runs through a stochastic planner. The failure you saw in production last Tuesday will never happen again in exactly that shape. And that's precisely why you have to rehearse it anyway.

The teams that internalize this stop asking "can we reproduce the incident?" and start asking a better question: "when a failure like this happens, do our people and our tooling do the right thing?" That question has a well-worn answer from the SRE world — the game day — but running one for an agent system requires rethinking what you inject, what you observe, and what artifact you're actually trying to produce.

Why Replay Doesn't Work When the Failure Path Is Stochastic

In a deterministic service, an incident leaves behind a reproduction recipe. The postmortem says "when the cache node dies during a write burst, the fallback path deadlocks," and you can build a regression test that pins that exact behavior forever.

Agent incidents don't leave recipes. They leave one sample from a distribution. The trace shows that the model, having received a 503 from the search tool, decided to answer from stale context and skipped the verification step it usually performs. But that decision was a probabilistic branch. Replay the same context at the same temperature and the model may take the safe path nine times out of ten. Your incident was the tenth.

This has two corrosive effects on traditional reliability practice:

• Regression tests rot into false confidence. You can pin the trace and assert the fix, but you've pinned one trajectory through a space of thousands. The next incident takes a neighboring path your test never covers.
• Postmortem action items skew toward the specific. Teams add a guardrail for the exact fabrication they saw, the exact tool that timed out, the exact phrasing that leaked. The distribution that produced the failure is untouched.

Research on chaos engineering for LLM-based multi-agent systems confirms what practitioners see in traces: the most dangerous failures are communication failures and cascading faults between agents, precisely because they're the hardest to trace back to their origin — and the least likely to recur in the same shape. You cannot regression-test your way out of a distribution. You can only build a team and a tooling stack that handles whatever the distribution throws next. That's a rehearsal problem, not a reproduction problem.

What to Inject: Four Drill Families for Agent Systems

A game day is a scheduled, time-boxed exercise where you deliberately degrade the system and run your real incident process against it — same on-call, same dashboards, same escalation paths. The AWS Well-Architected reliability pillar has prescribed this for years for infrastructure. For agent systems, the injection surface is different. Four families cover most of the space.

Tool-layer fault injection. This is the closest analog to classic chaos: wrap your agent's tool calls in a proxy that injects timeouts, 429s, 500s, slow responses, and — most interestingly — plausible but wrong results. The last one is the agent-specific twist. An infrastructure engineer worries about the tool being down; an agent engineer should worry more about the tool returning a stale record that the model weaves into a confident answer. Open-source harnesses for agent chaos now exist that do exactly this kind of interception, but a game day doesn't need sophistication: a proxy flag that fails 20% of calls to your retrieval service for one hour is a complete experiment.

Degraded-model drills. Silently route the agent to a weaker or older model mid-exercise and see who notices, and how. This rehearses two real production scenarios at once: the provider brownout where you fail over to a backup model, and the quiet quality regression after a model update. The scary outcome isn't that quality drops — it's discovering that nothing on your dashboard moves when it does. If your operators can't tell the difference between the flagship model and the fallback from the outside, neither can your monitoring.

Poisoned-context scenarios. Plant a contaminated document in the retrieval corpus, a wrong fact in agent memory, or an adversarial instruction in a source the agent reads. Then watch how far it propagates before anyone can (a) detect it, (b) trace which outputs it touched, and (c) purge it. This drill almost always exposes the same gap: teams can delete the poisoned source, but nobody can answer "which of the last 4,000 responses were influenced by it?" That answer requires provenance in your traces, and you'd rather learn it's missing on a Wednesday afternoon than during a real contamination event.

Human-escalation fire drills. Trigger the condition that's supposed to page a human — the agent about to take an irreversible action, the confidence score below threshold, the kill switch that needs pulling — and time the human side. Who gets paged? Do they know how to pause the agent fleet without killing the whole product? Does the kill switch actually stop in-flight runs, or only new ones? Incident response teams that run game days report that the exercise value concentrates here: procedures that read fine in the runbook fall apart when a human executes them under a clock.

Pick one family per game day. Combining them feels thorough but destroys the signal — when everything is broken, you can't tell which gap caused which fumble.

Loading…