How it works · by Spectrum Web Co
KanbanOS takes a request through five stages: a plain ask is planned into a graph-of-thought brief, the brief is shared through the Agent Substrate, a 15-agent swarm works it in parallel worktrees, the board shows every claim and move, and the ship loop opens a pull request that a human approves.
Planning first. Coding second. Swarm where the lifecycle needs it. Humans on every irreversible call.
The loop
A request enters as plain language and leaves as a reviewed, human-approved merge. In between, KanbanOS makes every step visible — the brief, the claims, the verdicts and the review — so operators can see progress without reading five terminal scrollbacks.
01 — Step 01 · Plan
Ultrathink hooks the agent's prompt. It filters noise, uplifts the ask into an XML spec with a dependency graph, builds a graph of thought and schedules the work into parallel execution waves. Each request receives a Graph ID in the form ut-… that follows it across the board, Linear and Notion.
02 — Step 02 · Ask first
Ambiguity is settled before a line is written. The planner raises human-in-the-loop questions for anything the spec cannot resolve on its own — scope, boundaries, irreversible choices — and records the answers in the brief so every agent downstream sees the same decision.
03 — Step 03 · Swarm
Agent Swarm dispatches the waves across specialists in parallel worktrees. Every handoff is a signed verdict in the swarm.v1 protocol and the Task Store is authoritative, so two agents never claim the same work and uncertain work stops instead of guessing.
04 — Step 04 · Ship
The post-plan coding loop opens a pull request and drives Greptile-style review until it scores 5/5. Then it stops. Humans approve merges, releases and anything else that cannot be undone, and the board records the gate as the final move on the card.
Where it lands
Each stage is a real component under active build by Spectrum Web Co: Ultrathink and Agent Swarm are public, Agent Substrate is in use inside KanbanOS, and the board carries the operator lineage of the product.
FAQ
What happens at each stage, and what humans still decide.
A Graph ID is the single identifier KanbanOS assigns to a request when Ultrathink plans it, in the form ut-… . It names the graph-of-thought brief and follows the work across the KanbanOS board, Linear and Notion, so status stays consistent wherever the team looks. Every claim, verdict and pull request produced for that request carries the same Graph ID, which is what lets operators trace a merged change back to the original ask and the questions answered along the way.
Humans intervene at three points. Before work starts, planning raises human-in-the-loop questions so ambiguity is settled up front. During delivery, any fail-closed gate that cannot produce a signed verdict escalates to a person instead of guessing. At the end, a human approves the merge, the release and anything else that cannot be undone. Everything else — planning, dispatch, parallel implementation and review — runs without a person in the loop, which is where the speed comes from.
Yes, within explicit ceilings. Agent Swarm supports headless execution for unattended runs and a dry-run simulation that previews the plan before anything is dispatched. Unattended cycles run up to the gates: the swarm will plan, implement, verify and open a pull request on its own, then stop at the human merge gate. Ceilings on autonomy are configured per team, and stalled or uncertain work escalates rather than continuing.
KanbanOS treats Notion and Linear as sources of truth alongside its own board. The Graph ID is written to each, so a card on the KanbanOS board, an issue in Linear and a page in Notion all describe the same unit of work and update together as agents claim and move it. Teams keep their existing tracking and documentation habits; KanbanOS adds the agent layer on top rather than asking anyone to migrate.
Early access
Bring one real request and we will take it from plain ask to gated ship with you during onboarding.
