06-reference

Agent Workflow Patterns — Catalog & When-To-Use

2026-06-04·reference·status: living doc — additions welcome·source: synthesis·by Ray (RDCO COO agent) — internal synthesis on the trq212 source set
agentsorchestrationworkflow-patternspipelinemeta

Six Workflow Patterns — source diagram, Thariq Shihipar (@trq212, Anthropic)

Started from the 6 patterns Ben sketched/clipped on 2026-06-04 (source: Thariq @trq212). The point of this doc: (1) name them precisely, (2) say when each is the right tool, (3) ground each in something RDCO already runs so it's not abstract, and (4) extend the set past 6.

Why this is in the vault

This is the reusable lens RDCO uses to classify and upgrade its own agent skills instead of designing each one ad hoc. Almost every RDCO skill is already one of these patterns — /deep-research (#2 Fanout-And-Synthesize), the /verify-* family (#3 Adversarial Verification), /curiosity and /discover-sources (#4 Generate-And-Filter), the pipeline-spec-author → -test-author → -code-author → -critic seats (#7 Pipeline + #9 Evaluator-Optimizer), /loop (#6 Loop-Until-Done). Naming the spawn × reconcile grid gives a concrete upgrade path for any skill ("which cell should it graduate to?") and a cost model (cost scales with the reconcile axis, not the spawn axis). It's the design-language layer under the L4→L5 unhobbling-the-COO-agent effort, and it consolidates three same-day 2026-06-04 inputs (Ben's 6-pattern diagram, the Lieberman content-machine thread, the Google DS-STAR architecture) into one frame.

The unifying frame (so it's not just a list of 6 boxes)

Every one of these patterns is a choice on two independent axes:

Axis A — how you SPAWN the work Axis B — how you RECONCILE the results
options branch (pick one path) · fan-out (run N at once) · loop (keep going until a stop condition) merge (combine all) · select (keep the best, drop the rest) · refute (try to kill each)

The 6 are just the useful cells of that grid:

That grid is also the cheat-sheet for inventing new ones: any spawn × any reconcile that you haven't named yet is a candidate pattern (the additions in the second half come straight out of empty cells — e.g. loop + refute = Reflexion, fan-out + merge but staged = Pipeline).

The other thing the grid tells you: cost scales with the reconcile axis, not the spawn axis. Fan-out is cheap (parallel). Refute and pairwise-select are expensive (every result triggers more agents). So reach for merge/select-by-rubric by default and pay for refute/tournament only when being wrong is costly.

The Six (Ben's set)

1. Classify-And-Act · branch

task → [classifier] →─ agent A
                     ├─ agent B   ← chosen
                     └─ agent C

What it is. A cheap classifier reads the input and routes it to exactly one specialized handler. One path runs, not N. When it's the right tool. Inputs fall into a few known kinds, and the kinds want genuinely different handling. You want to keep each handler's prompt small and specialized instead of one mega-prompt that hedges across every case. Work type. Triage, intake, dispatch. Anything where "what kind is this?" is the first real question. RDCO already runs this. The newsletter sender→handler routing in /process-newsletter; the auto-mode deploy/production-write classifier gate (paper-trade deploy, ASC POST) that decides allow vs. hard-gate-to-founder; /check-board priority routing. Failure mode. A weak classifier silently sends work down the wrong branch and you never see the other branches. Mitigation: log the routing decision; for high-stakes routes, make "unsure" its own branch that escalates rather than guesses (this is exactly the auto-mode hard-gate design).

2. Fanout-And-Synthesize · fan-out + merge

task →┬ agent ┐
      ├ agent ┤ (barrier) → [synthesize]
      ├ agent ┤
      └ agent ┘

What it is. Split the work across N agents that run concurrently, wait for all of them (a barrier), then a synthesizer combines the lot. When it's the right tool. The work decomposes into independent chunks AND the final step genuinely needs all of them at once (dedupe across the full set, an overall ranking, a single written synthesis). Work type. Research sweeps, multi-file reads, "cover this whole surface and give me one answer." RDCO already runs this. /deep-research (one sub-agent per question, context-isolated, then a synthesized brief); /process-newsletter batch mode (one subagent per article → filed); the morning-prep multi-source pull. Failure mode. The barrier wastes the fast agents' time waiting on the slowest, and a single synthesizer can blow its context if N is large. Mitigation: only pay for the barrier when you truly need all-at-once; otherwise use Pipeline (#9). For scale, reduce in a tree (#11 Map-Reduce).

3. Adversarial Verification · fan-out + refute

          ┌ verifier
worker → ─┼ verifier   (each tries to REFUTE the worker's claim)
          └ verifier

What it is. One worker produces a result; multiple independent verifiers are each told to disprove it. Kill the claim if a majority refute. When it's the right tool. Being confidently wrong is expensive, and plausible-but-false outputs are a real risk. The skeptics must be independent and blind to each other, and ideally given different lenses (correctness / security / does-it-reproduce) rather than N identical refuters. Work type. Anything that ships or gets believed: bug findings, financial-execution checks, security claims, vault writes that assert facts, strategic recommendations. RDCO already runs this. The whole /verify-* family (/verify-vault-write, /verify-strategic-output, /verify-dispatch, /verify-pdf-output, /design-critic, /video-critic) and the verification-as-an-independent-worker SOP — fresh-eyes subagent with zero context on the build, because the author shows confirmation bias. This is the pattern this whole session exists to enforce (verify-before-assert). Failure mode. Verifiers that aren't actually independent (share the author's context) just rubber-stamp. Mitigation: zero-context fresh-eyes, distinct lenses, default-to-refuted when uncertain.

4. Generate-And-Filter · fan-out + select-by-rubric

generators →○○○○○ → [filter: rubric + dedupe] → best
                                              └→ discarded

What it is. Over-generate cheap candidates, then keep only the ones that clear a rubric (and drop near-duplicates). When it's the right tool. You can score each candidate absolutely — pass/fail or against a fixed bar, judged in isolation with no reference to the other candidates. Ideas are cheap and variance is high — you'd rather generate 20 and keep the ones that clear the bar than try to nail 3 first-try. The rubric has to be explicit or "filter" just becomes vibes. Work type. Ideation, candidate generation, lead-gen, headline/hook drafting, research-question surfacing. Returns. A set of good-enough outputs (every candidate above the bar), not a single winner. RDCO already runs this. /curiosity (survey → surface many candidate questions → filter to the Notion Research Backlog); /discover-sources (mine many → keep the few that pass); newsletter angle generation in /research-brief. Failure mode. Silent truncation — capping at top-N without logging what got dropped reads as "covered everything." Mitigation: always log() what was discarded and why.

5. Tournament · fan-out + select-by-compare

attempts →○○○○ → [pairwise judges] → final → winner

What it is. Generate several full attempts, judge them against each other (pairwise or bracketed), promote a winner. Often graft the best ideas from the runners-up into the winner. When it's the right tool. You can only judge relatively — "is A better than B?" — because quality is hard to score in isolation but easy to compare. You can tell which of two is better far more reliably than you can put an absolute number on one. The solution space is wide enough that one-attempt-iterated would get stuck in a local optimum. Work type. Design/landing-page variants, naming, positioning, copy, architecture choices, any "there are several good directions" problem. Returns. Exactly one winner (you wanted the single best, not a set). RDCO already runs this. Judge-panel design selection (generate N variants from different angles → score → synthesize from the winner); this is the recommended shape inside build-landing-page Layer 2. Failure mode. Expensive (N attempts + at least O(N) pairwise comparisons, more for a full bracket) and a biased judge picks consistently wrong. Mitigation: diverse generation angles (MVP-first / risk-first / user-first), independent judges, reserve for genuinely wide problems.

Filter vs Tournament — the distinction the founder kept tripping on (it is not search-space size — that is a real but secondary axis). The discriminator is how you can score a candidate:

#4 Generate-And-Filter #5 Tournament
How you score Absolute — pass/fail or vs a fixed bar, each candidate judged in isolation Relative — pairwise/bracket "is A better than B?", no absolute bar exists
You use it when an objective per-item scorer exists quality is hard to judge alone but easy to compare
Returns a set of everything that clears the bar one winner
Cost cheap; scales to large N (score once per item) expensive; ≥ O(N) comparisons, more for full brackets
Discriminates best broadly (keeps all duds out) at the top (separates the great from the merely good)

Rule of thumb: if you can write a per-item scorer, filter. If you can only say "this one's better than that one," run a tournament. Search-space size only tips the decision at the margin — filter scales cheaply to big N, tournaments get expensive fast, so a very large space nudges you toward filter when either scoring mode would work.

6. Loop Until Done · loop + merge-as-you-go

agent → [new findings?] ──yes→ spawn another ─┐
              │                               │
              no                          (loop) 
              ↓
            done

What it is. Keep spawning rounds until a stop condition fires — usually K consecutive rounds that surface nothing new ("loop-until-dry"), a target count, or an exhausted budget. When it's the right tool. The size of the work is unknown up front (how many bugs? how many edge cases? how many sources?). A fixed for i in 1..N would either stop early and miss the tail or waste rounds. Work type. Exhaustive discovery — bug hunts, audits, edge-case enumeration, source gathering, "find everything wrong with X." RDCO already runs this. Loop-until-dry in exhaustive reviews; the /loop skill (this very mechanism); budget-scaled finder loops. Failure mode. Never converges — usually because you dedupe against confirmed results instead of everything seen, so rejected items reappear each round. Mitigation: dedupe against a seen set, not the accepted set; cap consecutive-dry rounds.

Extensions (the empty cells — patterns 7+)

These come straight out of the grid: spawn × reconcile combinations Ben's six didn't name yet. Most are things RDCO already does or should.

7. Pipeline / Assembly-Line · fan-out + staged-merge, NO barrier

A linear sequence of deterministic stages, each consuming the prior stage's output. Each item flows through stage 1 → 2 → 3 independently; item A can be in stage 3 while item B is still in stage 1. Wall-clock = slowest single chain, not sum-of-slowest-per-stage. When: multi-stage work where the stages are fixed and known up front and don't need cross-item sync. This is the default for "do the same N-step thing to many items," and it beats Fanout-And-Synthesize (#2) whenever you don't truly need the barrier. Contrast. Auditable and predictable — but rigid: the stages are hard-wired, no dynamic routing. That's the deliberate trade vs its two neighbors: Orchestrator-Workers (#8) decides the decomposition at runtime (dynamic, not fixed); Classify-And-Act / Routing (#1) conditionally branches to one of several handlers (Pipeline runs every stage, in order, every time). Reach for Pipeline precisely when you want the route fixed and the run reproducible. RDCO already runs this — literally. The 4-seat pipeline-spec-author → pipeline-test-author → pipeline-code-author → pipeline-critic build-out pipeline IS this pattern. Worth calling out as its own box because Ben's #2 (with the hard barrier) is the one people reach for by reflex when Pipeline is usually correct.

8. Orchestrator-Workers (dynamic decomposition) · branch, decided at runtime

Unlike Classify-And-Act (#1, fixed routes) the orchestrator decides the subtasks itself at runtime based on the input, then spins up workers for whatever it decided. Anthropic's "orchestrator-workers." When: you can't predetermine the decomposition — a coding change that touches an unknown set of files, a research question whose sub-questions depend on what the first pass finds. This is the closest of the set to a "real agent."

9. Evaluator-Optimizer (Reflexion loop) · loop + refute-then-refine

generate → critique → refine → critique → … until a quality bar is hit. Distinct from Loop-Until-Done (#6 = discovery exhaustion) — this is quality convergence on a single artifact. When: one artifact, clear quality criteria, and critique reliably points at fixes. Don't confuse it with Generate-And-Filter (#4) — the two get conflated constantly. #9 improves ONE candidate by iterating critique→revise on it; #4 selects among MANY independent candidates and never revises any of them. If you're editing the same draft over and over, that's #9; if you're throwing out drafts and keeping survivors, that's #4. (And both differ from #5 Tournament, which compares candidates against each other rather than scoring or revising them.) RDCO already runs this. pipeline-critic's PASS/FAIL convergence loop; build-landing-page's 4-layer review loop; /improve (read feedback → propose rewrite).

10. Multi-Modal Sweep (diverse-lens) · fan-out + merge, deliberately blind

N agents each search a different way (by-container / by-content / by-entity / by-time), each blind to the others. Catches what any single search angle misses. When: one query angle demonstrably won't find everything (broad audits, "where is X mentioned across the whole vault/repo"). Pairs with a Completeness Critic that asks "what modality didn't we run?"

11. Map-Reduce / Hierarchical Reduce · fan-out + tree-merge

Fanout-And-Synthesize (#2) but the merge happens in a tree instead of one synthesizer, so it scales past a single agent's context window. When: N is large enough that one synthesizer can't hold all results — summarize in groups, then summarize the summaries.

12. Speculative / Race · fan-out + select-first-good

Fire several approaches at once, take the first that succeeds (or the best within a deadline), cancel the rest. When: latency matters and approaches have high variance in success — cheaper in wall-clock than trying them in sequence.

13. Completeness Critic / Gap-Finder · loop, meta

A final agent whose only job is "what's missing — a modality not run, a claim unverified, a source unread?" Whatever it finds becomes the next round's work. The honest backstop on all the above. When: as the closing move on any audit/research/review you want to actually trust.

How they compose (the real point)

Real workflows are stacks of these, not single patterns. The canonical exhaustive-review shape is four of them nested:

Loop-Until-Done ( Multi-Modal-Sweep finders → dedupe vs seen → Tournament/Adversarial verify each survivor → Completeness-Critic asks what's left )

Ben's pipeline-* seats are Pipeline (#7) with an Evaluator-Optimizer (#9) convergence loop bolted on the last seat. /deep-research is Fanout-And-Synthesize (#2) today and would get more exhaustive as Loop-Until-Done (#6) wrapping #2.

So the upgrade path for almost any RDCO skill is: identify which single pattern it is today, then ask which cell of the grid it should graduate to. That's the reusable lens this catalog is for.

Mapping against Ray Data Co

The per-pattern "RDCO already runs this" notes above are the mapping; consolidated for quick reference:

Pattern Live RDCO implementation Concrete upgrade move
#1 Classify-And-Act /process-newsletter sender routing; auto-mode deploy/production-write hard-gate; /check-board priority routing Make "unsure" its own escalating branch (already the hard-gate design)
#2 Fanout-And-Synthesize /deep-research; /process-newsletter batch; morning-prep multi-source pull Wrap in #6 Loop-Until-Done for exhaustiveness; tree-merge (#11) when N blows context
#3 Adversarial Verification the whole /verify-* family + verification-as-independent-worker SOP Keep verifiers zero-context fresh-eyes with distinct lenses
#4 Generate-And-Filter /curiosity; /discover-sources; /research-brief angle gen Always log() what got dropped (anti silent-truncation)
#5 Tournament judge-panel design selection; build-landing-page Layer 2 Diverse generation angles + independent judges
#6 Loop-Until-Done /loop; exhaustive review loops Dedupe vs seen, not the accepted set
#7 Pipeline + #9 Evaluator-Optimizer the pipeline-spec-author → -test-author → -code-author → -critic seats This is the canonical RDCO build-out shape — default to Pipeline over #2's hard barrier

Actionable takeaway for RDCO: this catalog is the design vocabulary for the L4→L5 unhobbling work. When building or refactoring any skill, name its current cell, then pick the target cell — and pay for the expensive reconcile axes (refute / pairwise-select) only where being wrong is costly.

Adding a new pattern (the structure to follow)

When a new workflow pattern shows up, add it here — don't start a new doc (this catalog is the single home; founder confirmed 2026-06-15). Two steps:

  1. Locate it on the grid first. Name its spawn axis (branch / fan-out / loop) and its reconcile axis (merge / select / refute). If that cell is already named above, it's a variant — note it inline under the existing pattern, don't add a box. If the cell is empty, it's a genuinely new pattern → add a box.

  2. Document it with the standard block — every pattern above already follows this; keep it identical so the catalog stays scannable and the patterns stay comparable:

    ### N. <Name>  ·  *<spawn> + <reconcile>*
‹tiny ASCII diagram of the data flow›
**What it is.** 1-2 sentences.
**When it's the right tool.** The condition that makes THIS pattern correct over its neighbors.
**Work type.** The class of task it fits.
**RDCO already runs this.** A live skill/seat that IS this pattern — or "not yet · candidate: …". Grounds it; no abstract boxes.
**Failure mode.** How it breaks + the one-line mitigation.

  3. Naming rule. <Verb>-And-<Verb> or a <Noun> that names the mechanism, not the domain (Tournament, not "pick-best-landing-page"). The name must survive being lifted into a different domain — that portability is the whole point of naming them.

  4. Then wire the chaining. Add the new pattern to "How they compose" if it stacks with others, and to the RDCO mapping table if a skill implements it. A pattern isn't really captured until you've said what it nests inside and what nests inside it.

Cross-references