Retrace

Debug AI agents by replaying and forking runs

Productivity

Developer Tools

Artificial Intelligence

GitHub

Visit WebsiteSee on Product HuntLinkedIn ⧉Github ⧉Twitter ⧉

Congrats on the launch. Replaying tool calls from the tape instead of re-executing them is the right default, that alone puts it ahead of most homegrown replay scripts I've seen. The question I'd need answered before pointing this at a client project: my tool args and prompts regularly carry things like bearer tokens and customer emails, so when a trace is stored or shared with a teammate, does Retrace redact any of that or does the span keep everything as-is? Redaction at the SDK level would be a real selling point for the paid tier.

The first-divergence approach surfaces an input-side problem I've hit in my own agent harness: volatile tokens the harness itself embeds in prompts — timestamps, run ids, sampled examples — make every replay look like it diverges at step 1, before any real regression. My fix was blunt: ban wall-clock and randomness inside the orchestration layer entirely (time gets injected as an argument), so replays are byte-stable by construction. Curious where Retrace draws this line: do you normalize/mask known-volatile spans when computing first divergence, so a timestamp delta doesn't count as a fork point — or is the recommendation to make the harness deterministic upstream, like I did? And if it's masking, is the mask list configurable per project? Feels like the difference between a diff you trust and a diff you learn to ignore.

The failures that actually bite me only show up on a real user's weird input in prod, never when I'm testing locally, so recording a run and replaying it after the fact is the dream. Two Qs: can I ingest traces from a deployed backend (not just a local dev harness), and since those recordings carry real user messages, is there any redaction/PII control before a trace gets stored or shared?

Spent a few minutes replaying a flaky agent run and being able to fork the exact trace to try a different prompt without rerunning the whole thing was honestly a nice surprise. The tool call breakdown finally makes it obvious where my agent was looping.

How does the free tier handle traces that get close to the limit mid-session — does it cut off or let you finish and just throttle new ones?

Love how clean the replay view is, being able to scrub through each LLM call and tool invocation without losing context makes debugging agents feel way less like guesswork.

The replay feature is genuinely useful, I reran a flaky agent run and could pinpoint exactly where it stalled without digging through logs. Free tier is enough to actually evaluate it before committing.

Finally something that makes debugging AI agents less painful. The forking feature let me branch off a stuck trace and rerun it with a different prompt in like a minute. Super practical for anyone shipping agents right now.

this solves a problem every team building agents eventually runs into.

how well does it scale when an agent has dozens of tool calls, nested workflows, and multiple sub-agents? would love to know how you've approached visualizing complex traces.

congrats on the launch!

Finally a way to actually see what my agents are doing under the hood. The replay feature saved me a ton of time figuring out why one tool call was looping.

The replay-from-tape answer makes sense for stopping side effects re-firing, but there's a subtle failure once you fork and swap the model. The new branch might call the same tool with different arguments than the recorded run did, so the taped response is now the answer to a question the new path never asked. Do you match a replay on the tool name only, or on the actual call arguments, and what happens when a forked run makes a tool call that has no matching entry on the tape?

the git branching analogy for forking a run is the right mental model, most "replay" tools stop at showing you what happened instead of letting you actually change the input at the broken step and re-run from there. i've lost hours re-running an entire agent chain from scratch just to test one fix at step 8. does forking work if the tool call at that step had side effects, like a real API write, or only for pure LLM steps

The fork-as-git-branch model is the right call for agent debugging — re-running a whole prompt throws away the exact upstream state that caused the break. The thing I'd need pinned before wiring this into a real stack is side effects: when a forked run re-executes downstream live, does a tool call that writes to a DB or hits a payment/email API actually fire again, or can you stub specific tools so a fork doesn't repeat real-world writes? Being able to mark tools as replay-only vs live seems like the difference between using this on prod agents or only read-only ones.

Forking a run like a git branch is exactly how agent debugging should work. Replay alone rarely helps when the failure came from one weird tool response ten steps in.

Also went through your forum thread on separating real regressions from provider noise — nice to see nondeterminism treated as a first-class problem (first-divergence diff + verdict) instead of being waved away.

One thing I couldn't find though: when everything downstream of the fork runs live, do the agent's tool calls actually execute?

I work on agents with real side effects (checkout, payments, emails), and mocking those from the recording would be the difference between "safe to fork production runs" and not.

Replay + fork is exactly how agent debugging should work. Today my 'debugging' is reading transcripts of production calls and guessing which turn derailed it - being able to fork from the exact step and test a fix against the same context would save hours. Does it work with voice agents / live conversation logs, or is it aimed at tool-calling agents? Congrats on the launch.

For Retrace, when you say users can replay and fork runs, does the fork preserve the full context of the original AI agent run, or is it more about starting from a selected point in the trace? I can imagine both being useful for debugging, especially when a bad tool call or prompt change happens midway through a run.

finally something that lets me actually see why my agent broke instead of digging through logs. the replay view caught a tool call loop in seconds, super useful.