Tickets are claims. Sessions are evidence.

Ask an engineer why a bug report was hard and you rarely hear that the code was difficult. You hear that the report was wrong. The reporter left out the step everyone on the team just knows. They said it used to work when it never did. They described the symptom they noticed rather than the one that mattered.

None of that is dishonesty. It is what happens when a person reconstructs an event from memory, minutes or hours after it happened, in a text box. The ticket is a claim about a failure. It is not the failure.

Humans handle this by discounting the ticket. A senior engineer reads a report and silently assigns it a confidence level, then goes looking for the real thing. Coding agents do not do this. Give a model a ticket and it treats every sentence as fact, because a ticket is the only input it has.

What a model does with a claim

The failure mode is specific and worth naming. An agent handed only ticket text will produce a fix that is plausible for the story it was told. It cannot produce a fix that is correct for the failure, because it never saw the failure. The output looks like competent work. It reads well, it cites the right files, and it addresses exactly the thing the reporter described.

That is what makes it expensive. A wrong answer that looks wrong gets thrown away in seconds. A wrong answer that looks right gets reviewed, merged, and discovered later by the next person who hits the actual bug.

It just kind of guesses based on the ticket.

A support engineering manager, describing the internal triage bot their team built

We heard that sentence in a buyer discovery call in July 2026, from someone whose organization had already built the thing everyone builds first: a workflow that reads new tickets and asks a model what to do. It worked well enough to keep and badly enough to distrust. The diagnosis was not that the model was weak. It was that the model was reasoning from a claim.

The evidence exists. It is just not joined.

Here is what makes this frustrating rather than merely hard. In most teams the evidence that would settle the question already exists. The user's clicks were in a session tool. The failed request was in an error tracker. The slow query was in a logging tool. The bad row was in the database. The change that caused it was in a commit.

Five systems hold five pieces of one event, and they share no key. No column joins the click to the request to the row to the commit. A person can join them by hand in twenty minutes of tab switching and informed guessing. An agent cannot join them at all, so it does the only thing available and answers from the ticket text.

Joins have to be stamped while it happens

A join key cannot be added later. Once the request has been served and the log line has been written, nothing in either record says which click caused it. You can guess with timestamps and user identifiers, and the guess will be right often enough to be dangerous.

The only reliable moment to establish the link is while the failure is happening. If the click, the request, the backend span, the log line, and the row change all carry the same identifier at the moment they occur, then the join exists before anyone knows they will need it. That is a capture decision, not an analysis decision, and it has to be made before the ticket is filed.

Crumbtrail is built on that ordering. Capture runs first. The correlation key is stamped as the failure occurs. When a ticket shows up later and says checkout failed, the evidence that explains it is already one object rather than five.

What changes when the agent has evidence

Three things get easier, and they are worth separating because teams tend to want them in a different order than they expect.

1. Claims become checkable. Each statement in the ticket can be compared against what was recorded and marked confirmed, contradicted, or simply not covered. The reporter who said they clicked save either did or did not.

2. Reproduction stops being archaeology. The steps the reporter did not write down are in the recording, in order, including the two they did not think mattered.

3. A code change stops being the default answer. Plenty of tickets are not code defects at all. They are bad data, a config value that drifted, an infrastructure fault, or a deliberate change nobody told support about. An agent reasoning from ticket text alone tends to reach for a patch, because a patch is what it knows how to write, and evidence is what makes the other possibilities visible enough to consider.

That third one is the quiet cost of guessing. An agent that answers every ticket with a patch will write patches for things that were never broken in the code.

Try it against a claim you already have

The honest test is not a demo. It is one of your own tickets that an agent already got wrong. Record the session, assemble the evidence, hand the bundle to the same model, and read the two answers side by side.

The CLI and the SDKs are MIT licensed and published to npm, and the trial needs no card. One command sets it up.

npx crumbtrail

If the answer does not get better on your own bug, we would genuinely like to know. That result is more useful to us than a signup.