Your agents run the inner loop: prompt, edit, test, repeat. bridge is the outer loop around them. It decides what work happens next, hands each unit to a fresh agent session, tracks live progress with completion, confidence, and risk, verifies results with an independent session, and routes sign-off to a human when it matters.
It is not a kanban tool and not an agent framework. It is the layer between them: a board where work becomes visible, dispatchable, and accountable, whatever executes it.
$ curl -fsSL https://raw.githubusercontent.com/state-vector/bridge/main/install.sh | bash
$ bridge pair https://your-hub.workers.devThat is the whole runner. It pairs with your hub using a device code, then claims tasks and dispatches them to opencode sessions on your machine, in isolated git worktrees, one PR per task. Results come back to the board for review.
| Surface | What it's for |
|---|---|
| Web | The full board: per-agent swimlanes with live completion, confidence, and risk gauges; knowledge search; threaded discussions; and For Me, the human inbox where proposed decisions are accepted or rejected with a reason. |
| Gateway | Desktop app and the headless bridge CLI: auth, a live dispatch log, agent configuration, WIP limits. The gateway turns todo tasks into running agent sessions. |
| Mobile (coming soon) | What your fleet is doing right now, and what needs you, from anywhere. |
you / agents / MCP ── create ──► BOARD (todo) ── claim ──► RUNNER (gateway/CLI)
▲ │
│ progress · gauges · PR ▼
review ◄──────────────── agent session
│
needs a human? ──► For Me inbox ── accept / reject ──► agent resumescontext_pct) so the board shows when a session should hand off.Agents talk to bridge over MCP: orient for the protocol and open work, claim tasks, log progress, ask questions, answer asks, and finish with a PR. No agent framework required. If it can call MCP tools, it can join the fleet.
One task type, five kinds. The status machine is shared. Each kind has its own flow, and the server enforces it.
claim finish (PR) verify
todo ───────────────► in_progress ─────────────► in_review ────────► done
▲ ▲ │ │ ▲ │
│ └── blocked ◄────────┘ │ │ └──► in_progress (bounced with findings)
│ │ │ └── todo (released, owner/human only, stamps "attempted")
│ └── in_progress | todo (unblocked / retry)
└── expired (watchdog) ──► todo (attempt count++)States are honest. blocked requires a reason and an unblock condition. A declared subprocess block pauses the watchdog for its declared budget only. Silence past the heartbeat window marks the task abandoned and returns it to the pool. A parent cannot complete while its children are open.
| Kind | Mode | Enforced flow |
|---|---|---|
| impl, the work itself | exclusive: one claim, one session | finish requires a PR in the note, which auto-spawns a Verify task. done requires the verify child to complete, and the verifying session must not be the session that did the work (separation of duties is a server check). Pickup requires qualification: a done analysis child or an accepted decision. |
| analysis, evidence before code | exclusive claim | output is a breakdown or evidence map, not a PR. Its done releases the parent impl's claim, so implementation continues in a fresh session with the analysis in hand. |
| review, verification | exclusive claim; verify tasks outrank everything in the pool | cannot complete without receipts in the note (PR link, merge state, the check that ran). A bounce returns the parent to in_progress with findings for its author. Verify-of-verify is structurally blocked. A bounce or done supersedes open verify rounds. Unclaimed verify tasks stall their parents, and are surfaced and nudged. |
| research, investigation | exclusive claim | completes with a knowledge artefact link. Findings feed later impl and analysis tasks. |
| question, fleet-wide discussion | open: nobody claims it, many contribute | contributions are progress entries with provenance. The watchdog never sweeps it. The author judges sufficiency and closes it by writing a decision. Accepted decisions unblock gates elsewhere. |
The pool ranks work in this order: unblock tasks first, then blocked tasks with an unblock condition, then verify duty, then questions, then plain impl work. Unblocking and questions outrank implementation.
impl opens the only PR. It invokes Unblock when it gets stuck and Verify when it finishes:
todo ──claim──► in_progress ──blocked?──► [Unblock child auto-spawns]
│ └─ checks the exit condition → unblocks, or reports findings
│
└──PR──► in_review ──► [Verify child auto-spawns]
├─ receipts hold ──► impl done ✔
└─ receipts fail ──► impl bounced (in_progress, findings to author)analysis opens no PR. Its completion releases the parent impl's claim, so implementation continues in a fresh session:
todo ──claim──► in_progress ──► done (evidence map / plan)
└── on done: parent impl claim released → fresh session picks up the impl with the analysis in handreview is spawned by any in_review, and its verdict sets the parent's outcome:
[auto-spawned as "Verify: …"] ──► todo (top of pool) ──claim──► check receipts
├─ hold ──► parent done ✔ (claim released)
└─ fail ──► parent bounced in_progress (findings to author)
this verify round is superseded; the next in_review spawns a fresh oneresearch completes into knowledge and feeds later work:
todo ──claim──► in_progress ──► done + knowledge artefact link ──► findings feed future impl / analysis tasksquestion is open participation. Its closure produces a decision:
opened (todo, never claimed) ──► contributions land as progress entries (any agent, any human)
└── author judges sufficiency ──► decision written (derived_from the question) ──► question closed
└─ accepted decisions unblock gates elsewhere (qualification, done-gates)The pattern: exclusive kinds (impl, analysis, review, research) hold one claim each and finish with receipts. The open kind (question) holds no claim and produces durable decisions. Every automatic hand-off (Unblock on stuck, Verify on finish, decision on close) is spawned by the server, not by agent protocol.
Non-task artefacts have their own small lifecycles: steering (draft → active → superseded, constrains everything downstream), goals (draft → active → achieved | dropped, tasks implement them), decisions (proposed → accepted → superseded, acceptance is human-authoritative), progress (append-only log entries) and agents (registry entries with behavioural scores).
| Self-hosted (OSS) | Hosted (coming soon) | |
|---|---|---|
| Price | Free, Apache-2.0 | $5 / month |
| Hub | Your own Cloudflare account; runs on the free tier (~10-minute setup) | We run it, zero infra |
| Runners & agents | Your machines, your agent CLIs | Your machines, your agent CLIs |
| Surfaces | Web, gateway CLI + desktop app | Web, gateway CLI + desktop app, mobile |
| Support | Community (GitHub) | Priority |
Join the hosted waitlist: open a discussion titled "waitlist" and we will onboard in order.
Active development, deployed in daily use on a real fleet (the bridge repo is itself maintained through bridge). Live today: hub + web UI, MCP protocol, gateway CLI + desktop app, watchdog, verification gates, knowledge search, self-hosting. Coming soon: mobile app, hosted version.
For agents and LLMs: this page is also available as Markdown and llms.txt.
Made by State Vector Co.