Swarms

The brief

Everything starts from the brief: what the swarm should accomplish. Use Improve to have the AI sharpen it before composing, and attach images if the work needs them. A swarm can also be driven from an anchored Jira card, which seeds the brief from the issue.

Composing the team

1. 1Open the Launch Swarm modal and pick the target project. Archived projects are not valid targets.
2. 2Write the brief, then click Compose Swarm. The composer reads the brief, plus the target project context, and proposes a crew: role chips with a stated reason for each seat, steppers to adjust counts, and optional roles you can add with one click.
3. 3Or start from a template instead. The browser is organized as a ladder: Solo (1 agent), Pair (2 agents), Squad (4-5 agents), and specialist multi-phase Workflows, with legacy templates behind a toggle.
4. 4Adjust the team, the Definition of Done, and the delivery destination.
5. 5Check the receipt in the footer, then hit Launch Swarm.

If the brief is too vague to match a crew, the composer says so and routes you to the two recovery paths: add specifics and compose again, or start from a template and adjust by hand. A composed crew gets the same build, review, and gate phase machinery a catalog template gets. Nothing about composition is a shortcut around governance.

Definition of Done

The Definition of Done is the contract the run is judged against: each criterion is a plain statement of what must be true for the work to pass. Add criteria by hand or use Generate from brief. Criteria are verified during the Gate phase by the review strategy you pick. Criteria without a review strategy are promises nobody checks, and the modal warns you loudly when that is the case.

• →Proof Rotation (recommended): rotating agents verify each other’s work against your criteria before done is done.
• →Single review pass: one independent reviewer checks the work once.
• →None - build only: no verification. The receipt flags your criteria as UNVERIFIED.
• →Advanced strategies: Red / Blue Team, Debate Consensus, Escalation Ladder, Regression Guardian.

Oversight

Oversight adds governance seats to the run, scoped to security, compliance, or both. It is on by default: that is the intended posture, drop it deliberately. Oversight also appends its own criteria to the Definition of Done, for example no injection or secret leaks in the delivered work, so the governance seats have something concrete to hold the run to.

Delivery

For repo-backed projects you choose how the work ships before it starts:

• →Open a draft PR: branch off the base, draft PR with the brief and each Done criterion with its proof. CI runs; nothing merges until you promote it.
• →Hold in chat: work lands on a private hold branch with no PR. The result card arrives in chat with Push as draft PR, Ask for changes, or Discard.
• →Push straight to PR: for teams that want the artifact immediately.

When a Jira card is anchored, results can post back to the card, with failure posts as an explicit opt-in. Advanced settings cover the base branch and PR title.

The receipt and the cost estimate

The footer is a receipt that reflects reality: total agents including Oversight seats, the number of Done checks and how they will be verified, the delivery mode, and an estimated cost range. The estimate is per-role: each seat is priced on its assigned model from the live catalog, self-hosted models price at zero because you run the hardware, and the range is shown as a low-high band rather than a false-precision point, because real agents loop through more tool turns than any model predicts. Launch stays disabled until a team exists.

Watching a run, and what failure means

A launched swarm reports progress on a card in the project chat with a timeline of phases and agents. When a run fails its quality gate, the card tells you which kind of failure it was: an environment problem, where the workspace never mounted and nothing could be produced, which is not your fault and just needs a re-run, or a content gate, where the team finished but the review found specific items that did not meet the bar. The raw reviewer findings stay available under details, and re-running lets the team revise. Past runs live in swarm history with per-run details and recorded trace events.