Three subagent orchestration patterns for RevOps

Three orchestration patterns cover almost every subagent system we have shipped for revenue operations. Sequential pipeline, fan-out/fan-in, and supervisor-worker. Each has a clean fit, a clear failure mode, and a price the team pays for picking it. This post covers all three with worked RevOps examples, plus the rules for choosing between them and combining them when the system grows.

The framing comes from the TVA methodology and the builds we ship for GTM subagent engagements. Patterns are not theory; they are the shape of the repo you'll be reading at 11 p.m. when something breaks.

Pattern 1: sequential pipeline

A sequential pipeline is a series of subagents that run in order, each consuming the output of the previous step. Step one captures signals. Step two scores. Step three drafts. Step four gates. The output of each step is a structured payload (usually JSON) that the next step reads.

Sequential pipelines win when the work has a clear ordered structure and no branching. Outbound is the canonical RevOps use case (covered in the outbound data pipeline post). Pipeline hygiene is another. Inbound triage is a third. Anything where stage N depends entirely on stage N-1's output is a sequential pipeline candidate.

The win is readability. A new engineer can read the pipeline from top to bottom and understand the system. Failures are easy to localize: the broken stage is the one that ran last. State is held in plain files, not in a runtime graph. Re-running a stage is a single command.

The cost is rigidity. Sequential pipelines do not handle branching well. If signal A should produce a different downstream flow than signal B, you either fork the pipeline (which doubles maintenance) or stuff the branching logic into the drafting subagent (which bloats the prompt). When the work starts requiring decisions, sequential pipeline stops scaling.

Pattern 2: fan-out/fan-in

Fan-out/fan-in dispatches work to N parallel subagents and collects the results. A single coordinator splits a job into independent slices, each slice runs in parallel, results merge at the end. The coordinator is typically dumb: a script that knows how to split inputs and combine outputs.

The RevOps use case is signal capture at scale. Watching Greenhouse boards, SEC filings, BuiltWith deltas, news APIs, and LinkedIn changes are five independent jobs. Running them sequentially takes five times as long as running them in parallel and the order doesn't matter. The same applies to enrichment over a large account list: split into batches of 50, run each batch in parallel, merge results.

The win is throughput. Five sources running in parallel finish in the time of the slowest. The pattern scales horizontally on a single machine and across machines if needed. Failures isolate: one source failing doesn't block the other four. Re-running a single slice is cheap.

The cost is coordination. The fan-in step has to handle partial failures, schema variance across sources, and idempotency. If two parallel slices both try to write the same row in the warehouse, one of them needs to lose cleanly. Most fan-out/fan-in failures in production trace back to a sloppy fan-in step that assumed the parallel slices would always succeed.

Combining sequential and fan-out is common. A typical outbound build runs fan-out/fan-in for the signal capture stage and then a sequential pipeline for everything downstream. The combination keeps the parallel work parallel and the dependent work ordered. Most production RevOps systems we ship have this shape.

Pattern 3: supervisor-worker

Supervisor-worker introduces a planning layer. A supervisor subagent reads the input, decides what work needs to happen, and dispatches to a pool of worker subagents. The workers do specialized tasks. The supervisor reads the results, decides if more work is needed, and either dispatches again or returns the final output.

The RevOps use case is account research. A supervisor reads an account name and the trigger that flagged it. It dispatches workers: one for firmographic research, one for tech stack inference, one for hiring pattern analysis, one for news scanning. It reads the results and either drafts a unified account brief or dispatches a follow-up worker to dig into a specific thread.

The win is flexibility. The supervisor handles heterogeneous tasks where the right next step depends on what the previous step found. Pipeline review is another fit: a supervisor reads the pipeline, dispatches stage-specific workers for deals at each stage, and produces a unified review. Pipeline hygiene often runs this pattern.

