RossLabs Operations Center

The Problem

Directing a fleet of coding agents tends to collapse into babysitting: five terminal tabs open, each refreshed in turn to see whether an agent finished, stalled, or is just idle waiting on input. The work itself is fine — the watching is the tax. What’s missing is a single place that shows what actually needs a human, and nothing else.

What It Is

Operations Center is a local Rust ticket board built around a different workflow: plan the work once, let a fleet of coding agents execute it, and check in at set windows to approve, unblock, and review. Any agent runtime pulls from one shared queue and works in parallel, so no agent sits idle waiting on a person. When an agent hits something that needs input, it parks that task in a dedicated “Needs Input” lane and claims the next one — progress continues while the operator is away.

How It Works

Plain-language goals turn into a chained, dependency-aware task queue:

$ oc plan "refactor auth, then cover it with tests"
  → 4 tasks queued
  Needs Input: 1   In Flight: 3   Done: 12

Each pass is capability- and performance-gated, and every claim comes with a receipt — the record of what an agent actually did, not just a status flag. At check-in windows, the operator opens the board, clears the Needs Input lane, and glances at what shipped, instead of polling scattered terminal sessions. A scheduler can also install a recurring agent pass (e.g. oc schedule install --every 30m via launchd) so the queue keeps moving between check-ins.

Architecture

One binary, local-first: axum for the server, rmcp for the MCP server, rusqlite (SQLite WAL) for the queue, and maud for a server-rendered, live board. Two MCP transports ship from the same binary — stdio for Codex, Streamable-HTTP for Claude Code and the board — so both runtime types claim from and report to the same queue. The queue itself lives in a local SQLite file (~/.rosslabs/operations-center.db); there is no hosted service and no cloud queue. A menu-bar app is planned as an optional surface, not on the critical path — the board, queue, and notifications all run from the server binary without it.

Boundaries

Production actions hit a receipt-driven hard stop and wait for explicit approval — nothing ships to prod unattended. This is not a hosted project-management tool: it’s the Open Engine pattern (a status machine, receipts, and a ledger) running on a single machine against a local queue, not a service like Linear.

Results

⚠️ pre-release — no benchmark yet. Operations Center is an active build and is not publicly released; no throughput, latency, or concurrency figures have been measured or published. What’s documented above is architectural (queue design, transports, receipt gating), not a measured outcome.

Lessons

The receipt requirement and the single Needs Input lane are the two decisions the design center on: agents doing work without checkable evidence isn’t trustworthy at a glance, and a queue with no single “here’s what’s waiting on you” surface just becomes another set of tabs to poll.