For a long time, my agent-debugging process was a man scrolling. Something would go wrong in production — a tool called twice, an output that made no sense, a run that just... stopped — and I'd open the logs and start scrolling, hunting for 'the weird part' like a raccoon going through a trash can. Sometimes I found it. Often I found a weird part, fixed that, and the actual bug stayed because it was a different weird part four thousand lines down. I was debugging by vibes, and vibes do not scale past about three failures.
The breaking point was a flaky multi-step agent that failed maybe one run in fifteen, always differently. There was no single reproducible bug. There was a CLOUD of small failures with, I suspected, a couple of shared root causes — but proving that meant holding four thousand log lines in my head at once, which I cannot do, because I am a person and not Gemini.
Why I hand the logs to Gemini 2.5 Pro specifically
This is the rare task where the model choice is the whole point. Gemini 2.5 Pro has a genuinely enormous context window and is excellent at synthesizing across one big messy input — exactly the shape of a debugging session. I can paste an entire run's worth of logs, all of it, without chopping it into pieces and losing the cross-references between a tool call at line 200 and the error it caused at line 3,800. A model that can only see the top of the log will just confirm my existing bias about the top of the log.
So I built the Turn Raw Agent Run Logs into a Failure Report and Eval Set prompt to lean entirely on that strength. I paste the raw logs, a one-line description of what the agent is supposed to do, and any symptoms I've already noticed. The prompt does the rest, and the rest is the part I'm bad at.
What comes back
- A Failure Summary table grouped by ROOT CAUSE, not symptom — so the 'tool called twice' and the 'stale data returned' failures collapsed into one row: a missing idempotency check, which I'd never have connected by scrolling
- Each root cause came with the actual quoted log line as evidence, so I wasn't trusting a vibe — I was looking at the receipt
- A Regression Eval Set of about ten concrete test cases — input, expected behavior, what it catches — which meant I could verify my fix instead of deploying and praying
- A Quick Wins list ranking the three fixes that killed the most failures for the least work, which is the prioritization I always get wrong on my own
The eval set is the real prize
The failure report is nice. The eval set is what changed how I work. Before, I'd fix a bug and have no way to know it was actually fixed — I'd just stop seeing it for a while and hope. Now every debugging session ENDS with a set of test cases that I add to a growing regression suite. The bug that bit me last month has a test now. It cannot come back without setting off an alarm. My agent has slowly gotten more reliable not because I got smarter but because I stopped throwing away the evidence from each failure.
The honest caveat: if your logs are too thin — you're not logging tool inputs, say — the report will tell you it can't find a pattern and list what to start logging instead. That's a feature. It caught that I wasn't recording tool arguments, which was why half my failures were invisible. I fixed the logging, re-ran, and got a real report. The prompt is good, but it can only synthesize what you actually captured; garbage-thin logs in, 'log more things' out.
Group by cause, not symptom — this is the whole trick
The single instruction in this prompt that changed my debugging life is 'group by root cause, not symptom.' My instinct, and probably yours, is to list failures by how they looked: 'output was malformed,' 'tool timed out,' 'agent looped.' But three different-looking symptoms often share one cause, and if you fix them as three separate bugs you'll fix two and miss the one that mattered, or you'll fix the same thing three times. When the report collapsed my 'tool called twice' and my 'stale data returned' into a single row — missing idempotency check — it didn't just save time. It told me a true thing about my system I'd been failing to see because the symptoms were wearing different costumes.
I've since made this a ritual. Every Friday, I export the week's failed runs, paste them in, and read the report over coffee. It takes fifteen minutes and it's the highest-leverage fifteen minutes of my week, because it turns a vague sense of 'the agent's been flaky lately' into a ranked, evidenced list of exactly what to fix and a set of tests to confirm I fixed it. Flakiness stops being a feeling and becomes a backlog.
Stop scrolling. Grab the Turn Raw Agent Run Logs into a Failure Report and Eval Set prompt on Prompt Dock, paste your messiest run into it on Gemini 2.5 Pro, and let it find the shared root causes you can't hold in your head. I pair it with my Build a Chain-of-Steps Workflow for a Multi-Step Agent Task prompt — the eval set tells me what's breaking, and the workflow design tells me how to add the failure handling that stops it from breaking again.