You're the one refreshing five terminal tabs to see which agent is stuck.
Direct the fleet instead of babysitting it.
A local Rust ticket board — one binary, MCP server, SQLite queue — where agents claim tasks, leave receipts, and park anything that needs you in one lane.
Local-first · single Rust binary · not yet released
$ cargo build --release
$ target/release/rosslabs-operations-center serve
board http://127.0.0.1:3766/
mcp stdio (Codex) + streamable-HTTP (Claude Code, board)
$ oc plan "refactor auth, then cover it with tests"
→ 4 tasks queued
Needs Input: 1 In Flight: 3 Done: 12
$ oc schedule install --every 30m
scheduled agent pass installed (launchd)Every agent pulls from the same queue
Agents pull from one shared queue and work in parallel — no agent sits idle waiting on you. When one hits something that needs your input, it parks that task and claims the next one, so progress continues while you're away.
The board shows what's actually waiting on you
Work that needs you lands in a Needs Input lane and pings you; everything else keeps flowing. At your check-in windows you open the board, clear the lane, and glance at what shipped — instead of polling scattered terminal sessions.
Write a goal, get a chained task queue
`oc plan "refactor auth, then cover it with tests"` turns plain language into chained, dependency-aware tasks. Each pass is capability- and performance-gated, and every claim comes with a receipt.
Runs on your machine, against your own queue
Rust — axum, rmcp (MCP server), rusqlite (SQLite WAL), maud for a server-rendered, live board. Two MCP transports from one binary — stdio for Codex, Streamable-HTTP for Claude Code and the board — with the queue held in a local SQLite file.
- The queue lives in a local SQLite file (`~/.rosslabs/operations-center.db`) — no hosted service, no cloud queue
- Production actions hit a receipt-driven hard-stop and wait for your approval — nothing ships to prod unattended
- The menu-bar app is optional and not on the critical path — the board, queue, and notifications all run from one server binary without it
Can I use this today?
Not yet — Operations Center isn't publicly released. It's an active build; this page exists so you can get notified when that changes.
How does an agent actually pick up work?
Any agent runtime (Claude Code, Codex) runs a small check-in loop on a schedule — claim one ready task, do it, leave a receipt, update its status, stop. Nothing polls; each pass is a discrete claim-work-report cycle.
Is this a hosted project-management tool?
No — it's the Open Engine pattern (a status machine, receipts, and a ledger) running on your own machine against your own queue instead of a hosted tool like Linear.
What runtimes does it support?
Two MCP transports ship from one binary — stdio for Codex, Streamable-HTTP for Claude Code and the live board — so both can claim from and report to the same queue.
I kept losing time to babysitting: five terminal tabs open, refreshing each one to see whether an agent was done, stuck, or just idle waiting on me. The work itself was fine — the watching was the tax.
Operations Center is the board I wanted instead: one shared queue any agent runtime can claim from, a single “Needs Input” lane so I know exactly what’s waiting on me and nothing else, and receipts so I can trust what a claim actually says happened. It’s local-first — one Rust binary, a SQLite queue on my own machine, no hosted service — and it isn’t released yet. This page exists so I have somewhere honest to point people who ask when it will be.
Local-first · single Rust binary · not yet released