The wiki is the memory

An agent that wakes on a schedule is amnesiac by default. Every run is a cold start. It has the code in front of it and nothing else, no recollection of what it did yesterday, what it decided, or why. So the first thing the company needs is not a smarter agent. It is a place to remember. That place is the wiki, and treating it as documentation rather than memory is the mistake that quietly kills these systems.

Memory, not notes

The site's knowledge argument is that management is compilation, not filing: you turn captured noise into durable structure. The wiki is that argument applied to the company itself. It compiles what the company did into what the company knows, and it does it because the alternative is an agent that relearns its own situation from scratch every morning and gets it slightly wrong every time.

This is load-bearing. If the wiki is stale, the agent acts on a false picture and is confident about it. If the wiki is missing a fact, the agent invents one. The quality of the company is capped by the quality of its memory, which is why the wiki is the part I design first and guard hardest.

Three things kept apart

The wiki keeps state, knowledge, and interface in separate places, and the separation is the design, not housekeeping.

• State is what is true right now. Which vertical is live, which campaign is mid-flight, what the last deploy shipped. State is volatile and it expires.
• Knowledge is what stays true. The playbook, the lessons, the patterns that survive a project. Knowledge is durable and it compounds.
• Interface is where I meet the system. Briefs, decision cards, the running conversation. Interface is for a human to read.

Mix them and the system rots in a specific way: stale state gets read as durable knowledge, a one-off note hardens into a rule, and a draft meant for me gets treated as fact by the next agent. Keeping the three apart is what lets the agent trust what it reads.

The bus is a written summary

The departments do not talk to each other. One finishes its work and writes a summary to the wiki. The next reads that summary and starts. The hand-off is a durable document, not a live message.

This is deliberate. Agents passing messages directly is lossy and untraceable: the conversation evaporates and you cannot reconstruct why anything happened. A written summary is the opposite. It is asynchronous, so a department does not wait on another to be awake. It is durable, so the hand-off survives the run that produced it. And it is inspectable, so I can read the whole chain in five minutes and see exactly what each part claimed it did.

The audit trail is the safety mechanism

Every decision and every action is written to the wiki before or as it happens, not after. This is what makes autonomy safe rather than reckless. Nothing the company does is off the record. If an action surprises me, I can walk back through the trail and find the summary, the decision card, and the verdict that led to it. A system you cannot reconstruct is a system you cannot trust to run without you, so the trail is not a log I keep for tidiness. It is the precondition for handing off at all.

Compounding across projects

The last job the wiki does is the one that pays off slowest and matters most: a lesson learned once becomes available everywhere. A fix found while running the funeral vertical is written down once, and the senior care vertical inherits it for free. My directory portfolio already runs this way at the product layer, where a single compounding playbook makes each new vertical faster than the last. The wiki is that same mechanism for the operating layer, so the company gets better at running projects the more projects it runs.

The honest read

The failure mode is a wiki that rots: state that went stale and is still read as truth, structure that ossified into rules nobody meant to set. The defense is to design for neglect, to assume the wiki will be half-tended and make it degrade safely rather than silently. The open question I have not answered is how much structure is right. Too little and the agent cannot find what it needs. Too much and the structure itself becomes the work. I am building toward the least structure the company can run on, and I will only know the amount by watching where it breaks.