"An Agent Cannot See Its Own Bugs" - things I notice running multi-agent daily
Most multi-agent content in 2026 falls into two buckets. People questioning whether it's actually useful. People showing it off as novelty — framework launches, orchestration-graph screenshots, agents-talking-to-agents demos that were probably never run twice.
Very little of it comes from people who depend on these setups daily.
I do. Here's what I notice that doesn't show up in the demo posts.
An Agent Cannot See Its Own Bugs
Same model. Same context. Ask the agent to review its own diff. It mostly confirms.
Spawn a fresh agent. Clean context. Drop in the same diff. The bug pops out immediately.
The new agent isn't smarter. The original one spent twenty turns generating reasoning that pointed toward its current solution. Every token it produced was conditioned on the assumption that the approach was right. Asking it to contradict itself now runs against the grain of its own prior output.
This is also why pair programming works on humans. The second person isn't smarter. They walk in cold.
The fix isn't a more capable reviewer. The fix is an uncommitted one.
I stopped trusting single-agent self-review fast.
Adjacent example — same dynamic on design review, not just code.Last week I asked an agent to design a budget reset feature. It came back with a clean recommendation: lazy reset, UTC-aligned, no history retention. Confident, well-structured, "want me to implement any of these?"
Fresh context. Same model. I pasted the recommendation back and asked for a critical review from Claude Project.
The catches were substantive. UTC midnight is 8am Monday in Shenzhen — that's not what "weekly budget" means to a user shipping from there. No history retention breaks audit, which is the entire point of budget oversight. A stale period_start edge case the original pass had silently glossed over.Same model. Different context. Different output. That's the whole point.
A 1M Context Window Doesn't Parallelize IO
A bigger context window lets an agent hold more. It does not let it do more in parallel.
Take deep research. Task: browse 200 web pages and synthesize. Wall clock is dominated by sequential web fetch tool call, not reasoning. Stuffing all 200 pages into one agent's context doesn't make the fetches faster. It just lets one agent serially process them after they all arrive.
Every serious deep-research system uses sub-agent fan-out. Not because the orchestration is fashionable. Because the bottleneck is IO.
"Just use one big window" silently assumes the bottleneck is thinking.
For most of what I actually run, the bottleneck is waiting.
Long Specs Drift, Including on Frontier Models
With longer task spec, the agent is more prone to have implementation drift.
The agent is not able to group task spec, reasoning and implementation closely in its context window. The context itself will be contaminated by different details within the same task spec.
I noticed this very long ago and set ground rule for task spec writing.:"larger task -> sloppy implementation -> bugs-> fix tasks -> more bugs".
This works out perfectly, and having smaller task spec didn't even affect my efficiency - Large features are broken down into a number of smaller task spec and I just asked Claude Code to dispatch sub agents to implement each one of them and aggregate at the end. Worked every time.
The gap shrinks as models improve. I can feel that I am now writing longer and longer task spec and achieved the same outcome with better model. But shrinks is not vanishes. Splitting the spec is still a meaningful win on the workloads I actually care about.
So Is Multi-Agent Actually Useful?
The question has the wrong shape.
Multi-agent is a power-user thing. Boring literal sense: you have to run the same shaped task enough times for the setup to amortize.
One question and you close the tab? Overhead.
Same pattern hundreds of times — research pipelines, long-flow dev work, content workflows? Setup pays back fast.
The question I actually ask: does this workload repeat often enough for setup to pay back?
Usually no. Sometimes very yes.