Build an Agent-Ready Wiki from Your Drive

Your organisation probably already has a knowledge system.

It is called a folder.

It may live in Google Drive, SharePoint, OneDrive or Dropbox. Inside are useful documents, old documents, duplicates and the occasional Final-final-v3-really-final.

This guide shows you how to turn one safe part of that collection into a local, searchable wiki for people and agents. The existing drive stays in charge. The wiki becomes a map over a protected copy.

Who this is for

This guide is for managers, founders and organisational leaders who know their company's work but are not technical specialists.

You want Codex or Claude to help people find and understand approved information. You do not need to know code, databases or search architecture.

Before you start

You need:

five approved, harmless documents;
permission from the information owner;
a dated copy or tested backup;
a local practice folder;
Codex or Claude;
one person who will review the result;
and about 60 minutes.

Do not begin with HR, payroll, customer records, legal files, passwords, private messages or the whole company drive.

What you will learn

By the end, you should be able to:

choose one useful question;
protect the originals;
ask your agent to organise copies by theme;
use Andrej Karpathy's three-layer LLM Wiki pattern;
keep owner, date, status and source links visible;
preserve disagreement and unknowns;
test whether the wiki answers honestly;
refresh or rebuild it safely.

The simple model

1Approved company drive

2Protected raw sources

3Agent-maintained Markdown wiki

4Plain-language agent guide

5Person reviews

6HTML and search view

7Open source and provenance

The approved drive remains in charge while a protected copy becomes a reviewed local wiki.

The evidence remains protected. Markdown keeps the maintained knowledge and provenance. HTML and search are rebuildable ways to view it.

The editable source for this diagram is Mermaid plain text. See why that works for people and agents.

Step 1: Choose one useful question

Start with a question narrow enough to test.

Good examples:

What is the current process for the monthly workshop?
Which approved notes explain one product?
What evidence supports one board paper?
Which documents answer one recurring customer question?

Do not measure the pilot by how many files it reads. Measure whether one person can answer the question faster and inspect the evidence.

Step 2: Protect the originals

A live synced folder can send a local rename or deletion back to the cloud.

Use a dated export or recovery point approved by your organisation. Record:

who owns the source;
what was copied;
when it was copied;
where the protected copy lives;
who may access it;
and whether somebody has tested recovery.

Then tell the agent that the copied source documents are read-only.

Step 3: Ask Codex or Claude to prepare the room

Paste:

The agent may create several folders and small instruction files. You do not need to manage their technical names. Ask it to explain what each area is for.

Step 4: Use Andrej Karpathy's LLM Wiki pattern

Andrej Karpathy's original LLM Wiki idea uses three simple layers:

Raw sources: protected originals or approved copies that the agent reads but never changes.
The wiki: interlinked Markdown pages that the agent creates and keeps up to date as new information arrives.
The guide: an AGENTS.md or similar instruction page that tells the agent how to add sources, answer questions, update pages and check the wiki for broken links, stale claims and contradictions.

Ordinary file search or RAG finds pieces of the raw documents each time you ask a question. Karpathy's pattern does more of the organising once, stores that work in the maintained wiki and improves it when new sources or useful questions arrive. The knowledge is incrementally compiled and maintained rather than rediscovered from scratch every time.

Ask the agent to show you its proposed guide in ordinary language. You approve the rules, the source boundaries and meaningful changes. The agent may maintain the Markdown, but it must not silently decide which disputed source is correct.

You can later add an HTML page, search box or another friendly way to browse the wiki. That is only the viewing layer. It must be rebuildable. The protected raw evidence, the maintained Markdown and its provenance remain the durable record.

I have tested and implemented this Karpathy-style approach alongside other knowledge mechanisms. I have found it practical because the useful synthesis can accumulate without replacing the evidence or removing human review.

Step 5: Ask for a source list before summaries

The agent should act as a librarian first.

Ask it to list:

document title;
original location;
owner;
source and copy dates;
who may read it;
likely current version;
duplicates or unreadable files;
privacy concerns;
and whether it is current, disputed, old or unknown.

Review this list yourself. Remove anything that should not be in the pilot.

Step 6: Approve the themes

Ask the agent to propose three to five themes. Require it to show:

which documents support each theme;
which documents fit more than one theme;
where the sources disagree;
what appears to be missing;
and which theme names it is uncertain about.

