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:
- 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
- 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
- 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
- Shell (curl)
- Python (requests)
- JavaScript (fetch)
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_loopshigh 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_loopsdoes 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
SequentialWorkflowis simpler and cheaper