The cost is two-fold. First, the supervisor is the bottleneck for complexity. Every new worker type adds branches to the supervisor's logic. Without discipline, the supervisor prompt becomes a 4,000-token instruction monster nobody can read. Second, debugging is harder. Failures can originate in the supervisor's routing logic, in a worker's execution, or in the supervisor's interpretation of the worker's output. Root-cause analysis requires reading the full trace, not just the last step.

How to choose between them

Three questions decide it.

First, does the work decompose into ordered steps with deterministic transitions? If yes, sequential pipeline. Don't reach for fancier patterns when sequential works. The savings on readability and debug time are substantial.

Second, if the work is mostly ordered but some stage benefits from parallel slicing, can you isolate that stage? If yes, sequential pipeline with fan-out/fan-in inside one stage. This is the most common shape in production RevOps and the one we recommend by default.

Third, does the system require runtime decisions about what to do next based on what previous steps returned? If yes, supervisor-worker. But verify the requirement first. Many systems that initially look like they need supervisor-worker turn out to need only sequential pipeline with two or three branches. Hardcoded branches are cheaper than supervisor logic.

A worked decision: outbound vs account research

Compare two real RevOps systems we have shipped.

Outbound pipeline. Signal capture, ICP scoring, contact discovery, drafting, gate. The stages run in order. Each stage has a clear input and output. Branching is minimal. The pattern is sequential pipeline with fan-out/fan-in inside the signal capture stage. Total complexity: low. Engineer ownership: one RevOps lead can maintain the system after handoff.

Strategic account research. Read the account, decide what to research, dispatch researchers, read results, decide if more research is needed, dispatch again or finalize. The flow is recursive and depends on what each step finds. The pattern is supervisor-worker. Total complexity: meaningfully higher. Engineer ownership: requires a senior engineer to maintain the supervisor.

Same team, same toolkit, different patterns. The decision came from the shape of the work, not from a preference for one pattern over the other.

Failure modes we see

Three failure modes show up across builds.

Premature supervisor-worker. Teams reach for the most flexible pattern before they know the work needs flexibility. The supervisor's prompt accumulates routing logic faster than the team can document it. Six months in, nobody can change the supervisor without breaking three downstream workers. The fix is to refactor to sequential pipeline with explicit branches and accept the duplication cost.

Sloppy fan-in. Teams build fan-out/fan-in with strong parallel slices and weak merging. When one slice fails, the merge step either drops the failure silently or crashes the whole job. The fix is to treat the fan-in step as a first-class subagent with its own error handling and its own tests. We've seen production outbound runs go sideways for two weeks because nobody noticed one signal source had been failing every night.

Sequential pipelines that should have branched. Teams force decision logic into a single drafting subagent that's trying to handle three different ICPs with the same prompt. The prompt bloats, the output quality drops, and nobody can tune for one ICP without breaking the others. The fix is to split into three sequential pipelines (or branch the pipeline at the scoring stage), not to make the drafting subagent smarter.

What we tell teams

Start simple. Most RevOps work is sequential pipeline. The pattern is boring, readable, and easy to debug. The team learns the playbook by editing it, and the playbook stays small enough to fit in one head.

Add fan-out/fan-in when one stage becomes the bottleneck. Most often that's signal capture or enrichment. The pattern is mechanical and the parallelism win is real. Just write a real fan-in step.

Reach for supervisor-worker only when the work requires runtime decisions about what to do next. That's a narrow set of RevOps problems: strategic account research, multi-stage pipeline reviews, complex inbound triage. Most teams will never need it. The teams that do should have an engineer who can own the supervisor's logic the way a senior dev owns a service.

For the CLAUDE.md that gates output across all three patterns, see how to write a CLAUDE.md for your revenue team. For the architecture that sits underneath them, see Claude Skills vs MCP for GTM stacks. For the working outbound pipeline that uses sequential plus fan-out/fan-in, see the outbound data pipeline post. We deploy these patterns as fixed-fee engagements and hand off the repo on day one.