The shape of the company

A company is not a pile of agents. It is a small number of roles with clear boundaries, and a shared memory that lets them work without a human relaying messages between them.

The layers

• Owner (board). Sets direction, approves decisions. The only human. Reads briefs, signs off on a short list.
• Orchestrator (the lead). Reads the wiki, plans the day, hands work to departments, writes the brief. It coordinates. It does not produce.
• Departments (the workers). Data, outreach, content, growth. Each owns a slice of the existing scripts and writes a summary of what it did.
• Safeguards (the reviewers). Quality, security, privacy, content. They produce nothing. They review what the departments made before it is allowed through a gate.
• The wiki (the memory). Beside all of them. Everyone reads and writes it.

The cortex layer

The wiki is what makes the rest possible. An agent that wakes on a schedule remembers nothing from yesterday except what is written down, so the wiki is its memory, not a convenience. It does four jobs at once: it holds memory between runs, it is the bus the departments coordinate through (one writes a summary, the next reads it), it is the audit trail for every decision and action, and it is where cross-project learnings accumulate.

It keeps three things apart: state (what is live right now), knowledge (what is durable), and interface (briefs, decision cards, conversation). It is not the code and not the data. Those stay in the project repositories. The wiki is the layer of meaning about the projects.

The daily loop

The scheduler wakes the orchestrator. It reads the wiki and each project's health and writes a work list. The departments run and each leaves a summary. Anything low risk runs and is logged. Anything above a risk line is held back as a decision card and waits for me. The orchestrator writes the brief: what ran, what shipped, what is waiting, where the numbers sit against target. I read it, I approve or reject, and approvals are released on the next pass.

Decisions are executable specs

A decision is not a yes or a no. Each card carries the exact action it will take. When I approve, the agent runs the relevant safeguards one more time, executes, then verifies the thing actually happened (a deploy is not finished because the push succeeded, it is finished because the live version matches what was pushed), writes the result back, and rolls itself back if the check fails. Most cards arrive already carrying machine-checkable evidence, which is what lets the safe ones pass without me and the rest arrive pre-vetted.

Safeguards are the gate, and the gate is what buys autonomy

The reviewers are wired to the gates they guard. A privacy or security failure blocks the action and forces an explicit override. A style nit is advisory and fixed where it is safe to fix. The relationship between autonomy and safeguarding is not a tension, it is the same thing seen twice: the more trustworthy the automatic review, the more I can hand off. Trust is earned per department, not granted at once. Each one starts by only proposing, and earns the right to act through a track record the wiki keeps.

Built from parts that already exist

None of this is invented from scratch. The autonomy gradient (start by proposing, earn the right to act) is a pattern I already use. So is the model where departments are shared capabilities and a new project is a pointer plus a one-page charter, not a rebuild. So is the optimization loop the first department runs: propose a change, measure it against one number, keep it only if it improved. The company is the assembly, not the parts.