Record and replay for Python
Record a Python workflow as it runs. When 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.
A customer questions a checkout total.
Which rate did this order actually use?
What the engineer establishesThe rate changed between two items. This order used two exchange rates.
One investigation · illustrative example
The checkout completed. A customer questions the total. Rerunning the calculation now gives the expected result. The question is what happened in the original run.
The trace identifies the request and the code that ran. In this example, it does not contain the rate used by each line item.
POST /checkout · 200 OK · 483 msDid every line item use the same rate, or did a background refresh change it partway through the order?
The rate is read for each item.
The refresh happened between the second and third items.
The first two items used 1.0842; the last two used 1.0388. The source suggests this could happen. Inspecting the recorded execution establishes where it happened in this order.
A fresh run can receive different external results and execute in a different order. Replay uses the recorded results and ordering, so the Python state behind the original outcome can be inspected.
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 supported interactions with the outside world and the ordering needed to replay the Python execution. During replay, your code runs against those recorded results.
Record supported external calls, returned values, exceptions and execution ordering.
The external interactions and ordering needed to reconstruct the supported execution.
Re-execute the Python code using the recorded results and ordering.
Step through the replay and 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.
When a question remains
Traces, logs, workflow histories and saved inputs can explain many incidents. Sometimes an important question remains: which value was used at a particular point, which branch ran, or what changed between two operations?
For a supported recorded Python execution, replay lets you investigate application state after the run has finished. You can choose much of what to inspect when you know the question.
Concrete runtime values and code paths can also ground an AI-assisted investigation. We discuss supported evidence access and data handling as part of a pilot.
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.
