We built a self-growing organizational knowledge asset (an LLM wiki).
An autonomous agent that organizes scattered files & mail, grows them into a wiki, and answers from that wiki
It is not a tool that digs through everything from scratch on every search. It settles what it reads into wiki pages, appends new material to the existing wiki as it arrives, and accumulates the wiki into a lasting organizational knowledge asset — closer to a knowledge librarian that gets smarter over time.
One major thread in recent AI is the autonomous agent (agentic system). Give it a goal and it picks its own tools, decides, and asks back when stuck — the flagship being the general-purpose autonomous agent OpenClaw.
Knowclaw (Knowledge + Claw) takes OpenClaw's operating principle (a tool-use agent) as-is, but specializes it for one job: organizational knowledge management.
Most document Q&A re-searches the source on every question (RAG) — Knowclaw accumulates a wiki.
Classifies scattered Drive files & mail by project and moves them into real folders.
Reads the source to write person, concept, and summary pages, and accrues new material onto the existing wiki.
As material piles up, the wiki thickens and answers grow more accurate.
Karpathy's "LLM Wiki" pattern — instead of re-searching every time, the LLM incrementally builds and maintains a wiki as a lasting asset.
| RAG (retrieval-augmented) | Knowclaw (LLM wiki) | |
|---|---|---|
| Form of knowledge | Raw source-chunk embeddings | Wiki pages refined & structured by the LLM |
| Handling a question | Re-searches the source each time | Answers from the accumulated wiki |
| New material | Just adds chunks to the index | Incrementally integrated & linked into the wiki |
| Over time | Index only grows (quality unchanged) | The wiki thickens and quality rises |
Wiki bodies stay in markdown, while storage, queries, and web rendering use Django DB models.
Whether run as a manual sync or a daily cron, it uses the same orchestrator (run_full_sync).
| Stage | Module | What it does |
|---|---|---|
| 📥 Collect | drive_sync | Recursively scans project folders → diffs only changes → extracts text → upserts DriveFile |
| 🗂 Organize | classifier_agent → drive_organizer | Agent designs the taxonomy & placement (plan) → a deterministic executor performs the actual Drive move |
| 📚 Wikify | wiki_agent | Reads organized sources closely to create/update/link wiki pages (integrated across all projects) |
| 💬 Ask | wiki_qa | Natural-language QA grounded in the wiki (multi-turn + source citations) |
| email_archiver | Loads Gmail messages as files into project folders → reuses the same 4 stages |
We don't hand an irreversible action — moving a client's files — wholesale to on-the-fly LLM judgment.
Taxonomy design & category-assignment plans (classifier), wiki page authoring & linking (wiki_agent). All happen on the DB, so they can be undone anytime.
The actual move_file is performed by drive_organizer only through dry-run / apply / revert gates. The agent never holds this tool.
Not a hand-rolled while loop — they share a common builder (build_tool_loop_graph) borrowed from the popax/MeetingClaw pattern.
| Agent | Graph | Checkpointer | Tools (all reversible) |
|---|---|---|---|
| classifier_agent | Batch, once | None | list/read · propose/assign/merge category |
| wiki_agent | Batch, once | None | read source · read/write_wiki_page · link · search |
| wiki_qa | Multi-turn | PostgresSaver | search_wiki (embedding) · list · read_wiki_page |
make_sequential_tool_node runs the tool_calls of one response in order, eliminating "one value per step" state conflicts at the root. Batch work needs no checkpointer; only multi-turn QA persists session context.
Every move is logged to MoveLog → one revert restores it. Moves are confined below a designated root, deletion/trash calls are forbidden, and dry-run is the default.
"Files never cross projects." An active guard ensures the move destination is always the current project folder.
Only top-level scattered files are moved (already-organized subfolders are preserved). A once-moved file is auto-excluded from the next sync.
If classification confidence is low or unmatched, it isn't loaded — only logged. The email stage is isolated with try/except to protect the core sync.
It respects each client project's folder boundary. Even the same "contract" gets a separate category and folder per project.
Its value is greatest when answering cross-project questions ("what issues do A & B share?"), so the wiki is a single unified knowledge base spanning all projects.
Estimates that vary with volume of material and number of projects.
| Task | Before (manual) | After (Knowclaw) | Effect |
|---|---|---|---|
| Classifying Drive files & tidying folders | Minutes each × dozens | Auto-classify & move | Nearly automated |
| Writing summary/organizing docs | 30–60 min per item | Auto wiki build | Major savings |
| "Where was that again?" searches | 5–15 min | One question + source citation | Major savings |
| Organizing & filing received mail | Minutes each | Auto-loaded into project folders | Nearly automated |
LangGraph (StateGraph · tool loop · PostgresSaver) · LangChain · LangSmith
Anthropic Claude (classify · wiki · QA) · multi-provider swappable
OpenAI text-embedding-3-small (1536 dims) + numpy cosine
Django 4.2 · DRF · gunicorn · PostgreSQL · psycopg 3
standarda-core (Drive · Gmail · Docs) · crontab daily auto-sync
Tokens & USD auto-logged per run. Prompt caching cuts repeated input to 0.1× (measured −36% on Nulldam)
Design principle — "plan by agent, execute by deterministic executor" · "only reversible actions to the LLM"
Once it grows to hundreds+ of pages, swap numpy cosine for pgvector.
Export the DB wiki to markdown files for external sharing & backup.
Let people review and re-classify low-confidence mail that was held from loading.
An organizational knowledge asset that gets smarter as material piles up