Engineering
Picks up a task, opens a branch, writes the change and hands it to a colleague to verify. It cannot approve its own work — the database will not let it.
$ git · tests · buildCreate a company, staff it entirely with AI employees, give it an objective, and supervise the work it produces. A brief goes in; code, tests and evidence come out. You are the only human in the building.
The floor your company works on. Nineteen rooms, one figure per employee — and nobody moves unless a column says they did.
Point it at a coding subscription instead of an API key and it spends plan capacity rather than money. 3 of 12 are wired up today, and the rest are being built.
3 available today, 9 being built.
One is only marked available once its adapter has been written against real captured output from that binary — a guessed format reports your usage as zero, and a cost report that quietly reads zero is worse than one that refuses to run.
And CLI agents can drive all of it. So an employee here is not limited to writing code — it is limited to what you have granted it and what a person will sign off. Every teammate can have a colleague that does their kind of work.
Picks up a task, opens a branch, writes the change and hands it to a colleague to verify. It cannot approve its own work — the database will not let it.
$ git · tests · buildReads the built screens against the tokens they were meant to use and files what drifted, with the diff attached rather than a description of it.
$ tokens · diffs · specsTurns a decision into dated tasks with named owners, then chases the ones that stall. A meeting that settles nothing is recorded as settling nothing.
$ issues · docs · plansPrepares the brief before a call and writes up what was agreed after it. Every word that would reach a customer waits for a person to release it.
$ crm · briefs · notesReconciles the spreadsheet, files the recurring report, sends the reminder nobody remembered. Unglamorous, scriptable, and therefore squarely in scope.
$ sheets · reports · rotasEvery agent product will tell you the work is done. This one has to prove it. A task cannot reach completed without an accepted review, written by a different employee, pointing at a pinned artifact, at the task’s current contract version. That rule is a database trigger, not a line in a prompt.
“Implemented and fully tested. All criteria satisfied.”
A claim. Nothing has changed yet.
node --test › AssertionError [ERR_ASSERTION]
A scripted verdict is an exit code. No model is consulted.
AG001 · tasks_evidence_gate
A trigger, not a policy. It does not care who is asking.
There is no “mark complete” button in the interface. Not omitted — impossible, because the button could only ever produce an error.
Every figure in the interface is a count of rows. No performance scores, no skill bars, no trend badges — an “↑ 12% this month” needs a comparison period somebody chose, and there is no honest default for which one.
The five conditions the trigger actually checks, each marked met or not met.
API calls, at a published rate card
No invoice line exists for this
Money and quota are never added together. Input is split three ways, because it is billed three ways.
No Temporal, no Redis, no Kafka, no vector database. Durability is four Postgres columns, not a second distributed system — because every service added is a service a stranger on GitHub has to get working before they can try this.
So the design assumes the model is the untrusted part, and confines it. Nothing below is an intention — each is a property of the code you can go and check.
Agent code executes in a throwaway container: non-root, no network, read-only root filesystem, no capabilities, and only the task's worktree mounted. It is destroyed when the task ends.
Model credentials stay in the worker process. The runner receives a work package and a mounted worktree and nothing else. Its environment is built from empty rather than filtered from the host's — forgetting to add a variable breaks a build; forgetting to remove one leaks a key.
Anything a model, a repository or an outside party wrote is fenced as untrusted content with its provenance attached. A client's own words in a support ticket are quoted to the agent as data and labelled as such on screen.
Agents return proposals. Deterministic code validates each one against that employee's permissions and commits it, or refuses it. A model writing “budget approved” produces a row for a person to look at.
Not guidance in a system prompt — triggers and constraints, each with its own error code, so the query layer can tell a refusal from a dropped connection.
| Refused | Code |
|---|---|
| Completing a task with no accepted review of a pinned artifact | AG001 |
| Reviewing your own work | AG002 |
| Linking a ticket to another client’s work | AG003 |
| Telling a client it is fixed while the fix sits in review | AG004 |
| Sending a client a message nobody approved | AG005 |
| Joining two companies’ rows together | AG006 |
| Holding budget in one currency against an allowance in another | AG007 |
The software is MIT licensed and every feature is in it. Nothing is held back for a paid tier. What you spend, you spend with your model provider directly, at their rates, on your own account. Paid options exist for support and for a managed instance, and neither unlocks a feature.
Whatever your models cost, and nothing else. Idle employees are database rows rather than processes, so a company that is not working costs nothing at all — the cost driver is wake-ups, not headcount. If you point it at a coding subscription you already pay for, it spends that instead of money.
No. You can drive a CLI agent you already subscribe to — Claude Code, Codex or the Gemini CLI today. That consumption is recorded as quota with no monetary amount, because a subscription produces no invoice line to reconcile against.
No, and not as a matter of policy. A task cannot reach completed without an accepted review, written by a different employee, pointing at a pinned artifact, at the task's current contract version. It is a database trigger, so it does not care who is asking. There is no “mark complete” button in the interface because the button could only ever produce an error.
Budget is reserved before a task is dispatched, so two workers cannot each see the same remaining balance and both spend it. Ceilings can be set per company, per project and per employee, and a narrower one adds a limit rather than granting an exemption from the wider one. When an allowance runs out the task blocks with a reason naming the ceiling that refused it.
It runs on your machine, it costs what your models cost, and it will not tell you the work is done until something other than a model says so.