Record and replay for Python
Record a Python workflow as it runs. When a test fails, an agent takes an unexpected action, or a customer questions a result, replay the recorded execution and inspect the values and code paths behind it.
One investigation · illustrative example
The checkout completed and a customer questions the total. A rerun gives the expected result. What happened in the original run?
The refresh landed between the second and third items. This order used two rates.
The source shows this could happen. The recording shows that it did. See the same race investigated in a failed CI test →
The questions behind the investigation
The model and tool responses may be in your trace. You still need to establish the Python state, transformation, retry or branch that turned them into an action.
Which decision path did this workflow actually take?
The calculation finished successfully. Its inputs or external data may have changed since. Investigate the recorded calculation and the intermediate values that produced this result.
Why did this particular run produce that value?
A CI test passes on rerun, or a customer's Python integration fails in a way the support report cannot explain. An agreed recording gives the investigation an original execution to work from.
What happened in the run that failed?
How it works
Retrace records your program's interactions with the outside world and the order its threads ran. During replay, your code runs against those recorded results.
Record external calls, returned values, exceptions and thread ordering.
The external interactions and ordering needed to reconstruct the execution.
Re-execute the Python code using the recorded results and ordering.
Step forwards and backwards through the replay. Inspect the Python values and code paths behind the result.
A workflow can look successful and only be questioned later. For a pilot, we agree what to record, which completed runs to retain, and how long they need to remain available. The relevant code and execution environment must remain available too.
Private preview
We assess a specific investigation and a manageable workload together. The first step is to establish whether replay can recover evidence that would be useful to your team.
Retrace reconstructs supported Python execution state. It does not recover an execution that was never recorded, the internal computation of a model, opaque native or GPU state, or the internal state of a remote service. Original wall-clock latency and kernel scheduling are not reconstructed by Python replay. Deliberately removed data cannot be assumed recoverable.
For an AI application, the recorded response is what the application received. Replay investigates how the Python code behaved given that response.
Talk to the founders
Tell us about an investigation your team found difficult: an unexpected agent action, a disputed result, or a Python failure that was hard to explain.
We'll discuss what happened, what your existing tools recovered, and what evidence was missing.
Retrace is built in London by Henry Yates and Nathan Matthews. We are working with engineering teams to understand where original execution evidence can make an investigation more useful.
