Parallel orchestration patterns: the 3 shapes of concurrent AI work

If you have 100 specialist agents and you run them one at a time, you've thrown away the reason to have 100 of them.

The value of a specialist fleet isn't that it exists. It's that many specialists can work the same problem at the same time, each on a different slice. Take that away and you're left with a slow generalist cut into a hundred pieces.

So this post is about the three patterns NEXUS uses to run agents in parallel (fan-out, pipeline, and swarm), and the two ways most multi-agent systems get parallelism wrong.

Pattern 1: Fan-out

Fan-out is the simplest of the three, and where most jobs begin. The orchestrator takes a directive, splits it into independent subtasks, dispatches each to a specialist, and waits for all of them. Then it aggregates.

Say you want a competitive analysis of five companies. Fan-out sends a research agent after each one, all at once. Five agents run in parallel; when they return, a synthesis agent folds the results into a comparison table. Total time is roughly the slowest single agent plus synthesis, not five times one agent.

Fan-out works when:

• Subtasks are genuinely independent (company A's research doesn't depend on company B's)
• Aggregation is straightforward: combine, compare, rank
• Results are bounded in size, not an open-ended stream

And it fails when:

• The subtasks actually depend on each other (serial is correct, even though it feels slow)
• One subtask runs dramatically longer than the rest: the straggler drags the whole batch
• The aggregation step is itself the bottleneck, so you've just moved the cost around

Pattern 2: Pipeline (staged parallelism)

Pipeline parallelism is the one nobody reaches for first, and the one that matters most at scale.

Picture five stages (research, draft, review, polish, publish), each staffed by its own specialists. Push twenty items through that sequence one at a time and item two can't start research until item one has cleared all five stages. Slow, and wasteful.

Pipelining overlaps them instead. While item one is being drafted, item two is in research. When item one moves to review, item two moves to draft and item three enters research. Your research, drafting, and review specialists are all busy at once, on different items.

This is how factories run. It's how CPU instruction pipelines run. It's one of the oldest tricks in systems design, and multi-agent frameworks are only now starting to use it.

Pipelines work when:

• Many items flow through the same sequence of stages
• Each stage takes roughly similar time (otherwise one becomes the bottleneck)
• Each stage's output is durably stored before the next consumes it, so nothing gets re-run

NEXUS leans on pipeline parallelism for batched content workflows, data-enrichment jobs, and research sweeps.

Pattern 3: Swarm (redundant parallelism)

Swarm is the least intuitive and the most useful when quality is on the line.

The idea: for a high-stakes judgment call, run the same task through several specialists at once and have an arbiter pick the best answer, or fuse the best parts of each.

Say you need a headline for a press release. You dispatch the hook-writer three times in parallel, with slightly different prompts or temperatures, and get three candidates. The orchestrator either picks the strongest (via a ranker agent) or merges them into a fourth. Swarm costs more, three calls instead of one, but it produces better results where creativity or judgment matters. It's a deliberate trade: pay several times the money to cut quality variance.

Swarm works when:

• The output is high-stakes and quality variance matters more than cost
• The task is genuinely creative and probabilistic: headlines, naming, tone choices
• It's a judgment call you'd want a "council" to vote on

And it's the wrong tool when:

• The task is mechanical and outputs barely vary: formatting, JSON extraction
• The run is budget-constrained and can't afford the fan-out
• The arbiter has no clear quality signal to choose on

This is the pattern behind the NEXUS council, where three to five specialists debate a hard decision and the orchestrator applies the verdict.

Two traps that kill most parallel orchestrations

Trap 1: Implicit dependencies

You think the subtasks are independent. They aren't. Company A's research actually had to happen before company B's, because B's strategy is a response to A's positioning. You ran them in parallel, got disconnected results, and quality paid for it. The orchestrator has to model dependencies honestly: if it can't prove two tasks are independent, it should serialize them. This is where most naive frameworks fail: they parallelize aggressively and ship fragmented work.

Trap 2: Context duplication

Running five fan-out agents in parallel usually means passing the same context five times, which means paying five times the input-token cost. Unless you reuse context deliberately (prefix caching, shared memory), your "5x speedup" is really a 5x cost explosion wearing a performance costume. NEXUS handles this with scoped context per agent (each specialist gets only what it needs, not the whole run history) and the shared-memory layer we'll cover next.

How NEXUS chooses

For any directive, the orchestrator picks the pattern from three inputs:

1. Task structure. Independent subtasks point to fan-out. Many items through sequential stages point to pipeline. A single quality-critical output points to swarm.
2. Budget. Swarm is expensive, fan-out is moderate, pipeline is cheap but needs volume. The orchestrator reads your tier and spend cap and chooses accordingly.
3. Quality stakes. A launch headline gets swarm. A routine summary gets a single agent. Enrichment on 500 rows gets a pipeline.

You don't pick the pattern. The orchestrator does, from what you asked for and what you're willing to spend. That's the point of orchestration.

Why it matters

Most "multi-agent" frameworks ship with one parallelism pattern, usually naive fan-out, occasionally a pipeline. When the task doesn't fit the pattern, you get bad results. NEXUS switches patterns per task, which is why the same directive can return a five-second answer for a simple job and run a ninety-second pipeline for a complex one, and both feel right. Parallelism isn't a feature you bolt on at the end; it's a decision that shapes everything downstream. We made it core.

Next: "Quantum cloning explained: the shared-memory trick that makes 100 agents smarter than 1", the name sounds like sci-fi, the idea is simple, the impact is large. How agents share what they learn across the fleet without bloating their context.