PTENES
MODULE 4.1 · Track 4 · Advanced & cross-environment

🛰️ Multiagent architecture at scale

Move from “one subagent” to a fleet isn't just about asking for more. It's about building a system that search until it runs dry, refute what it found, look at different lenses and never silently cuts anything — then synthesize an answer you can trust.

7
Topics
~35
Minutes
Advanced
Level
Architecture
Type

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.

1 · FIND 2 · VERIFY 3 · SYNTHESIZE searcher searcher searcher searcher … repeat until dry (K empty rounds) skeptic skeptic skeptic majority rejects → discard vote majority survivors Synthesizer final report, cited a completeness critic asks "what's still missing?" · everything that was cut goes in the log (no silent cap)

↑ The harness skeleton: find in a loop → verify adversarial by majority → synthesize only the survivors.

Detailed content

1

🚢 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.
What it is:

a pattern in which many subagents with the same role tackle slices of the same problem in parallel, coordinated by a single orchestrator.

Why learn:

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."

Key concepts:

partitioning · large-scale parallelism · orchestrator as hub · the system as the unit of reasoning.

🧭
Partition
divides the space
🚀
Dispatches
parallel fleet
📥
Collects
partial reports
🧩
Consolidates
a result
2

🔁 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.

1

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.

2

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.”

3

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.

What it is: an exhaustion-based stopping criterion: repeat the search until K consecutive rounds turn up nothing new.
Why learn: is the antidote to shallow coverage—the system only stops when it has proven there’s nothing left to find.
Key concepts: round · novel gain · empty counter · K threshold · safety ceiling.
3

⚖️ 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.

finding "X is true" skeptic 1 skeptic 2 skeptic 3 skeptic 4 refute ✗ refute ✗ refute ✗ keeps ✓ 3 out of 4 refute it → majority verdict: discard the finding

✓ 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”
What it is: a quality filter where several skeptics try to knock down each finding and the majority decides whether it dies.
Why learn: is what separates "a confident search" from "a reliable answer"—refuting is more honest than confirming.
Key concepts: burden of refutation · independence · majority vote · evidence over opinion.
4

🔭 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.

What it is: assigning different roles/perspectives to subagents that examine the same material.
Why learn: eliminates the collective blind spot of a homogeneous fleet—each perspective covers a failure in the others.
Key concepts: lens/persona · collective blind spot · diversity before quantity · complementary coverage.
5

🧮 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.

completeness-critic’s output gaps → new searches
# 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.

What it is: a dedicated evaluator that maps gaps in the assembled set instead of searching for more.
Why learn: "stopped finding" doesn't mean "it's complete"; the critic turns gaps into targeted searches.
Key concepts: coverage × exhaustion · gap as task · fresh context · feedback to find.
6

📋 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.

What it is: the discipline of making every truncation visible — recording what was cut, how much, and why.
Why learn: invisible cuts produce falsely complete answers; the log gives the user the coverage decision back.
Key concepts: explicit truncation · cutoff criteria · auditable trail · visible "edge of the map".
7

🧬 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.

relatorio-final.md (summarized form) only survivors + log
# 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.

What it is: the stage that merges the surviving findings into a cited report, with conflicts resolved and omissions stated.
Why learn: is the point where scale becomes delivery—without synthesis, you just have a pile of pieces.
Key concepts: deduplication + grouping · source citation · conflict resolution · confidence level · clean report.
📄

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.

harness.pseudo — fleet orchestration pseudocode (illustrative)
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.

Prompt 1 — search until you run dry loop-until-dry
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.
Prompt 2 — verify adversarially N skeptics, majority
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.
Prompt 3 — synthesize without silently cutting content completeness + log
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.

claude code · harness:pesquisa-em-escala · round 3 ⏱ 02:17
━━ FIND · search fleet ━━━━━━━━━━━━━━━━━━━━━━━
● searcher · docsHaiku
+12 new
● searcher · codeHaiku
+3 new
● searcher · webHaiku
+0 new
empty rounds: 1/2 · still not dry → start round 4
━━ VERIFY · adversarial tribunal ━━━━━━━━━━━━━━━━━━━
● 4 skeptics · finding #18Sonnet
3/4 refute ✗
● 4 skeptics · finding #22Sonnet
4/4 holds ✓
⚠ log: 214 findings → 50 processed (top by relevance) · 164 saved
orchestrator · Opus
your context
9%

↑ 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

  1. Define how to partition the problem between the fleet (by folder? by source? by subtopic?).
  2. Choose the K (how many empty rounds before it runs dry) and a round cap.
  3. Write the rule for adversarial verification: how many skeptics, and how the majority decides.
  4. Define the completeness critic: what question it asks and what becomes a new search.
  5. 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

✓
Fleet — many subagents with the same role working on slices of the problem; the system is the unit of reasoning.
✓
Loop-until-dry — repeats until K consecutive rounds come back empty; “dry,” not “one round.”
✓
Adversarial verification — N skeptics try to refute it; if the majority overturns it, the finding dies.
✓
Diverse perspectives — different lenses cover the blind spot of a uniform fleet.
✓
Completeness critic — asks “what’s missing?” and turns gaps into new searches.
✓
No silent cap — every cutoff gets logged: what, how much, and by what criterion.
✓
Synthesize — combines only the survivors into a cited report, with conflicts resolved and omissions declared.

Next module:

4.2 — Subagents in Codex and other environments. The same concept outside Claude Code: equivalents, cross-runtime use, and what changes.