Skip to content

PATTERN Cited by 1 source

Parallel narrow agents over exhaustive

Intent

When a task is find-something or audit-something over a large surface, achieve coverage by running many agents on narrow tasks in parallel — and deduplicating the aggregated results downstream — rather than asking a single agent to do an exhaustive job.

Canonical articulation

Cloudflare's verbatim formulation (Source: sources/2026-05-18-cloudflare-project-glasswing-what-mythos-showed-us):

"Coverage improves when many agents work on tightly scoped questions and we deduplicate the results afterward, rather than asking one agent to be exhaustive."

The pattern is the parallelism half of the architecture that the narrow-scoped agent task pattern's scope half makes feasible.

Why this pattern beats the exhaustive single agent

Three mechanisms compound, each disqualifying the single-exhaustive-agent shape:

  1. Single-agent coverage failure. "A single agent session (even with subagents) against a hundred-thousand-line repository can cover maybe a tenth of a percent of the surface in a useful way before the model's context window fills up and compaction kicks in." Coverage is bounded by per-session context window, not by model capability.
  2. Context rot. The longer a single agent session runs, the more context-window pressure degrades accuracy. Splitting work across fresh-context sessions keeps each session inside its accuracy sweet-spot.
  3. Throughput cap on serial work. "A single-stream agent does one thing at a time." Even if the model could handle each investigation correctly, serialising thousands of investigations behind one stream is structurally slow.

The single-exhaustive-agent shape stops scaling not on the model but on the shape of the interaction itself.

The architectural recipe

Component Job
Task generator (Recon stage in Cloudflare's harness) Produces a queue of narrow tasks, one per investigation. Bounded by attack-class × code-location combinatorics.
Worker pool (Hunt stage; ~50 concurrent agents at Cloudflare) Pulls tasks; each agent runs in its own fresh-context session with the narrow task as its prompt.
Per-task isolation Per-task scratch directory, per-task tool surface; agents can't interfere with each other.
Result aggregation Findings flow into a queue.
Dedup stage "Findings that share the same root cause collapse into a single record. Variant analysis is a feature, not a way to inflate the queue with duplicates."

Cloudflare's harness names the dedup step explicitly because parallel agents on overlapping scopes do find variants of the same underlying bug — the pattern is incomplete without a deduplicator.

What scales how

  • Coverage scales with task-queue size × agent pool size.
  • Per-finding latency is bounded by the slowest agent's task duration, not by total task count (when concurrency is sufficient).
  • Token cost scales with task count × per-task token cost — total cost is much higher than a single agent run, but per-finding cost can be lower because each agent runs in a small, focused context.
  • Coordination overhead is per-task, not per-agent — task generation, queueing, and dedup are O(tasks).

Sibling pattern instances on the wiki

  • patterns/agent-spawn-parallel-exploration — Vercel's Turborepo experiment: "8 background coding agents from my phone" on a single Rust performance question. Sibling at the "unattended-fan-out + survivor- selection" shape. Both depend on tolerance for high per-agent failure rate (fixed by parallelism, not by per-agent reliability).
  • patterns/coordinator-sub-reviewer-orchestration — Cloudflare AI Code Review's coordinator + ≤7 sub-reviewers. The shape is the same; the parallel agents are domain-specialised (security / perf / quality / etc.) rather than task-specialised (one attack-class + one-function). Both compose with this pattern at the fan-out boundary.
  • patterns/context-segregated-sub-agents — Fly.io's general formulation: "a new context array, another call to the model. Give each call different tools." This pattern is the parallel specialisation of segregated-sub-agents.

Trade-offs

Property Parallel narrow Single exhaustive
Coverage on large repos High (scales with concurrency) Bounded by single-session context
Per-finding context noise Low (fresh context per task) High (accumulates over session)
Token cost (absolute) Higher Lower
Token cost per real finding Lower (after filtering) Higher (single session burns tokens on navigation)
Coordination complexity Higher (queue, dedup, aggregation) None
Best for Find-something / audit-something / cover-something Single-hypothesis tasks (one bug, one feature)

When not to reach for this pattern

  • Single-hypothesis tasks — one bug to fix, one feature to build, one specific question. The fan-out / dedup overhead swamps the work.
  • Tasks where the value is cross-cutting reasoning — when an agent's value is connecting findings across the repo, splitting the work fragments the connection-making capability.
  • Tasks small enough to fit comfortably in a single session. Parallelism is for problems where coverage is bounded.

Numbers (Cloudflare)

  • "Typically around fifty" hunters concurrent.
  • Each hunter fans out to "a handful" of exploration subagents (intra-task fan-out, sub-second to seconds- scale).
  • "More than fifty" repos in scope per scan run.
  • Single-agent useful coverage on 100k-LoC repo: "maybe a tenth of a percent of the surface".

Seen in

Last updated · 542 distilled / 1,571 read