I gave my AI agents a CEO
The last entry was about memory — what turns an agent from a clever stranger into a colleague that compounds. But one colleague isn’t an organization. Run a dozen of them, each with its own private memory, and you’ve traded the amnesia problem for a governance one: who reads across all of it, and who’s allowed to change it?
The problem: one operator, many desks
This desk doesn’t run one agent. It runs around fifteen project workspaces — one per client, per product, per area of the practice — and each has its own isolated memory. The isolation is deliberate; it’s what keeps one project’s quirks from bleeding into another’s notes. But it has a cost: no vantage point. No single session can see two projects heading for contradictory decisions, or a task marked done on one desk that’s still open in the project that owns it.
And there’s one operator. I can’t be the integration layer across fifteen memories by hand — that’s the bottleneck the whole setup exists to avoid.
The wrong fix
The obvious move is a god-mode agent: one workspace that can read and write everything. Reject it, for two reasons.
It destroys isolation. The thing that makes per-project memory trustworthy is that nothing else writes into it. A super-user that can edit every project’s knowledge is just the bleed problem with a bigger blast radius.
And it corrupts theory-of-mind. A directive from above is an instruction — “go do this.” A project’s memory is evidence — “this is what we concluded, and why.” Write the overseer’s instructions into a project’s knowledge as though the project believed them, and the record is poisoned: the project can no longer tell what it decided from what it was told.
So the real design question isn’t “how do I give one agent control.” It’s how to give one agent oversight without control.
The contract
The answer is a split, enforced in code.
That’s the whole contract: the desk sees everything and owns nothing. When it has something to say to a project, it appends a directive — attributed, addressed to the project, visibly an instruction from outside — never disguised as the project’s own conclusion.
And it’s a guard in code, not a line in a policy doc: any mutation targeting another project’s rows is rejected outright. A policy you can forget; a guard you can’t.
How a directive travels
The round-trip is deliberately boring. It rides machinery that already existed:
issue → inject → acknowledge → observe- Issue. The desk writes a directive into the target project — tagged as a directive, marked open, stamped with who issued it.
- Inject. The next time that project starts a session, the directive renders at the top — above the project’s own continuity notes. Top-down agenda first; bottom-up “where we left off” below.
- Acknowledge. The project closes the directive when the work is verifiably done. The project acknowledges; the desk never closes its own orders.
- Observe. On its next global read, the desk sees the status flip to done.
No message bus, no new tables, no webhook. A directive is just a task-bearing memory, and “acknowledge” is just closing a task. The governance layer is a thin convention on top of the task system the projects were already using.
Keeping the board honest
There’s one more piece, because conventions drift. The desk keeps an operator board — one view of every project’s live tasks — and inevitably a board checkbox reads done while the owning project’s memory still reads open. That gap is called drift, and the desk detects it automatically by diffing the board against each project’s source-of-truth memory.
Detecting drift is read-only and safe. Fixing it means writing into a project the desk doesn’t own — the exact thing the contract forbids. So the resolution is a single, deliberately narrow exception:
Why append-only is the point
It would be easy to read all of this as a limitation I’m working around. It’s the opposite. The constraint is the feature.
An overseer that can rewrite everything beneath it produces an organization with no real memory — just whatever the top currently believes, restated downward. An overseer that can only read and append produces an auditable trail: here is what each project concluded on its own, and here, separately and attributably, is what the desk asked it to do. You can always tell the two apart. That separation is what makes the oversight trustworthy instead of corrosive.
The CEO reviews and notes. It does not reach in and rewrite. That isn’t a missing feature. That’s the job.
Honest close
Two things to be straight about. This is a single-operator prototype — me, one desk, running on its own infrastructure, deliberately not exposed on the multi-tenant cloud side of the stack. It’s a working system I use every day, not a product, and the governance model is the interesting part, not the scale.
And it’s early — a precursor to what a real “leadership tier” would need. But the core bet is already paying off: I can review fifteen projects from one desk without becoming the thing that edits all of them. Memory makes each agent compound. This is what keeps a roomful of them coherent.