Skip to main content
Swarm Type: PlannerWorkerSwarm

Overview

PlannerWorkerSwarm implements the planner-worker pattern for long-running, multi-step tasks: planning and execution are handled by different agents so neither role has to do both. A planner agent decomposes the goal into a queue of sub-tasks, your worker agents claim and execute those sub-tasks concurrently (optimistic concurrency — no locks, each task is claimed atomically), and a judge agent evaluates the results after each cycle to decide whether the goal is complete, needs another round of targeted work, or has drifted enough to warrant a fresh start. Each cycle runs in three phases:
  1. Plan — a planner agent reads the goal (and, from the second cycle on, the judge’s feedback) and writes a set of sub-tasks into a shared queue, with optional dependencies between them
  2. Execute — your worker agents claim tasks from the queue and run them concurrently; workers do not coordinate with each other directly, they only interact with the queue
  3. Judge — a judge agent reviews what the workers produced against the original goal and returns a verdict: complete, needs more work (with specific gaps and follow-up instructions), or needs a fresh start if the work has drifted off course
max_loops caps the number of planner-worker-judge cycles; the swarm stops early as soon as the judge marks the goal complete.
The planner and judge agents are created internally by the swarm and are not configurable through SwarmSpec — there are no PlannerWorkerSwarm-specific tuning fields beyond the common agents, task, and max_loops. The agents you supply in agents become the worker pool; at least one worker agent is required.

Architecture

The planner only plans and the judge only evaluates — neither one executes tasks. Workers only ever talk to the queue, never to each other or to the planner directly.

Use Cases

  • Long-running coding or research tasks that benefit from explicit planning before execution
  • Workflows where you want an automatic “did we actually finish?” check instead of a single fixed-depth pass
  • Decoupling decomposition from execution so the worker roster can be swapped without touching the planning logic
  • Tasks prone to drift over multiple iterations, where a judge-triggered fresh start prevents compounding errors
  • Queue-based parallel execution of many independent sub-tasks generated from one high-level goal

API Usage

Example Response:

Best Practices

  • Give worker agents narrow, execution-focused system prompts (“execute the sub-task you are given”) rather than broad planning instructions — planning is the planner’s job, not theirs
  • Set max_loops high enough to allow at least one re-planning cycle (2-3) for non-trivial goals — the judge’s first verdict is often “needs more work,” and the swarm needs a second cycle to act on that feedback
  • Use 2-4 worker agents with complementary skills (e.g. research vs. writing) so the planner has meaningfully different sub-task types to assign
  • The swarm stops as soon as the judge marks the goal complete, so a low max_loops does not waste cycles on an already-finished task — the ceiling only matters when the goal is genuinely hard to satisfy
  • Best for open-ended, multi-step goals; for a fixed, known sequence of steps a SequentialWorkflow is simpler and cheaper