Why replay matters
Agents are nondeterministic: same prompt, different run, different tool calls. That is fine for exploration and terrible for accountability. When a run produced a bad outcome, you need to know whether the outcome was inevitable or accidental. When a run produced a good outcome, you need to know whether you can get it again.
Replay answers both. It separates the agent's decisions from the world's responses: re-run the same calls with the same inputs, and see what reproduces and what does not.
How receipt-based replay works
- Extract the call sequence. From the run's receipts, ordered by sequence number: every tool, every argument, every input byte.
- Re-execute in order. Call each tool again with the recorded canonical inputs, in the recorded order.
- Compare outputs. For each call, compare the new output bytes to the receipt's recorded output bytes.
- Classify divergences. A match means that step is deterministic and reproducible. A divergence means nondeterminism entered there: a changed external state, a time-dependent value, a stochastic tool.
The receipts make this possible because they record inputs and outputs as canonical bytes, not summaries. A summary cannot be re-executed. Bytes can.
What replay proves
- Reproducibility. A run whose receipts all match on replay is reproducible: same inputs, same outputs, checkable by anyone.
- Fault location. The first diverging receipt marks where the run stopped being deterministic, which is usually where the investigation should start.
- Counterfactuals. Change one input and replay the rest: what would the run have done? The receipts give you the baseline to compare against.
- Regression testing. Replay yesterday's receipts against today's agent version. New divergences are behavior changes, caught mechanically.
Replay needs history first
Replay consumes the tool call history. If your history is receipt-backed, replay is mechanical. Read the tool call history guide.
The receipt requirements for replay
Not every record supports replay. The receipt must contain the exact canonical input bytes for each call, the observed output bytes, the execution order via sequence numbers, and a commitment binding them. AER-1 receipts, published as the IETF Internet-Draft draft-zambo-aer1, carry all four by definition: tool, caller, timestamp, canonical inputs and outputs, SHA-256 commitment, sequence position.
Without canonical bytes, replay is guesswork. Without commitments, you cannot tell whether the replayed inputs are the real ones. The receipt format is the replay format.
Try the replay primitive
Mint a real AER-1 receipt for a real tool call, free, no signup. The canonical bytes in that receipt are exactly what a replay would re-execute.