What is Swarm?
Unattended coding agents that take a task from Slack, Jira, GitHub, or the dashboard and deliver a pull request for human review.
After this page you'll know what Swarm does, how a run flows from trigger to pull request, and which way in fits the task you have. Swarm is 3 Sided Cube's system of unattended coding agents: you hand it a task, a bee (an agent run) works through it autonomously in an isolated container, and the result comes back as a pull request on GitHub.
The full flow in two minutes: triggers → router → bee or swarm agent → pull request → human review.
Specialist bees vs the generalist swarm agent, and how a run stays grounded in project context.
The product contract, in full: No human writes code. A human always reviews. A bee never merges its own work: every change lands as a PR that a person reads, approves, and merges.
The one-minute version
You mention Swarm in a Slack channel or send the bot a direct message, move a Jira ticket to the "AI" status, @mention the bot in a GitHub issue or PR comment, or press "Run a bee" on the dashboard. Most requests go to the swarm agent, the default general agent, which plans the work, reads the repo, and can ask you a clarifying question mid-run. If you name a specific bee, it runs that bee's recipe (its fixed playbook) instead. Either way, the output is a PR, or an honest verdict explaining why no PR was opened.
@cube-agent repo:org/name fix the flaky login test on CIHow a run flows
- Trigger: a Slack mention or DM, Jira status change, GitHub comment, dashboard button, webhook, CLI call, or schedule.
- Validation: the trigger is checked at the door. Webhooks get HMAC signature verification, and a repo must be identifiable from the message, the ticket, or the Space's configured sources. An exact
repo:org/nametoken always works, but a shorthand project name is matched against the project catalog too, and a DM's pinned project fills in the default. If nothing resolves, the bot asks which project you meant rather than failing. - Classification: did you name a specific bee? If yes, that bee's recipe runs. If not, the request goes to the swarm agent.
- Auth: Swarm resolves a GitHub token, preferring the GitHub App's short-lived tokens over a static PAT.
- Agent phases: inside an isolated container the bee scans/investigates, fixes, then ships (lint, test, branch, commit, push, open the PR). Each phase has an action budget so runs can't wander forever.
- PR: the pull request appears on GitHub, the linked Jira ticket gets a comment and moves to "Awaiting PR", and a human reviews.
Runs can also pause: if the agent needs a decision from you, it posts the question in the thread (or on the dashboard) and resumes when you answer.
Ways in
| Way in | What it looks like | Read next |
|---|---|---|
| Slack | Mention the bot in a channel, or just DM it directly; a living status card updates in-thread. In a DM you can pin a default project so you don't have to name the repo every time | Slack |
| Jira | Move a ticket to the "AI" status, or @mention the agent in a ticket comment | Jira |
| Dashboard | Press "Run a bee", pick a recipe and repo, optionally attach files | Dashboard |
| GitHub | @mention the bot in a PR or issue comment; replies continue the same run | GitHub |
| More | Generic signed webhook, CLI (./scripts/run-agent.sh), and scheduled runs | Other triggers |
What Swarm is not
- Not a chatbot. A bee is a worker, not a conversation partner. It will ask you questions when it's blocked, but the goal of every run is a concrete deliverable, usually a PR.
- Not auto-merge. Nothing a bee produces reaches a main branch without a human approving it. A human always reviews.
- Not magic. A bee can finish without a PR (blocked, false positive, or nothing to change), and it will tell you why, in the thread and on the dashboard.