Session replay is not evidence for an agent

Session replay solved a real problem and solved it well. Before it existed, the argument about a bug report was unwinnable. The reporter said they clicked save. The engineer could not reproduce it. Both were sincere and neither could prove anything. Replay ended that argument by showing the engineer the thing itself.

That category is mature now. The tools handle scale, they mask sensitive fields, several are open source, and the good ones are genuinely pleasant to use. Nothing below is an argument that they are bad at their job.

It is an argument that the job changed underneath them.

The first reader is no longer a person

When a person is the reader, video is close to ideal. Somebody watching thirty seconds of a recording takes in the cursor hesitating, the layout shifting, the field that cleared itself, and the small pause of a user deciding to give up. They do all of that without being told what to look for, which is a capability no schema has.

More and more, the first reader is not a person. It is a coding agent, handed a bug and asked what changed. And the agent cannot watch. That is not a limitation anyone is about to engineer away with a better player.

The honest version of the claim is narrow. A model can be given frames from a recording and describe what is in them. What it cannot do is get from a picture of a spinner to the status code of the request behind it, the query that request ran, and the row that query wrote. Those facts are not in the pixels. They were never supposed to be.

What a model needs instead

Different reader, different artifact. The properties that make evidence useful to a model are specific, and only one of them overlaps with what makes a recording useful to a person.

• Structured. Typed events with a stable schema, not a rendering of them. A model reasons about a status code, a duration, and a changed row, and each of those has to be a field it can address.

• Correlated. One identifier carried from the click through the request, the backend span, and the row change. Without it the model receives four unrelated facts and no way to decide whether they describe the same failure.

• Redacted before it moves. A bundle assembled for a model is usually a bundle that leaves the machine. Masking has to be the default state rather than a setting somebody remembered to switch on.

• Bounded. A model has a context budget. Evidence delivered as an undifferentiated stream spends that budget on scroll positions. A ranked summary first, raw events only when asked for, and a stated cap when they are.

• Machine readable end to end. Plain files with a documented shape, so retrieval is a query rather than a screenshot of a query.

Two jobs, not two grades of one job

It is tempting to frame replay as a weaker version of an evidence bundle. That framing is wrong in both directions.

A person triaging a confusing report still wants to watch. There is information in the shape of somebody's hesitation that no field captures, and if your workflow is a support engineer trying to work out whether to believe a customer, a recording is the better tool and it is not close.

A model resolving the same bug wants the opposite. Fewer impressions, more fields. It wants to know that one request returned a 500 after nine seconds, that the query behind it wrote a row with a null where the code assumed a value, and that a deploy forty minutes earlier touched that code path. None of those get clearer by being shown.

Plenty of teams want both, and that is a reasonable thing to want. They are two consumers of the same underlying event stream, asking it for different shapes.

Where Crumbtrail sits

Crumbtrail records the stream and finalizes it into the shape the model reader needs: plain files, a redacted evidence index, a correlation key stamped while the failure happens rather than inferred later, and read only MCP tools that hand an agent a ranked summary long before it asks for a raw event.

There is a dashboard, and a person can read the same evidence in it whenever they want to. The pipeline is built to work without anyone opening it, which is a different statement from saying nobody should.

How to tell which one you need

The test is who acts on the answer. If the output of an investigation is a person forming a judgment, optimize for watching. If the output is a model proposing a change to your code, optimize for something it can parse, because the alternative is a model answering from ticket text and sounding certain while it does.

You can settle this in an afternoon on a bug you already understand. The packages are MIT licensed on npm and the trial needs no card.

npx crumbtrail

Record the session, hand the bundle to the same model that got the ticket wrong, and read the two answers side by side. If the answer does not improve, that result is more useful to us than a signup.