Dynamic mission planning
The planner calls a real model to decompose a goal into a dependency-aware task graph — 3 to 12 tasks, cycle-checked, validated with Zod before anything is persisted. No hard-coded task lists.
LIVE MVP · AUTH + TENANCY + DURABLE DISPATCH SHIPPED
Build AI workforces that actually get work done.
One goal. A governed swarm. Verified work. AgentSwarm plans a mission, routes it across specialist agents, blocks consequential actions on human approval, and backs every step with a real, replayable event ledger.
Human approval gatesReal event ledgerPostgres-authoritativeMulti-tenant by design
Execution architecture
Intent to evidence, with every boundary visible.
Planning is separated from execution, and execution from verification — the backend, never the browser, owns what actually happened.
1Intent
2Plan
3Route
4Execute
5Approve
6Verify
Platform
What's actually running today.
Every item below is implemented and has been exercised end to end — including deliberately breaking it (killing Redis mid-mission, crashing the worker) to confirm it recovers correctly.
Eight specialist agents
Planner, researcher, architect, backend, frontend, QA, security, and DevOps — each task is assigned to the specialist whose role matches the work.
Model routing
A provider-neutral adapter talks to any OpenAI-compatible endpoint (shipped with Qwen). Unconfigured providers block missions honestly as BLOCKED — never simulated as running.
Governed approvals
Tasks can declare requiresApproval and a risk level. The task genuinely stops in WAITING_APPROVAL until an operator with OPERATOR-level role or above decides — approve resumes, reject fails the mission.
Real-time event ledger
Every state change is a persisted, sequenced event. Server-Sent Events stream them live via Postgres LISTEN/NOTIFY, with durable backlog replay on reconnect — not a client-side timer pretending to be progress.
Durable dispatch
Postgres row-level locking (FOR UPDATE SKIP LOCKED) is the sole authority on task claims. Redis/BullMQ adds a low-latency wake-up signal on top, with a Postgres-only fallback poll — verified to survive a real Redis outage and a worker crash mid-backlog.
Real auth (bcrypt + DB-backed sessions) and org/project tenancy with role-based access ship alongside all of this — cross-organization access returns a genuine 404, not just a hidden UI element.
Truth doctrine
We don't say LIVE unless it's live.
AgentSwarm's own runtime uses explicit states — LIVE, CONFIGURED, UNAVAILABLE, UNKNOWN — instead of guessing. This page follows the same rule.
Shipped & verified
- ✓Mission → task DAG → agent execution, backend-authoritative end to end
- ✓Real auth: bcrypt password hashing, DB-backed sessions, org/project/role tenancy
- ✓Approval gates that genuinely block execution until an operator decides
- ✓SSE event stream with durable replay from a persisted, sequenced ledger
- ✓Postgres-authoritative dispatch with Redis/BullMQ as a coordination layer, not a truth source
- ✓A verification gate that checks real artifact existence before COMPLETED
Roadmap — not yet live
- ○MCP tool registry and gateway
- ○Sandboxed / isolated task workspaces
- ○Persistent memory and reusable skills
- ○Scheduler for recurring or webhook-triggered missions
- ○Cost engine backed by real provider-reported usage
- ○Richer verification gates (build, typecheck, security scan, accessibility)
Use cases
What today's swarm can actually produce.
Every succeeded task writes a real artifact. Missions currently complete when every task's artifact exists — deeper verification (build, test, security scan) is on the roadmap above.
Architecture reports
Research summaries
API design proposals
Security review checklists
Technical documentation drafts
Migration & audit plans
FAQ
Direct answers about AgentSwarm.
What is AgentSwarm?+
AgentSwarm is a control plane for AI workforces: you describe a goal, a backend-authoritative planner decomposes it into a dependency-aware task graph, specialist agents execute tasks against a real model provider, consequential actions require human approval, and every state change is a persisted, replayable event.
Is the mission execution actually real, or a demo?+
It's real. There is no client-side timer or random-number engine driving progress. Postgres holds authoritative mission/task state, a worker leases and executes tasks with FOR UPDATE SKIP LOCKED, and the browser only ever renders what the backend actually persisted — verified by deliberately creating missions during a real Redis outage and a killed worker process, and confirming no lost or duplicated work.
What happens if a model provider isn't configured?+
The mission is persisted and then honestly moves to BLOCKED with provider status UNAVAILABLE. It is never simulated as running or completed.
How does approval actually work?+
A task can declare requiresApproval and a risk level. When the worker reaches it, the task genuinely stops in WAITING_APPROVAL and a persisted approval record is created. Deciding requires OPERATOR role or above in that mission's organization — approving resumes the exact task, rejecting fails the mission. There's no optimistic client-side approval.
Is there real multi-tenancy?+
Yes. Every mission belongs to exactly one organization and project, assigned server-side from a verified membership check. A user outside that organization gets a genuine 404 on the mission — not a hidden UI element with the data still reachable underneath.
What isn't built yet?+
MCP tool registry, sandboxed task workspaces, persistent memory and skills, a scheduler, a real cost engine, and richer verification gates (build/typecheck/security). These are on the public roadmap above, not claimed as live.