The swarm agent

What the default general agent handles, how requests route to it, what it can reach, and where it stops.

After this page you know when your request goes to the swarm agent instead of a named bee, what the swarm agent can do once it has the request, and what it can't. The contract is the same as everywhere in Swarm: No human writes code. A human always reviews.

What it handles

The swarm agent is Swarm's default general agent, built on the Claude Agent SDK. It handles anything that doesn't match a named bee: bug investigations, small features, refactors, questions about a repo, multi-step asks that no single recipe covers. Named bees are shortcuts for well-shaped jobs; the swarm agent is the primary path for everything else (ADR 0055).

How routing decides

The router's classify step has exactly two outcomes:

Your request	Where it goes
Names a bee that exists in the catalog	That bee's recipe (the explicit shortcut path)
Names no bee, or names one that doesn't exist	The swarm agent

There is no LLM guessing which bee you meant: if you didn't name one, you get the swarm agent. A typo'd bee name also falls through to the swarm agent rather than being rejected. From Slack, the confirmation pulse tells you which path you took: a named bee gets Routing `bee` for `space` ; a fall-through gets Swarm agent on it for `space` . See From Slack for the mention syntax.

What a run looks like

The swarm agent plans first, then executes step by step, emitting timeline events you can watch on the dashboard. If the request is ambiguous it pauses and asks you in-thread instead of guessing; if you put /plan in the request it stops after planning so you can review the plan before anything runs; the conversation stays open and your next reply continues the work. Details are on How Swarm thinks.

Capabilities

The swarm agent's reach at boot is a merged surface, extended along an ownership split (ADR 0109):

MCP servers: external systems, declared in mcp-servers.json. Today: hive (the shared pattern layer) and figma (read-only design access). These grant new reach and credentials, so only engineers add them, via reviewed config changes.
Skills: reviewed "how we do X" playbooks the agent invokes on demand. Today: raise-a-pr, security-self-review, run-e2e-after-pr, use-figma-designs, use-hive-context. Skills carry knowledge, not credentials, so any internal 3SC staff can add one, via PR to swarm-skills/ or self-serve through the dashboard with admin approval before activation.
Built-in tools: replying in your Slack thread, asking you for input, verifying a web UI change, and triggering the end-to-end test suite after opening a PR. The swarm agent does not dispatch other bees mid-run; that capability is switched off by default, and naming a bee in your ask still routes straight to that bee's recipe.

A good example ask

@cube-agent repo:3sidedcube/some-api The /api/health endpoint returns 500 on
cold start. Find the cause, fix it, and add a regression test.

Good asks name the repo, describe the observed behaviour, and say what done looks like. The swarm agent fills the gaps a recipe would have pre-answered, so the more concrete the ask, the fewer clarifying questions you get back.

Limits

It ends in a PR, not a deploy. Code changes land as a pull request for a human to review, never a direct push.
It's headless. It runs unattended on Fargate. Any system it reaches needs a non-interactive credential wired by an engineer; it can never complete a "click Authorize" OAuth flow mid-run.
Turns are bounded. Planning gets 6 turns; each execute step gets 50 by default (operator-tunable via SWARM_AGENT_MAX_EXECUTE_TURNS). These are runaway backstops: a run that exhausts them stops rather than looping forever.
Spend is bounded too. Each run has a dollar budget ($20 per run on staging). At 80% spent the agent is told to wrap up: commit, push, open a draft PR or report findings. At the cap it runs one short salvage turn, then pauses with a budget-exceeded decision card for you instead of failing the run.
It waits on you. A clarification or approval pause parks the run until someone answers; no answer means no progress.
Dashboard skills are words-only. Skills added self-serve through the dashboard can't bundle scripts or files; anything executable takes the reviewed PR route, where a skill can ship files alongside its SKILL.md.