The Wave pattern — orchestrating in two waves

In short

The Wave pattern structures a multi-agent orchestration into sequential waves rather than a single parallel dispatch. Wave 1 produces intermediate material (data, sources, extracts); wave 2 transforms it into final deliverables. Between the two, an adjustment step analyzes wave 1 results to calibrate wave 2 — trimming it, reorienting it, or enriching it.

In plain terms : instead of launching all agents at once, you launch them in two stages — those who collect first, those who write afterwards — checking between the two that the material is sufficient.

Picture waves rolling onto a beach: each wave carries further what the previous one has deposited on the sand. The Wave pattern orchestrates agents in successive waves — each wave consolidates what the previous one produced, then launches the next on this firmer ground. Between two waves, an observer looks at what has been deposited and decides whether to relaunch the same wave, move on to the next, or abandon certain tasks for lack of material.

Why a single wave is not enough

In a batch of homogeneous agents — all submitted the same task, all independent — a single parallel dispatch (the fire-and-consolidate pattern) is sufficient. Each agent works in a silo, and results are aggregated at the end.

But some tasks are not homogeneous. Writing an article requires sources. Comparative analysis requires data collected upstream. If writer agents are submitted before sources are available, they produce content without material — or they hallucinate that material.

The fundamental problem is a sequential dependency between two classes of tasks. The Wave pattern resolves it by explicitly separating them in time.

In plain terms : if a writer agent depends on a collector agent, they should not be launched at the same time — otherwise the first invents what the second has not yet found.

The pattern mechanics

A Wave orchestration unfolds in three steps:

Wave 1 — upstream execution. A first batch of agents is launched in parallel. Their role is to produce material: collect sources, extract data, summarize documents. They do not produce the final deliverable.

Inter-wave step — analysis and adjustment. The orchestrator examines wave 1 outputs. It evaluates coverage, quality, and gaps. On this basis, it decides how to configure wave 2: which agents to launch, how many, with what context. It can also decide to skip certain tasks if the collected material is insufficient to feed them.

Wave 2 — downstream execution. A second batch of agents is launched, this time fed with wave 1 outputs. They produce the final deliverables.

The pattern can extend to three or four waves if dependencies run deeper — for example: collection → supplementary research → synthesis → writing. In that case, each inter-wave transition plays the same adjustment role. In practice, two waves cover the majority of cases; beyond four, cumulative latency often becomes prohibitive [order of magnitude estimate].

In plain terms : wave 1 gathers the material, wave 2 transforms it into a deliverable, and the orchestrator looks between the two at what is missing before relaunching.

The inter-wave adjustment: the real value of the pattern

The collect → write sequence already exists in any automated pipeline. What distinguishes the Wave pattern is the conditional adjustment between waves.

Without adjustment, wave 2 is simply scheduled in advance regardless of wave 1 results. If a collection agent failed or returned thin material, the corresponding wave 2 task will be launched anyway — and will produce a low-quality deliverable or fail.

With adjustment, the orchestrator can:

• Skip a task if wave 1 material is insufficient to feed it.
• Expand the context of a wave 2 agent if wave 1 produced more than expected.
• Add agents to wave 2 if wave 1 discovered unanticipated angles.
• Correct parameters (for example: an incorrect slug, a miscategorized field) before wave 2 agents propagate them.

In practice, this adjustment phase allows configuration errors to be caught before they contaminate production, and prevents launching agents on material too thin to yield usable results. On an orchestration of ~20 agents in two waves, it is not unusual for 1 to 3 wave 2 tasks to be abandoned or reconfigured at this step [order of magnitude estimate].

In plain terms : the real added value of the pattern is not chaining two waves — it is looking between them and deciding what to do with the result.

When to use the Wave pattern

The Wave pattern is not universally superior to a simple batch. It introduces latency (wave 2 cannot start until wave 1 finishes) and coordination complexity (the inter-wave step must be explicitly implemented).

It is justified when at least two conditions are met:

If tasks are homogeneous and independent, the fire-and-consolidate pattern suffices. Wave is warranted as soon as heterogeneous task classes must chain together.

In plain terms : no point splitting into waves if 5 agents can do the same thing in parallel — Wave only makes sense when some depend on others.

Limits and points of attention

Cumulative latency. Each wave adds an irreducible wait time. A four-wave orchestration is sequentially constrained even if each wave is massively parallel. If each wave typically lasts 3 to 5 minutes, a four-wave orchestration cannot complete in under ~15 minutes, even with full parallelization within each wave [order of magnitude estimate].

Adjustment complexity. The inter-wave step is the most delicate. If the orchestrator misjudges its analysis (overestimating material quality, underestimating gaps), wave 2 is miscalibrated. An overly simple adjustment logic can miss edge cases.

Tool dependency. In practice, some collection agents may encounter network access blocks that were not foreseeable at design time. A degraded collection wave can limit the production wave — even with good inter-wave adjustment [NOT VERIFIED: this sensitivity to external tool failures varies depending on the execution environment].

Error propagation. If the adjustment logic is not strict enough, a wave 1 error can be passed as-is to wave 2. Adjustment must include minimum quality thresholds below which a task is abandoned rather than passed on in degraded form.

In plain terms : each wave adds at least the time of one wave — and if you do not set a quality threshold between them, an error at the start contaminates everything that follows.

Key takeaways

• The Wave pattern splits an orchestration into sequential waves to handle dependencies between heterogeneous tasks.
• The distinct value of the pattern is the inter-wave adjustment: the orchestrator recalibrates the next wave based on results from the previous one.
• Adjustment allows skipping, enriching, or correcting before errors propagate.
• The pattern introduces cumulative latency: each inter-wave transition is a sequential wait point.
• It is warranted as soon as a real dependency exists between two task classes and wave 1 material quality is variable.