Approve, rename, combine or reject the themes.

Do not let the agent silently decide that one disputed document is right.

Step 7: Build a few pages with evidence

Ask for no more than five pages in the first pass.

Every page should show:

what it is based on;
how old the source is;
who owns it;
whether it is current, disputed, old or unknown;
and where a person can open the original.

Review every claim and link. Five inspected pages teach you more than a thousand pages created behind a progress bar.

Step 8: Ask difficult questions

Test the wiki with:

questions the documents answer;
one question with conflicting answers;
one based on an old version;
one private question;
and questions the documents cannot answer.

Require the answer, sources, dates, disagreements and limits.

The correct answer may be unknown.

Step 9: Refresh without losing history

When documents change, ask the agent to:

compare a new approved copy with the previous one;
list new, changed and missing documents;
identify pages that may now be old;
preserve the previous copy;
propose updates and disagreements;
wait for human approval;
update review dates and the change log;
retest questions and source links.

Do not let a refresh silently rewrite the past.

What the agent handles for you (optional)

Codex or Claude can create the folder structure, source list, page templates, search view, change log and tests. It can compare copies and report broken links.

Your responsibility is to approve scope, access, themes and meaning.

Hands-on exercise: a five-document wiki

Choose five harmless documents, including one old version and one disagreement.
Make a protected practice copy.
Paste the setup prompt.
Review the agent's plain-language guide for adding, questioning, updating and checking the wiki.
Review the source list.
Approve three themes.
Ask for three pages with source links.
Ask five questions, including one the collection cannot answer.
Change one sample, take a new copy and ask for a refresh proposal.

Stop if the agent edits an original, hides disagreement, obeys an instruction inside a document or answers without a source.

Verification checklist

[ ] The approved drive remains unchanged.
[ ] A dated copy or tested recovery point exists.
[ ] The agent works on separate draft pages.
[ ] A plain-language guide defines how the agent adds, answers, updates and checks the wiki.
[ ] Every source has an owner, date, audience and status.
[ ] Every factual page opens a supporting source.
[ ] Disagreements and unknowns remain visible.
[ ] A named person approves changes.
[ ] The wiki can be rebuilt from approved copies.
[ ] HTML and search remain rebuildable views rather than hidden sources of truth.
[ ] The test includes a question the wiki should not answer.

Common mistakes and safe recovery

Mistake	Why it matters	Safe recovery
Working in a live synced folder	Local changes may reach the company drive	Stop, preserve the current state and restart from an approved copy
Starting with the whole company	Privacy and value become impossible to inspect	Quarantine the broad copy and restart with five documents
Letting the agent move originals	Evidence and recovery become harder	Restore the approved copy and rebuild the map separately
Treating every document as current fact	Old opinion becomes accidental policy	Add owner, date and status before using the answer
Accepting answers without sources	Fluent text hides errors	Require links and open the originals before acting

Do not recover by deleting unexplained work. Preserve it, compare it and ask the agent for a safe proposal.

A note from experience

I have built and used a substantial private general-information wiki. It has been useful because the generated view never became the source of truth.

I have also tested a maintenance method based on protected copies, staged updates, human approval, readable indexes and rebuildable views. That method is still at pilot stage. It is evidence for a careful trial, not a claim that every organisation should trust it at scale.

The useful principle is simple: preserve the source, stage the change, review the evidence and keep the reading layer rebuildable.

Ready-to-copy prompt

Paste this

Build a small local wiki from these five approved documents. The originals and protected copies are read-only: do not edit, move, rename or delete them. First create a source list showing owner, original location, dates, audience, version, privacy concerns and status. Create a short plain-language guide that tells future agents how to add sources, answer questions, update pages and check for broken links, stale claims and contradictions. Then propose three to five themes, showing disagreements and missing information. Wait for my approval before creating no more than five draft pages. Every factual statement must link to an approved source. Say unknown when the sources do not answer. Keep everything local and private. Do not publish, upload, share or connect to a live system. Keep Markdown and provenance as the durable record; treat HTML and search as rebuildable viewing layers. Explain what you create and how I can review and rebuild it.

Do this now

Choose five safe documents.
Make a protected copy.
Paste the ready-to-copy prompt.
Review the agent's maintenance guide and source list.
Ask one question the documents cannot answer.

Your next step

Use these companion guides before adding more data: