So far, you've delegated isolated tasks. Now imagine a truly large request: "gather everything available about topic X, confirm what's actually true, and give me a complete report". A single subagent can't handle it — and worse, if it stop too early or believe the first result, you get a polished but wrong answer. Scaled architecture addresses this with three linked stages: a fleet that searches until it runs dry (find), a a court that refutes each finding (verify) is one synthesizer that brings together only what survived (synthesize). Remember this pipeline — it's the backbone of the entire module.
↑ The harness skeleton: find in a loop → verify adversarial by majority → synthesize only the survivors.
Detailed content
🚢 The fleet: from one subagent to many
A fleet is a group of subagents of the same type working on the same problem at the same time—not one, not two, but ten, forty, a hundred, each on a slice. The conductor stops "delegating a task" and starts run an operation: split up the search space, dispatch the fleet, gather the pieces, and move on to the next stage. The unit of reasoning stops being the subagent and becomes the entire system.
⚓ The exploration fleet analogy
Think of an ocean to map. A single ship takes months and still misses entire regions. A fleet divides the sea into sectors, sends a ship to each one, and the admiral (the conductor) consolidates the charts. No ship talks to another — they all report to the admiral. If a region is unclear, it sends more ships there. Scale isn't the size of the ship; it's quantity and coordination.
- •Admiral = the orchestrator/harness, which splits up, dispatches, and consolidates.
- •Ships = the fleet of subagents, each in a different area of the problem.
- •Cards = the partial reports that come back to be combined.
a pattern in which many subagents with the same role tackle slices of the same problem in parallel, coordinated by a single orchestrator.
broad-coverage problems (scanning a huge repository, surveying literature, auditing hundreds of files) only become manageable when you think in terms of a fleet, not "one hard-working agent."
partitioning · large-scale parallelism · orchestrator as hub · the system as the unit of reasoning.
🔁 Loop-until-dry: repeat until dry
The biggest mistake in a large-scale search is stop too early. A subagent finds five things, thinks "that's enough," and returns — but there were fifteen. The fix is the loop-until-dry: run the fleet in rounds, and only stop when K consecutive rounds come back empty (nothing new). “Dry” doesn’t mean “a round without news”; it means K rounds nothing new—a buffer against stopping at the first breath.
Run: dispatches the fleet
Each subagent searches its own slice.
The round produces a batch of new findings. Anything that appeared before is deduplicated against the accumulated findings.
Measure the round’s “gain”
Number of findings new did they enter?
If a new finding comes in, the empty-round counter goes back to zero and opens a new round. The search is still “wet.”
Empty run → counts toward K
Nothing new this round.
Increments the counter. Only when it reaches K (e.g., 2 or 3 empty results in a row), the search is declared dry and the stage ends.
💡 Why K and not 1
An empty round may be bad luck (the fleet looked in the wrong corners that time). Require K empty rounds in a row avoids declaring victory too early. In exchange, define a round cap (e.g., maximum 8) so the loop doesn't run forever in a pathological case.
⚖️ Adversarial verification: N skeptics refute
Finding is not confirmation. Each finding from the fleet goes into a court: you launch N skeptical subagents, and each one’s task no is to agree—it’s try to take down the claim ("find evidence that this is wrong"). If the majority be able to refute, the finding dies. Only what withstands the attack survives. It’s the opposite of asking for confirmation—asking for confirmation only reinforces the bias.
✓ Adversarial verification (do this)
- ✓Instruct the skeptic to look for the error, not to confirm
- ✓Use N independent skeptics and decide by majority
- ✓Require each rebuttal to point to evidence, not opinion
- ✓Let only what survived to attack
✗ Naive verification (avoid)
- ✗Ask "is this right?" (encourages agreement)
- ✗A single verifier (becomes a single point of bias)
- ✗The same agent that found it is the one who validates it
- ✗Accepting everything that “seems plausible”
🔭 Diverse perspectives: different lenses
A fleet of subagents identical make the same mistakes in unison—everyone looks in the same place and misses the same blind spot. The fix is to give each subagent a different lens: the same material, different roles. One looks for contradictions, another looks for what’s missing, another reads from a cost perspective, and another from a security perspective. Diversity of perspective = diversity of errors found. It’s the same idea as the 5 personas from Track 1, now as an architecture component.
Contradiction lens
"Where do two findings contradict each other? Which one has to be wrong?"
Gap lens
"What should be there but didn’t show up? What question did no one ask?"
Cost lens
"How much does this cost in practice? What changes when the budget gets tight?"
Risk lens
"Where does this break? What’s the worst case? What would an adversary exploit?"
Scale lens
"Does it work with 10? And with 10 million? Where does this approach stop working?"
Sum of the perspectives
Each lens finds a flaw the others miss. Together, they cover what a uniform fleet would overlook.
📊 Diversity > quantity
Ten subagents with the same lenses find, in practice, almost what one would find — just faster. Five with lenses different find things that none of the ten would. When scaling up, vary the perspective before increasing the number.
🧮 Completeness critic: what’s still missing?
Loop-until-dry tells you when the fleet stopped finding. But "stopped finding things" doesn't mean "found everything that matters" — an entire gap may have remained unexplored. Enter the completeness critic: a subagent whose only mission is to look at the assembled whole and ask "what's still missing?". It doesn’t search; it points out the gaps. Every gap it points out becomes a new round of targeted searching — closing the loop between checking and searching again.
# Pergunta única do crítico: "o que ainda falta?"
COBERTO ✓ definição do conceito
COBERTO ✓ 3 casos de uso confirmados
COBERTO ✓ limites conhecidos
LACUNA ✗ nenhuma fonte sobre custo em produção
LACUNA ✗ nada sobre o que muda fora do Claude Code
LACUNA ✗ zero contra-exemplos (só casos de sucesso)
# → o harness abre 3 buscas direcionadas para
# fechar exatamente estas lacunas e roda de novo.
💡 Searching is different from critiquing
People searching tend to stop once they’re satisfied with what they found. That’s why the completeness critic is a separate subagent, with fresh context — it arrives without the searcher's attachment to "I've found enough" and sees the gap the searcher normalizes. It's the same principle as an impartial reviewer, applied to coverage.
📋 No silent cap: log what was truncated
Every system at scale has limits — on tokens, time, and number of items. The problem isn’t setting limits; it’s cut silently. If the fleet finds 500 items and the system processes only 50 without warning you, you get a report that seems complete and isn't — and you'll never know. The golden rule: no silent cuts. Cut? Log it: what was cut, how much, and by what criterion. The user needs to see the edge of the map.
✓ Honest cut
- ✓"I processed 50 of 500 findings (top by relevance)"
- ✓Records the criterion from the cut (relevance, date, scope)
- ✓Saves what’s left for a future run
- ✓Let the user decide if you want to go beyond the ceiling
✗ Silent cap
- ✗Truncates at 50 and doesn't notify that there was more
- ✗The report looks complete, but it’s only a slice
- ✗Discards the other 450 without a trace
- ✗Coverage decision made by you without you
⚠️ The most dangerous scaling mistake
It’s the only mistake on this list that gives no indication. You notice a shallow search; the tribunal catches a false finding; but a silent cap delivers a report plausible and incomplete that no one questions. That's why the rule is strict: if it was cut, it should appear in the log — always, even when the cutoff seems obvious.
🧬 Synthesize: the report that closes the pipeline
In the end, someone has to put everything together — but combining isn't pasting together. The synthesizer receives only the findings that survived to the tribunal, after the gaps are closed, with the cut log in hand, and produces a coherent narrative: deduplicates, groups by topic, resolves remaining conflicts, cites the source of each claim, and states what was left out. The final report is the only thing that comes back to you—clean, as the subagent model requires.
# Síntese: <pergunta original>
## Conclusões (sobreviveram ao tribunal)
- <afirmação A> [fonte: f1, f7 · 4/4 céticos mantiveram]
- <afirmação B> [fonte: f3 · 3/4 mantiveram]
## Conflitos resolvidos
- A vs. C → C caiu (refutado por evidência em f9)
## O que ficou de fora (sem cap silencioso)
- 500 achados → 38 processados (top por relevância)
- lacuna ainda aberta: custo em produção (0 fontes)
## Confiança
- alta nos itens 4/4; média nos 3/4; baixa onde há 1 fonte
📊 Synthesis carries the trail
A good report doesn’t hide the process: each conclusion includes how many skeptics kept it e of where it came from, and there’s an honest “what was left out” section. That’s what turns a pile of findings into a document you can trust—and audit.
Example: the skeleton of a harness
One harness is the code (or skill) that orchestrates the fleet—the “admiral” implemented as a program. You don’t need to write this in any specific language right now; what matters is recognize the form. Below is the pseudocode skeleton: the seven topics in this module appear as steps in a function. Read it like a recipe, not as ready-to-run code.
função pesquisar_em_escala(pergunta, K=2, max_rodadas=8, N_ceticos=4):
achados = conjunto() # dedup automático
rodadas_vazias = 0
log_cortes = []
# ── 1+2 · FIND em loop-until-dry ──────────────────────
enquanto rodadas_vazias < K e rodada < max_rodadas:
fatias = particionar(pergunta, achados) # tópico 1: frota
novos = frota_paralela(BUSCADOR, fatias) # cada um, uma lente (tópico 4)
ineditos = novos - achados
se ineditos vazio: rodadas_vazias += 1
senão: rodadas_vazias = 0; achados |= ineditos
# ── 3 · VERIFY adversarial (mata por maioria) ─────────
para cada a em achados:
votos = frota_paralela(CETICO, repetir(a, N_ceticos)) # "ache o erro"
se maioria(votos) == "refuta": achados.remove(a)
# ── 5 · COMPLETENESS critic → realimenta o find ───────
lacunas = subagente(CRITICO_COMPLETUDE, achados) # "o que falta?"
se lacunas: retornar pesquisar_em_escala(focar(pergunta, lacunas), K, ...)
# ── 6 · SEM CAP SILENCIOSO ────────────────────────────
se tamanho(achados) > TETO:
log_cortes.append(f"processados {{TETO}} de {{tamanho(achados)}} (top relevância)")
achados = top(achados, TETO)
# ── 7 · SYNTHESIZE (única saída p/ o maestro) ─────────
retornar subagente(SINTETIZADOR, achados, log_cortes) # relatório citado
🧠 What the harness guarantees
- Depth — the loop only exits when it runs dry (K empty).
- Reliability — every finding goes before the tribunal.
- Completeness — the critic feeds the gaps back into the find.
- Honesty — every cutoff becomes a log entry.
⚙️ The parameters you adjust
- K — how many empty rounds before declaring it dry.
- max_rounds — a limit to keep the loop from running forever.
- N_céticos — how many refute each finding.
- CEILING — explicit limit, always logged when reached.
Ready-made prompts (copy and paste)
Three prompts to enforce this module's doctrine across a fleet—even without writing a harness. Notice the pattern: ask exhaustion, ask for refutation and prohibit the silent cut.
Dispare uma frota de subagentes para levantar TUDO sobre
<tema>. Rode em rodadas e só pare quando 2 rodadas
seguidas não trouxerem nada novo. No fim, diga quantas
rodadas rodou e por que considerou a busca esgotada.
Para cada achado, abra 4 subagentes céticos cuja missão
é TENTAR REFUTÁ-LO com evidência (não confirmar). Se a
maioria refutar, descarte o achado. Me entregue só os
que sobreviveram, com a contagem de votos de cada um.
Antes de fechar, rode um crítico que liste o que ainda
falta e abra buscas para as lacunas. Depois sintetize um
relatório citado. Se você cortar QUALQUER coisa por
limite, registre o que cortou, quanto e por qual critério.
Simulated screen: the harness running a fleet
This is how the operation appears in the terminal: the harness is in the find round 3, with a fleet of searchers and skeptics in parallel. Notice the empty-round counter (1/2 — it still hasn't dried), skeptics knocking down findings, and at the base, the cutoff log line — visible, never silent.
↑ Illustrative recreation of the terminal (not a real screenshot). The fleet burns through context in its own windows; yours barely moves — and the 214→50 cut is visible in the log.
Exercise: design a loop-until-dry
Choose a real problem with broad coverage (e.g., "find every place in my code that touches payments" or "gather everything I know about competitor X") e sketch the harness on paper that would solve it using this module's doctrine. You don't need to run anything — the deliverable is the loop design and its rules.
How to do it
- Define how to partition the problem between the fleet (by folder? by source? by subtopic?).
- Choose the K (how many empty rounds before it runs dry) and a round cap.
- Write the rule for adversarial verification: how many skeptics, and how the majority decides.
- Define the completeness critic: what question it asks and what becomes a new search.
- Say where the cutoff cap and exactly what you’ll log when to cut.
✅ Verification criteria — how to know you got it right
Your design is correct if a reader can answer these five questions just by looking at it:
- →When to stop? The stop condition is "K empty rounds," not "one round" or "ran out of time."
- →How do you trust it? There is majority-based rebuttal, not “asking if it’s right.”
- →How do you know it’s complete? There is a gap critic that feeds back into the search.
- →What was cut? There’s an explicit logging point—no cuts are silent.
- →What comes back? A cited synthesis, not the raw pile of findings.
If any of the five are missing, the design is not yet an architecture at scale—it’s just “several loose subagents.”
Solved example (condensed)
Problem: find everything in the repo that touches payments. Partition: one slice per top-level directory. K=2, limit of 6 rounds. Verify: 3 skeptics per finding; if the majority refutes it → discard. Critical: "what payment flow doesn't appear in any finding?" → becomes a targeted search. Cut: cap at 80 snippets; if it exceeds that, log "processed 80 of N". Output: list cited by file + "not covered" section.
✅ Module summary
Next module:
4.2 — Subagents in Codex and other environments. The same concept outside Claude Code: equivalents, cross-runtime use, and what changes.