How our company wiki writes itself
A company wiki stays current when something other than a person maintains it. Ours runs on five pieces: markdown files with an index, three access scopes, one home per artifact, ingestion that turns email, Slack, meetings and CRM into durable facts, and a nightly pass that consolidates the lot while we sleep.
Why does every company wiki go out of date?
A company wiki goes out of date because keeping it current is nobody's job. Open yours. Check the last edited date on the ten pages you would send a new hire.
Every company I have worked at had this page. Somebody spends a week writing it, a few people keep it current for a quarter, then a launch lands and nobody opens it again. The next person to read it follows a step for a service that got replaced months ago, and from then on they ask a human instead.
Nobody decided to abandon it. Updating a wiki sits below every other task, forever, for everyone.
What does a wiki that maintains itself look like?
A wiki that maintains itself looks like a change history where most of the lines were not typed by a person. That screenshot is ours. Every line ends with the AI session that wrote the change, not the person who asked for it. In the last fifteen days our shared knowledge base took 1,817 markdown writes across 807 distinct pages. Agent sessions account for 1,264 of them.
Eight people work here. Nobody sat down to maintain any of this.
You can check the same numbers on your own store in one command once the pieces below exist. I care about that more than the numbers themselves, because a claim you cannot reproduce is marketing.
How did John Locke solve this in 1685?
In 1652 a student at Oxford started keeping a notebook. He copied passages, arguments, recipes, medical notes. So did everyone else with an education. They called them commonplace books, and they had one flaw: you could write anything into them and never find it again.
Some people pre-assigned pages by topic. Ten for medicine, ten for law. Then they wasted nine of one and ran out of the other by March.
John Locke kept at this for twenty-five years. In 1685 he published the indexing scheme he had built for it.
Two facing pages, ruled into a grid. A row per letter, five vowels across each row. To file something, take the subject heading, take its first letter and the first vowel that follows, and go to that cell.
"Epistola" gives you E and i. Go to cell E-i. If a page number sits there, that subject already lives on that page, so keep writing. If the cell is empty, start on the next blank page and write its number into the cell.
That is the entire invention. No topic gets reserved space. Everything grows to whatever size it needs. Any entry comes back by a rule instead of by memory.
Universities across Europe taught the method. It held for two hundred years.
Why doesn't a second brain scale to a team?
Locke died in 1704. His method survived him by three centuries. His own commonplace book survived him by zero days, because the moment he stopped writing into it, it stopped tracking anything. His papers sit in a library collection now, and nobody has added a line to them since.
You probably run something similar. Notion, Obsidian, a folder of notes that makes you faster. I keep one too. It works because you maintain it for yourself, which means it does nothing for the teammate who asks you the same question every month, and nothing at all for whoever replaces you.
A second brain makes one person smarter, and Locke reached that ceiling in 1685.
What are the five mechanisms?
A folder of markdown files, with an index
Our knowledge base is 574 markdown files in a folder. No database, no vendor. You can open any page in any editor, and so can any AI tool you adopt next year.
One file at the root does what Locke's grid did. It lists every map, each map lists its pages, and each entry carries a line describing what sits inside. An agent reads that one file, learns what the company knows, then opens the three pages it needs instead of scanning 574.
Two scripts keep the structure honest. One regenerates the maps from the tree. The other checks that every page carries valid frontmatter, appears in exactly one map, and leaves no dangling links. It exits zero or it tells you what broke.
Three doors
Not everything belongs to everyone. We run three separate stores that sync independently: a personal space with 20 files, the team brain with 1,126, and a gated board space with 29. Finance, legal, and board material live behind the third door and never cross into the shared one.
Same structure inside each. Same index, same page format, same rules. Different membership.
Pages move between them on purpose. A draft starts in my personal space, and when the team needs it, it gets promoted. Traffic in the other direction stays locked.
One obvious home per artifact
The top level holds four folders: projects for work with an end date, areas for responsibilities you own indefinitely, resources for reference that stays useful, archive for finished work. Tiago Forte designed this for personal notes. We run it for a company.
Ask "where does this go" and one answer comes back. A new hire looking for the sales deck checks three folders and finds it.
One addition makes it work with agents. Every page opens with three lines: what type of thing it is, whether it still holds, and when it last changed. Humans read the folder structure. Agents read those three lines. Same file serves both.
We did not invent that part. It follows OKF, the Open Knowledge Format, which Google publishes: a vendor-neutral way of representing knowledge as plain markdown with YAML frontmatter, deliberately tied to no agent, framework, model provider, or serving system. A small set of required keys gets you interoperability, and you can add your own on top without breaking anything that reads the file.
Picking a published standard beats inventing one, for a reason that only shows up later. Your own schema is a second thing to maintain, and it locks your company's memory to whatever tool you happened to like this year. A format someone else specifies outlives the tool.
It fills itself
Nobody updates the brain by hand, because the work reaches it on its own.
Our email routine checks when it last ran, pulls what arrived since, and reads for four things: a decision, a commitment, a price, a deadline. It files each fact onto the page that owns it. It has run unattended since July.
The routine never archives the message. A line like "we committed to SSO by September 15" comes out of a thread of eleven emails. The thread stays in email. The meaning moves into the brain. Raw material and knowledge are different objects, and mixing them is how you end up with a search index instead of a wiki.
Slack, meetings, and CRM run the same shape. A meeting recording becomes the decision it produced and the owner it landed on, not a transcript nobody opens again.
It reorganizes itself overnight
Filling the brain leaves one problem. Knowledge rots. The plan changes, the price changes, somebody leaves, and every page that held in March holds a little less today. Locke handled this by recopying pages.
So the brain sleeps on it. Ingestion drops the day's raw material at 22:00. At 02:00 agents distill it into pages, resolve contradictions between pages that disagree, update the index, and flag the gaps worth chasing. At 08:00 the team opens a current brain.
The middle step carries the difficulty, and it is where we deliberately stopped short. When two pages disagree about a renewal date, the agent does not pick a winner. It marks the page for review and waits for a person. A system that resolves every contradiction on its own is a system that will confidently write down the wrong number, and you will not find out for a quarter.
Which parts of this actually run today?
- Markdown store, index, maps, lint scripts: Running
- Three scoped stores with independent membership: Running
- PARA structure and page frontmatter: Running since 2026-08-17
- Email ingestion, unattended: Running since July 2026
- Slack, meeting, and CRM ingestion: Running
- Nightly consolidation pass: Running
That is the whole system, and the order of that list is the useful part. We built it top to bottom, and every row depends on the ones above it. The store came first, and the nightly pass came last for a reason: a consolidation agent turned loose on an unstructured folder produces confident nonsense. Structure is what makes the automation safe.
What still belongs to humans: deciding which page is right when two disagree, and deciding what never gets written down at all. The brain flags both. It does not settle them.
Why does this work now and not ten years ago?
Commonplace books are three hundred and forty years old. PARA has been around a decade. None of the ideas in this post are new, which raises a fair question about why any of it works now.
Locke solved indexing in 1685. The bottleneck sat one step later: an index needs a librarian. Somebody has to file the new thing, notice that two pages contradict each other, and rewrite the page that stopped being true. That work is constant, boring, and belongs to no one's job description, so it does not happen, and the wiki dies.
For three centuries the only fix was paying a person, and no company below a certain size could justify the headcount. Your wiki is not dead because your team lacks discipline. It died because nobody could afford to keep it alive, and that arithmetic only recently stopped holding. An agent that already has the repository open can file a page as a side effect of the work it was doing anyway.
How do you start a company wiki this week?
You do not need agents for the first step, and starting without them will teach you whether the structure holds.
- Make one shared folder. Anywhere your team already syncs files.
- Create a file called `index.md`. This is the whole trick, and it comes before any content.
- List the ten things your team re-explains every month. Onboarding steps, the deploy process, why you chose the current database, what you promised your three largest customers. Write one line per item in the index.
- Write those ten pages. Two paragraphs each. Resist writing more.
- Put three lines at the top of every page: what it is, whether it still holds, when it last changed.
- Add four folders when ten pages become forty: projects, areas, resources, archive. Move each page into one.
You now have a company wiki with no AI in it, and the structure will hold whether or not you ever add one. Locke would recognize it.
The agent layer comes after. Point a coding agent at the folder, give it permission to write, and ask it to file what it learns during a session. Ours writes into a synced store called BearDrive so that every teammate's agent reads the same pages, and every change carries the session that made it. Start with one folder and one index.
Questions
- What is a company wiki?
- A shared, written record of what your company knows: process documentation, decisions and their reasons, customer commitments, and internal reference. It differs from a document folder by being organized for retrieval, so a specific answer comes back in seconds rather than requiring you to know which file to open.
- Why do company wikis go out of date?
- Maintenance has no owner. Writing a page is satisfying and takes an afternoon. Noticing six months later that page 34 contradicts page 71 is neither satisfying nor scheduled, so nobody does it. Wikis decay from missing maintenance rather than from missing content.
- Can AI write and maintain internal documentation?
- Yes, with limits worth stating. Agents working in a repository can write pages as a by-product of doing the work, and they hold a naming convention more consistently than people do. They should not resolve contradictions between two pages that disagree about a fact. Flag those for a human. Our own store took 1,817 writes in fifteen days, 1,264 of them from agent sessions.
- What is the difference between a company wiki and a second brain?
- Ownership and audience. A second brain serves one person and reflects how that person thinks, which is what makes it effective and also what makes it useless to anyone else. A company wiki has to stay legible to people who did not write it, including people who have not been hired yet.
- What is OKF, the Open Knowledge Format?
- A vendor-neutral specification from Google for representing knowledge as plain markdown files with YAML frontmatter. It is deliberately independent of any agent, framework, model provider, or serving system, so the same files stay readable as tools change. A small set of required keys provides interoperability, and documents can carry extra keys without breaking consumers. It also carries trust signals such as sources, verification status, and staleness, which is what lets an agent tell a current page from a stale one.
- Do I need special software to start a company wiki?
- No. Markdown files in a synced folder work, and plain files stay readable by whatever tools you adopt later. Software matters once you want agents writing into the same store as your teammates, because at that point you need change history and access scopes.
- What is a commonplace book?
- A notebook for copying passages and notes, standard among educated readers from the 1500s onward. John Locke published an indexing method for them in 1685: file each entry under its first letter and the first vowel that follows, so anything can be found again by rule. The idea underlies most modern note-taking systems.