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 exactly what keeps a client site’s quirks from bleeding into infrastructure notes. But isolation has a cost: there’s no vantage point. No single session can see whether two projects are about to make contradictory decisions, or whether something marked done on one desk is still open in the project that actually 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.” If the overseer’s instructions get written into a project’s knowledge as though the project believed them, the record is poisoned: the project can no longer tell what it decided for itself from what it was told to do.
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 CEO desk sees everything and owns nothing. When it has something to say to a project, it doesn’t reach in and change that project’s notes — it appends a labeled directive addressed to the project, stamped with who issued it. The directive is 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 that targets a project other than the desk’s own is rejected outright — the desk can only manage the rows it authored. 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 — it marks the task complete. 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 — a single view of every project’s live tasks. Inevitably a board checkbox reads done while the owning project’s memory still reads open. That gap has a name here: drift. The desk detects it automatically, comparing its board against each project’s source-of-truth memory and flagging every row where the two disagree.
Detecting drift is read-only and safe. Fixing it is the hard case, because 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:
Lifecycle hygiene is a legitimate thing for an overseer to do. Rewriting what a team knows is not. The exception is scoped precisely to that line, and no further.
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.