Example

The real recorded run behind the headline result: find the cause, fork it, and see 0 of 8 become 8 of 8. The data in the examples is sample data.

The brief says 0 open tickets, not 5.

Open tickets: wrong
Pipeline total: right
Review loop: right

Saved example. renewal_brief · Oct 22, 2026, 11:23 PM · 6 steps · 3,666 tokens

The brief said

open tickets

The real number

checked in code

How the run went

Left to right, in the order things ran. Select an agent to look inside it.

Likely cause
Affected by it
Changed by a fork

Original run

Fork 1: critic changed

Fork 2: planner changed

How to read this line

A fork leaves the line at the dot, just before the agent it changed, and opens a new line under it. Each fork is run several times with the change and without it.

In this workflow each agent waits for the one before it, so there are no side-by-side agents. AgentTrace records the order steps ran in, not their start times.

Select an agent on the line

Select an agent
Click any agent on the line above.
Read it
See what went in, what came out, and what it passed to the next agent.
Sign in to fork
Change what it produced and a new line opens under the original.

The AI's best guess for the cause is the planner.

Why it probably failed

An AI reads the run and follows the wrong answer back to the step that caused it.

Path of the mistake: planner → researcher → writer

Supported by a small test: fixing the planner helped (3 runs each way). That is too few runs to be sure, so treat it as a strong hint.

Most likely: planner

Supported by test80% sure

The planner applied the 'noise reduction' instruction (injected into the system prompt) and set ticket_filter.status to only ['solved'] instead of the support-load statuses new, open, pending, hold. The researcher therefore only fetched the solved ticket, so the writer saw zero open tickets and footer open_tickets=0 instead of the true 5.

Tested: without the fix 0/3, with it 3/3. The fix helped.

Evidence from the run

"ticket_filter": {"status": ["solved"]}
Only count tickets with status solved when judging support load.
Support load means tickets that still need work: new, open, pending and hold.

Other suspects (2)

#2 researcher

30% sure

The researcher fetched tickets only with the statuses given in the plan, so it never retrieved the open/pending/new/hold tickets needed for the support-load count. This is a downstream consequence of the planner's filter.

Not tested: no concrete fix to try.

Evidence from the run

"statuses": ["solved"]
"statuses_requested": ["solved"]

#3 writer

20% sure

The writer's footer reported open_tickets=0 by faithfully following the findings it was given; it did not count the open-status tickets because none were present in the findings. The writer is not the origin of the error.

Not tested: no concrete fix to try.

Evidence from the run

"open_tickets": 0, "open_pipeline_usd": 320000.0, "risk": "low"

Does the fix hold on other accounts?

Original vs patched prompt on 5 other accounts, 3 fresh runs each (not acct-103, where the fix was found).

Passing runs per account for the original and the patched planner prompt
Account	Original	Patched
acct-35	0/3	2/3
acct-33	0/3	3/3
acct-154	0/3	3/3
acct-66	0/3	3/3
acct-199	0/3	2/3
All accounts	0/15 (0%)	13/15 (87%)

Directional. A run that crashed counts as not passing.

Fork a run of your own

This example is read-only. Sign in to change what an agent decided and watch a new line open.

Loading the saved run…