Why an agent trace needs more than an error log
How Trace Autopsy finds repeated calls in a recorded run.
In the retry-storm example, an agent makes eight identical health-check calls to an unavailable service.
The final event reports that the retry limit was exceeded. To see how the run reached that point, you need the earlier calls.
I built Trace Autopsy to find structural failure patterns in traces and connect each finding to its evidence. This article describes the documented retry-storm example.
One failed call becomes eight identical attempts
The agent first plans to check the payment service. It then calls health_check with the service name and a timeout.
The call returns Service unavailable: Connection refused. The agent repeats the request with unchanged arguments until the retry policy stops the run.
The outage is the initial error. Repeating an unchanged request without a new decision is the behavior the analyzer needs to identify.
Parsers give the detectors one event format
Trace Autopsy reads generic JSON, LangGraph, LangChain, and OpenTelemetry traces. Each parser maps its input into shared Trace and TraceEvent models.
Normalization retains event order, assigns event identifiers, and updates parent references. Events stay in their original sequence, even when their timestamps appear out of order.
Detectors then check the shared events for repeated calls, cascading errors, empty outputs, and other failure patterns. They do not need a language model.
Findings point to the events that support them
Three identical tool signatures meet the loop threshold in this example. The analyzer runs afterward, so the finding includes all eight repeated calls.
| Evidence | Finding |
|---|---|
| Events 1 through 8 repeat the same call |
infinite_loop
|
| The failed calls return no value |
empty_response
|
| Errors continue through event 9 |
error_cascade
|
The retry-storm detector does not add a duplicate finding because the loop detector already covers those events.
The report ranks a missing exit condition as the leading explanation. Its suggested fix includes an iteration guard and an error boundary.
The reported confidence values are fixed ranking values, not calibrated probabilities. They order possible explanations rather than establish that an explanation is correct.
Model-generated explanation remains optional
The deterministic checks run first. An optional model can then query events and expand the explanation, with checks on its citations and structured output.
The deterministic report remains available when credentials are absent or a model call fails. The command-line interface, Streamlit interface, and Model Context Protocol server share the analysis code.
View the application screenshot ↗ · Read the Trace Autopsy source ↗
What the evaluation covers
The documented evaluation uses scripted traces and the project's own expected-pattern manifest. Agreement with that manifest verifies known cases, not accuracy across unseen failures.
Legitimate polling can resemble a loop. Unknown-tool checks also depend on a complete list of allowed tools.
A run can look structurally correct and still produce a wrong answer. Event patterns alone cannot establish whether the answer satisfies the task.
Trace Autopsy diagnoses runs after they finish. Preventing the next repeated call would require checks in the live execution path.
Read next: Starting ELTE's Data Science Club →