The agent finishes a long task. The result is clearly wrong — a number that doesn't match, a format that's off, something that should be there and isn't. But there's no error line. Nothing turns red to point at the spot. You scroll to the top and start rereading the six hundred lines it just produced, line one, line two… and by line two hundred you still haven't seen anything wrong. Each step, read in isolation, looks right.
That's because you're looking in the wrong place. The break isn't where it shows up. It's where it began — and those two places are usually far apart.
01The error flows downstream, so reading downstream just chases its shadow
Picture the agent's work as a flowing river. A skewed assumption upstream — it misreads a word in the request, pulls the wrong column of data, guesses the wrong format — doesn't throw an error right there. That skew flows down: every step after it works hard and correctly, just on a premise that's already wrong. By the final output the skew has accumulated enough for you to see it. But by then it's traveled a long way from where it was born.
That's why reading straight from the top is a time trap. You're scanning a long run of correct steps — correct relative to their wrong premise — and they look right, because they are. You're swimming downstream to go upstream. Each line you read costs effort and eliminates almost nothing, because the error doesn't surface in any single step; it hides in the contract between steps.
✕ Read it all, top to bottom
✓ Halve the suspect zone
The difference isn't diligence — it's linear versus halving. Reading six hundred lines costs you six hundred; repeated halving reaches the bottom in about ten questions. Same bug, very different bill.
02Bisect: halve, ask to confirm, drop a half, repeat
The technique is borrowed straight from finding a word in a dictionary: you don't flip page by page, you open to the middle and decide front half or back half. Applied to tracing an agent's failure, it becomes three repeating beats:
Beat 2 — Ask one confirming question: "At this step, what is the value of X?" or "Show me the input you used for that step." A checkable fact, not a self-report.
Beat 3 — Drop a half, then repeat: if the midpoint is still right, the break is in the back half; if already wrong, it's in the front half. Halve the remaining side.
The power is in beat two: the question must demand a checkable fact, not a self-assessment. "Was that step okay?" and the agent performs an answer for you — ask "what is the specific value" and it has to surface the real thing.
The four suspect zones in beat one are a handy frame for splitting: most errors sit where the agent misunderstood what you wanted, or took the wrong input — two sources that tend to be upstream and get skipped the most, because we default to "surely it understood me" and dive into the logic. Halving forces you to check that default, early, instead of leaving it a blind spot.
03Finding the real break beats patching the right symptom
There's a second win, deeper than speed. When people read downstream and tire out, they surrender a different way: they see the wrong output and patch it right at the output — force the number back, nudge the format to match. The upstream skew is still fully there; you've taped over where the blood comes out, not where the wound is. Next time the input differs slightly, it bleeds out a different way, and you patch from scratch again.
Bisect isn't just fast — it leads you to the real break, the place worth fixing. Fix it there and the whole river below clears on its own, once. That's the difference between mopping up consequences and treating the cause.
So next time the output is wrong with nothing pointing at the spot, don't scroll to the top and read. Ask one question at the middle. Even the quietest error leaves a trace at the exact step that birthed it — you just have to halve the path enough times to corner it.