Continuous swarm
While the main AI is working, you may identify other independent tasks. Continuous swarm routes these new instructions to background work and returns the results to the current conversation.
Use it to add work as you go. To divide one goal from the outset, start with ordinary swarm.
Decide what to add
Suppose the main AI is revising release notes:
| New work | How to arrange it |
|---|---|
| Check links in a separate help directory | Independent; suitable to add |
| Verify installation commands | Supply the file and reference material |
| Rewrite the paragraph currently being edited | Wait or reassign ownership first |
| Translate the revision that does not exist yet | Wait until that revision is ready |
Check whether inputs already exist and whether file ownership overlaps. Work submitted too early may read an outdated version.
Enable continuous swarm
In a supported coding session, enable Continuous swarm from the composer's additional options. It is separate from Swarm On / Off: ordinary swarm organizes the current goal, while continuous swarm receives additional work.
Send a self-contained instruction. Without recursive mode, the current workflow splits work by line. Keep each task's context, scope, and acceptance criteria on the same line instead of splitting one task into several instructions.
Include the context
Background workers do not automatically receive your complete conversation with the main AI. Replace “make the changes we discussed” with concrete inputs, actions, and deliverables.
For example, add these read-only checks independently:
Check whether the installation commands in docs/setup.md match the scripts in package.json. Report mismatches and suggestions without editing files.
Check internal links in docs/help. Report the source file, target, and reason for any inaccessible link. Do not edit files.
These are illustrative paths; substitute real project paths. Each instruction stands on its own.
For edits, specify file ownership, what must remain unchanged, and verification:
Fix only confirmed broken links in docs/help/faq.md. Preserve the meaning of the text and do not change other files. List old and replacement addresses and verify that each target opens.
Track submission and results
Submission state first tells you whether the request was acknowledged; execution state tells you whether work is running. Pending acknowledgement does not mean execution has started, and an uncertain state does not prove failure.
Results return to the conversation. Review scope, evidence, and unfinished items, then decide how the main AI should use them:
Use the link-check findings to update the help documentation. First list the files you intend to edit; do not change the release guide currently being revised.
This connects background findings to subsequent work. A returned result does not mean integration has already happened.
Disable, stop, or retry
Disabling continuous swarm changes how later messages are handled; it does not undo submitted work. Use the appropriate stop action to interrupt execution, then confirm the actual state.
A request retry handles failed sending or uncertain acknowledgement. It does not guarantee resuming execution at the exact interrupted step. Check existing files and results before proceeding; see Recovery and follow-up.
When the goal needs more decomposition
For a larger goal requiring several levels of planning, use Recursive tasks where supported.
Continuous swarm concerns when new work enters the workflow. Recursive tasks concern how that goal is broken down internally.