Using swarm

Give swarm one clear goal, let each workstream handle part of it, and combine the results in the current conversation. This guide follows a release-guide review from submission to the final findings.

Prepare the material

Attach the document or identify a readable file in the current workspace. Specify its version and whether this is a read-only review or an editing task.

Reviewing release notes need not expand into rewriting all product documentation. A clear scope makes findings easier to combine.

Enable and send

Turn on Swarm at the bottom of the composer, confirm that it reads Swarm On, and send your goal. For a single turn, you can explicitly ask to use swarm in the message without leaving the toggle enabled.

Use swarm to review this release guide. One workstream should check feature descriptions for contradictions; another should check instructions for missing prerequisites or entry points. Cite the location, reason, and suggested change for each issue. Combine duplicates and list anything that cannot be verified. Do not edit files yet.

This specifies both responsibilities and the output format. Asking several agents to “take a look” may produce overlapping answers that are difficult to integrate.

Read progress

This fictional release-guide review shows the complete flow. Enable swarm and send the preset task to see both reviews, synthesis, and the final reply. Use the arrows to inspect individual steps or switch between graph and list. The demo runs only on this page and sends no real task.

The graph shows the overall division of work and node states. A completed branch does not mean the final synthesis is ready while the candidate conclusion is still waiting.

The list helps you inspect task names, workers, and states individually. In this example, feature descriptions are checked while instructions remain in progress. Both views show the same tasks.

The narrative explains who is working, whether anything depends on another branch, and what should happen next. Color depth in the legend represents usage, not answer quality.

Set the order where it matters

Not every step should start together. If you want a revised guide after the review, wait for both reviews:

Run both reviews in parallel. Wait for both to finish before consolidating suggestions. Where findings conflict, present the evidence for each and ask me to decide rather than editing the file.

Dependencies let work wait for required inputs while unrelated branches proceed. An ordinary task can have dependencies; an execution order alone does not require recursive mode.

Make results usable by the next task

Waiting for upstream work and referring to completed results are different requirements. The first controls when work starts; the second concerns which material is available when it starts.

A terminology check might use a completed feature-review summary. Sharing a summary does not share the entire conversation or make running tasks automatically reread every new conclusion. If the terminology check needs both final reviews, explicitly ask it to wait for both.

State this requirement in the task and check execution records to see whether it was used:

Give a later terminology check any completed feature-review summary. If no result is available yet, let it work independently; reconcile all findings during final synthesis.

Checks that start together may have no completed summaries to read. Work that requires the full upstream conclusion should explicitly wait for it.

For a complete artifact, identify the file or material, its version, and the relevant sections. “Use the previous agent's result” is not a sufficient handoff.

Consolidate and act

Ask for integration rather than concatenation:

Combine findings by source location. Keep one entry per duplicate issue, show the evidence for conflicting opinions, and separate straightforward fixes, decisions I need to make, and unverified claims.

Check that citations exist, changes preserve meaning, and unfinished branches are acknowledged. Authorize edits only after reviewing the findings, then check the whole document.

For parallel file edits, assign ownership first. Workers may share a working directory rather than automatically receiving isolated copies. For partial failure, use Recovery and follow-up instead of immediately repeating everything.

A task description is not a file-access boundary. Before sharing a workspace, remove unrelated credentials and private files, and provide only the material each workstream needs.