Agents and automation
An agent took an unexpected action.
Your trace has the model and tool responses. Replay shows the Python state and branch that turned them into an action.
Record and replay for Python
The run is over. The execution isn't gone.
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
One order. Two exchange rates.
The checkout completed and a customer questions the total. A rerun gives the expected result. What happened in the original run?
Original run
thread Aitems 1–2items 3–4sum
thread Brefresh
two rates · 424.60
unexpected total
unexpected total
Ordinary rerun
thread Aitems 1–2items 3–4sum
thread Brefresh
one rate · 433.68
expected total
expected total
Recorded replay
thread Aitems 1–2items 3–4sum
thread Brefresh
two rates · 424.60
original evidence
original evidence
The finding
The refresh landed between the second and third items. This order used two rates and totalled 424.60, not 433.68.
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
An unexpected result deserves an explanation.
Historical calculations
A price, bill or decision is challenged.
The calculation succeeded, but its inputs may have changed since. Replay shows the intermediate values behind this particular result.
CI and SDK support
A failure is hard to reconstruct.
A CI test passes on rerun, or a customer's integration fails and nobody can reproduce it. Replay the original run, not a new attempt.
How it works
Record while it runs. Investigate afterwards.
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.
While your application runs
Your chosen workload
Record external calls, returned values, exceptions and thread ordering.
The recording
The external interactions and ordering needed to reconstruct the execution.
When an outcome needs investigating
Replay
Re-execute the Python code using the recorded results and ordering.
Investigate
Step forwards and backwards through the replay. Inspect the Python values and code paths behind the result.
The recording needs to exist when the question arrives.
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
Start with one Python worker or workflow.
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.
- Runtime and dependencies
- Retrace runs on CPython 3.11–3.15 on 64-bit Linux and macOS. We check your libraries, native extensions and concurrency against the current build. See all requirements →
- Recording and data
- We agree what to record, which completed runs to keep, where recording and replay run, and who may inspect the data.
- A useful first investigation
- We choose a concrete question and agree how to judge whether the recording supplies the missing evidence. If you want AI-assisted investigation, we agree how it can access that evidence.
What a replay can and cannot show
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
What was difficult to establish?
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.
Building a better way to understand software execution.
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.
FoundersHenry Yates and Nathan Matthews
AdviserYury SelivanovCPython core developer, author of async/await (PEP 492), creator of uvloop
Backed byPreston-Werner Ventures