Replay bundles

To prove a fix works, you have to re-run the exact situation that failed. A replay bundle is the self-contained snapshot that makes that possible.

What’s in a bundle

Lumni assembles a bundle from a failing run:

• Inputs — the original user request and any run parameters.
• Tool schemas & responses — what each tool was called with and what it returned, so tools can be replayed or mocked faithfully.
• Context snapshot — the prompt, retrieved documents, and history that reached the model.
• Environment — model id and version, dependency versions, and the policy version in force.

The point is determinism: replay the bundle and you should reproduce the original failure before you change anything.

What can be replayed

Agent type	Replay support
LangGraph	Native, stateful replay of the graph
SDK-instrumented runners	Bring-your-own runner via a replay adapter
Deterministic agents	Anything with fully captured inputs and tool I/O

Non-deterministic external calls are handled by replaying the captured tool responses from the bundle rather than hitting live services — so a replay is safe and repeatable.

Reproduce first

A fix is only meaningful if the bundle reproduces the original failure. If a replay of the unmodified bundle already passes, the failure was flaky or environment-dependent — Lumni will tell you the evidence is uncertain rather than claim a fix works.

Next

Once you have a bundle that reproduces the failure, test a fix against it.