EngineeringAgentsParallelism

How Spectral agents orchestrate work in waves

Artur Czemiel
3 min
On this page5

The usual way to "scale" an agent is to hand it a plan and let it grind through the tasks one by one. Spectral's built-in orchestrator does the opposite: it never does the work itself. It delegates every task to built-in subagents — and it structures that delegation into waves: one parallel call plus a barrier, repeated until the work is done.

One call, one barrier

The orchestrator (ghost) spawns four built-in subagents: researcher for read-only investigation, executor to implement and verify, reviewer to review changes before done, and fork as the generalist for everything else.

A wave is one parallel subagent call — a set of independent tasks launched together — plus a barrier. At the barrier the orchestrator waits for ALL reports and verifies each one against its done-criteria. Only then does it decide what happens next. No report is left behind, no task silently half-done.

The orchestrator delegates to three researchers, hits a barrier, delegates to three executors, hits another barrier, then runs a single review
FIG.01 The orchestrator delegates to three researchers, hits a barrier, delegates to three executors, hits another barrier, then runs a single review

Dependencies decide the waves

Routing is a topological sort. Independent tasks go into the same wave — once a wave grows past about eight tasks, split it into smaller ones. Tasks that depend on other tasks' results go into separate later waves — never in the same wave as what they depend on. A strict 1:1 dependency is chained with {previous}, so each subagent receives exactly what the last one produced.

And for very large batches of fully independent, fire-and-forget research, waves are the wrong tool — that's what session fanout is for. Fanout spawns big batches where results are read later; waves are in-process orchestration where the results come back to the orchestrator.

A dependency DAG grouped into wave one with tasks A, B and C, wave two with D and E, and wave three with F
FIG.02 A dependency DAG grouped into wave one with tasks A, B and C, wave two with D and E, and wave three with F

Distillates, not transcripts

Between waves the orchestrator passes only distillates and selected facts — never full transcripts. Each barrier produces a short distillate of roughly 10-15 lines: the decisions made, the key file paths touched, and what was rejected. There is no PLAN.md to keep in sync; the distillate lives in session memory, and the next wave's prompts are built from it.

Four stages of a wave: parallel subagent calls, a barrier where all reports arrive, a 10-15 line distillate, and a continue, re-plan or stop decision
FIG.03 Four stages of a wave: parallel subagent calls, a barrier where all reports arrive, a 10-15 line distillate, and a continue, re-plan or stop decision

The standard shape

Most jobs fall into the same rhythm: a research-wave to investigate, an implement-wave to build, and a review-wave to check the result. The reviewer pass is mandatory — nothing counts as done until the changes have been reviewed. And there is no wave-level timeout: only the per-subagent timeout applies, so a wave finishes when its subagents finish, not when a clock runs out.

Takeaways

  1. Delegate, never grind. The orchestrator splits work across researcher, executor, reviewer, and fork subagents instead of doing the work itself.
  2. A wave is a call plus a barrier. Wait for ALL reports and verify each against its done-criteria before launching the next wave.
  3. Dependencies set the order. Independent tasks share a wave; dependent ones wait for a later wave, in topological order — or chain with {previous}.
  4. Pass distillates, not transcripts. 10-15 lines of decisions, file paths, and rejections — kept in session memory, not in a PLAN.md.