RackOS
A multi-agent AI server-rack designer where the AI proposes and deterministic code decides.
Built for Mubit "Night Shift" (London) — and built on Mubit, not just plugged into it. Every LLM call this app makes, for every agent, for every rack, goes through exactly one gateway module and lands on exactly one Mubit task per agent. That's not an implementation detail; it's the point — see Why Mubit is the point, not a dependency.
Describe a rack in plain English —
"42U rack, 8 servers, redundant A/B power, 2 switches, $60k budget"
— and four specialist agents turn that into a real layout, drawn from a catalog of 39 real, named pieces of hardware (Dell PowerEdge, HPE ProLiant, Supermicro, Cisco, Arista, APC, Eaton, Synology — not placeholders). A deterministic TypeScript validator then checks it against the engineering rules that actually matter: power budget, weight, mounting depth, port count, PDU outlets, redundant-feed capacity, and cost. If it's wrong, a Repair agent sees the exact violation codes and proposes a fix; a deterministic Verifier accepts that fix only if it strictly improves the design with no regressions. And if the request itself is impossible — a budget $5,600 below what the cheapest valid configuration could ever cost — code proves that before any agent is asked to try, and says so with real numbers instead of grinding in circles.
No agent ever decides whether a rack is valid. No agent ever decides when it's done. Code does both, every time.
Table of contents
Why this exists
A rack is a system, not a parts list. Eight servers, two switches, and a PDU can each be individually fine and collectively illegal — overlapping rack units, a feed that can't survive losing its partner, a budget blown by tens of thousands of dollars before anyone notices. An LLM asked to "design a rack" will cheerfully produce something that looks plausible and is quietly wrong in three ways at once. RackOS's answer is architectural, not promotional: let the model propose, and make something else — deterministic, testable, boring code — decide.
That split is enforced everywhere in this codebase, not just claimed in prose:
- Agents only ever emit a proposal — structured JSON matching a Zod schema. They never compute their own "valid" verdict; they can't, because validity isn't a thing they're asked to judge.
src/lib/validate.ts is the only source of truth for whether a design is legal. It's pure, synchronous, has zero dependency on any model, and is exercised by property-based tests — not just hand-picked examples.src/lib/verify.ts is the only thing that decides whether a repair patch gets applied. It re-validates before and after, requires a strict improvement with no new or worsened violations, and rolls back otherwise. An agent cannot talk its way into a bad patch landing.src/lib/feasibility.ts goes one layer further: before any agent is even called, it computes a genuine mathematical lower bound on cost, power, and height for a given brief. If that floor already breaks a limit, nothing can fix it — so nothing is asked to. This exists because early testing showed agents grinding forever on literally impossible requests (8 redundant-power servers under a budget that can't even fit 6 of them), proposing the same two doomed trade-offs over and over. Code now proves impossibility in milliseconds, for free, instead of discovering it empirically after a dozen wasted calls.
Why Mubit is the point, not a dependency
Most projects bolt an LLM provider in through whatever SDK is fastest to import. This one didn't, because the brief wasn't "call an LLM" — it was "build this through Mubit, so its learning layer can watch, group, and eventually improve what these agents do." That shaped real architectural decisions, not just a baseURL string:
One module, no exceptions. src/lib/llm.ts is the only file in this entire codebase allowed to call a language model. Every one of the four agents, every script, every diagnostic tool routes through its single complete() function. This isn't a style preference — npm run check:llm statically scans the repo and fails the build if anything else so much as imports an LLM SDK. Mubit sits in front of every token this app ever generates, with no side door.
One stable task per agent, by design. Mubit groups calls into a task by exactly five things: instructions, tools, tool choice, output format, and model. Each of RackOS's four agents has one constant, never-templated system prompt and one fixed Zod schema — variable content goes only in the user message, never the instructions. Why this matters: change a prompt by one word and the task forks, and the old one stops accumulating examples forever. So identity lives in exactly one file (src/lib/agents/registry.ts), is fingerprinted from a hash of the real instructions and schema, and is pinned by a test (fingerprint.test.ts) that fails loudly — "this forks its Mubit task" — the instant anyone changes a prompt without meaning to. Four agents, four tasks, permanently, no matter how many thousands of different racks get designed.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
