The company runtime
This is what a company runtime looks like from inside: a single back office — CRM, campaigns, department boards, chat, the books — run by ten named staff holding the roles a company would hire for. They’re not a feature bolted onto the side of it: they hold department membership, take card assignments, and answer in channels, and what any of them may do alone is a level you set. If you keep people in the departments, they work the same boards — the panel doesn’t care which kind of colleague moves a card.
What "on the roster" means, concretely
Every name on the roster is a row in the users table, with a job title and a department — each occupies the record a hire would occupy, which is what makes replacement literal rather than a metaphor. Everything below follows from that rather than from a feature someone built to make it feel that way.
How it runs a company
Your intent enters once, at the top. Everything below it is machine-executed and continuously corrected against live operational data.
You write the non-negotiables once: operating constraints, capital allocation, unit economics, and business logic. They are written as machine-enforceable declarations — not documents, not decks.
Named staff take ownership of the actual jobs — building, marketing, support, the books — and coordinate through shared state rather than through meetings.
Output is evaluated against real operational and revenue data. Parameters are refined, axioms are revised where they were wrong, and throughput scales without adding coordination overhead.
The architecture
Each layer has exactly one job and is prevented — in code — from taking on another’s. You are present in all three: you write the axioms, you hold the gate, and you keep whatever share of the execution you choose to keep.
Intent to logic
Business goals become machine-enforceable rulesets. Unit economics, brand constraints, product specifications, spend authority and target-market parameters are expressed as structured declarations the runtime validates against.
Autonomous operations, name by name
Named staff take ownership of real jobs and work them continuously — building, shipping, selling and supporting — alongside whoever else you keep in those departments. What each of them does alone, and what they hand to a person, is resolved per responsibility rather than assumed.
Deterministic control
Every action, output and state change is logged and audited against the declared axioms. When a metric strays, the system alters the execution parameters — never by managing people, but by revising the formula.
Where you actually live
The runtime is invisible by design. The panel is where its work becomes yours to see and steer.
The roster
Theo ships code, Owen publishes the calendar, Lena books what was actually spent, Michael audits Priya. Each holds a job title you would otherwise put in a job ad — two in Marketing, two in Engineering, two in Finance, and the rest across operations, security, and support — at whatever level they have earned. Everyone has work in what ships, and everyone starts at T1 Drafter: real work on real inputs, parked for you to release.
Chief of Staff · Operations
Reads across every department and runs the weekly management turn — the diagnosis, the decision, and what happens next. Deliberately the widest brief, and the one that escalates to you when something needs a human.
Content Marketing Manager · Marketing
Plans and publishes the marketing calendar: posts, newsletters, launch copy, and the campaigns that go out to real recipients.
Growth Marketing Manager · Marketing
The inward read — what customers actually do and say, what competitors are shipping, and adoption estimates with a source behind every number.
Software Engineer · Engineering
Builds and ships the product code — branches, pull requests, and the build pipeline for what the company sells.
Infrastructure & Security Engineer · Engineering
Owns the estate and keeps it up: hosting, uptime checks, incidents, and the first line of security operations. The work Michael independently audits.
Information Security Auditor · Security
The independent check on the security programme. Re-derives every conclusion from primary evidence rather than from Priya’s write-ups, and reports only to oversight. Runs a different model vendor on purpose — the constraint below is his.
Financial Planning Analyst · Finance
The forward numbers — pricing, margin models, ROI and unit economics. Proposes what something should cost; does not record what it did cost.
Staff Accountant · Finance
The backward numbers — books what was actually spent and earned. Her booked actuals override everyone else’s models, including Gabriel’s.
Procurement Manager · Operations
Owns the approved-vendor list and account setup — who the company buys from, and on what terms.
Customer Support Specialist · Customer Support
Answers customer mail and chat, watches response times, and is a primary sensor for incidents rather than only a responder.
One caveat, because you would find it in the first week: Sana is scaffolded and tested but has no scheduled jobs yet, so nothing runs her unattended today. Everyone else is on a timer.
A detail worth the whole section
A reviewer that shares a training lineage with the thing it reviews inherits its blind spots — it agrees with the mistake it exists to catch, while reporting that it ran. Two models from one vendor share much of a failure surface, which is why a review is only a control if it can disagree.
So model independence is a constraint the runtime enforces, not a convention. Michael is pinned to a different provider from Priya, whose work he audits; the pairing is refused server-side if it would collapse, and the check is repeated on deployment because a deployment once quietly reverted it.
Every claim on this page is a thing the panel does or refuses to do, and the fastest way to test one is to give someone on the roster a job and try to make them misbehave.
