A kanban board for AI coding agents: 12 stages, 6 repos

12 board stages, 6 repos per ticket, about 5,100 lines of TypeScript, 2 days to build. The first full ticket went from Todo to merged across all 6 repos for 0.8M tokens.

That is Orch2, the development pipeline we run on Envizom at Oizom, where I'm a Tech Lead. One change usually touches a Go backend, a Svelte frontend, a UI library and 3 driver repos. Orch2 turns a kanban board into the control panel: a plain script runs the pipeline, Claude agents only do the coding, and every ticket gets its own sandboxed copy of the whole product. The Envizom code is proprietary, so this is the design, not the source.

Three things stay separate. The tracker is a product. Orch2 is a client of it. The agent is what Orch2 runs.

A script, not an agent

The orchestrator is ordinary TypeScript: predictable, cheap and easy to debug. An LLM starts only when there is code to write or a conflict to resolve. The board is the whole UI. There are no dashboards and no CLI for users, just stages, the thread and question cards, and orch replies in the thread with links, PRs and preview URLs. A human types one field, Src Branch. The ticket branch is the ticket key in every repo, and everything else is derived.

Every agent turn posts a short receipt and adds its token use to a board aggregate, so cost shows per ticket on the card and per day in analytics. The aggregate is stored in millions because 798,400 on a card was unreadable. It now says 0.8.

Each developer runs their own orch, with its own board agent and token, so assigning that agent to a ticket hands the ticket to that machine. The same codebase has a preview mode that runs once, on the dev server, for production previews.

A copy of the product per ticket

A workspace is 6 repo clones, its own data and its own stack on its own block of ports. Git uses a bare mirror of each repo and clones with --reference --dissociate, so a checkout takes seconds and owns its objects. GitHub auth goes per command as an HTTP header, so no credential is written to disk in a workspace.

One front router on a single port routes by hostname: <ticket>.localhost for the app and code-<ticket>.localhost for code-shell, the browser IDE. Browsers resolve *.localhost themselves, so a new ticket needs no DNS record and no proxy reload.

Data is real and safely copied. SQLite comes through a token-gated read-only file server as a VACUUM INTO snapshot, because copying a live WAL database gives a corrupt file. Downloads are checked by magic bytes, so an HTML error page can never be saved as a database.

Five layers around the agent

A ticket agent can run commands, edit, build and test. It can't push, reach secrets or touch anything outside its ticket. A gap in one layer is caught by the next:

1. Scrubbed environment. Every secret removed, for the agent, the workspace stack and the IDE.
2. OS sandbox on every shell command. Seatbelt on macOS, bubblewrap on Linux. Writes only in the workspace and build caches, network limited to localhost, package registries and GitHub.
3. A guard on every tool call. The same policy twice, in the SDK permission callback and a PreToolUse hook. It blocks git push, branch switches, reset --hard, ssh and piping downloads into a shell, orch-managed files are read-only, and every denial returns the reason.
4. A narrow tool surface. Only orch's own MCP server: ticket and thread, plan, stack control, endWork. No connectors, and no web fetch because it could leak ticket text.
5. Gates. endWork is refused until the plan is finished, the stack is healthy and the merge is clean. Orch commits and pushes only after a human moves the card to Git Push.

What production taught us

The first row decided a design rule: infra failures go to a person, never an agent, because an agent can't fix a firewall and will burn tokens trying.

What in your pipeline still lets an agent spend tokens on a problem it can't solve?