Compile Your Knowledge, Don't Retrieve It: Rethinking a new way for Agent Memory
There is something strange about how we use AI agents today, it has the memory of a goldfish and we've decided that's fine. Every question you ask, your AI re-reads the same documents, go to retriever to get same query which it asked 5 day ago, to re-figures-out how they connect, and forgets all of it the moment it answers — then does the whole thing again on the next question. It's slow, it's expensive, and it means a new coding agent is just as lost in your codebase on day 100 as it was on day 1. Meanwhile the company knowledge that actually matters — why you built things this way, what your customers keep telling you, the stuff living in one senior engineer's head — walks out the door the day they quit. We've been treating AI's forgetfulness as a quirk. It's actually the root of almost every context problem we complain about.
What is fix for this problem?
What if we have an AI agent read your raw data once, write a folder of markdown files summarising it, and let every future agent read the folder instead of the raw data?
Solution
Wiki -That's it. Markdown files. In a folder. But while working with multiple option like deepwiki Langchain solution , Open Knowledge Format by Google my mental model kept breaking and rebuilding. Below is the conclusion i got .
v 1 — This is just RAG with extra steps
We already have retrieval: chunk the docs, embed them, fetch relevant pieces at query time. A generated wiki looked like RAG that someone ran through a beautifier.
what is issue: what does retrieval actually accumulate?
Nothing. That's the answer. Ask a question that needs five documents synthesized together, and the model rebuilds that synthesis from scratch. Ask again tomorrow, it rebuilds it again. Pays for it again. Forgets it again. Your pipeline has perfect recall and zero learning.
The wiki approach does the synthesis once and writes it down. The cross-references exist before the question arrives. The contradictions between doc A and doc C were flagged at ingest time, not discovered mid-answer.
And the numbers back the intuition: published results from the agent-memory world show compressed, pre-processed context running at roughly ~7,000 tokens per query versus ~26,000 for stuffing everything into the window, with p95 latency dropping from ~17 seconds to ~1.4. (These are vendor benchmarks and vendors in this space actively feud over each other's numbers, so hold them loosely. The direction, though, nobody disputes.)
Conclusion: - "This isn't RAG with extra steps. It's RAG with a build step"
v2 — "But why we need into files format? cant we use database"
For enterprise knowledge after building but it in a vector store or in a graph database.
What is issue in it: I tried listing what plain files give you for free, and the list got increasing..
You can git diff a markdown file. You can review it in a pull request. You can read it in any editor, grep it, blame it, fork it, tar it, and hand it to literally any agent — Claude Code, Cursor, Copilot, Try any of that with an embedding. You can't code-review a vector.
Then Google published an open specification for this pattern — not a product, a spec. The entire required schema is one YAML field per document. It fits on a page. And it explicitly promises never to require a proprietary SDK to read or write.
When a company whose whole business is proprietary APIs ships a format anyone can implement in a text editor, they're not being generous. They're telling you where the moat isn't. The format layer(Semantic knowledge for your company) got commoditised.
Conclusion: "Files are the point. Knowledge as an artifacts you own, not a service you rent."
For enterprise knowledge after building but it in a vector store or in a graph database.
What is issue in it: I tried listing what plain files give you for free, and the list got increasing..
You can git diff a markdown file. You can review it in a pull request. You can read it in any editor, grep it, blame it, fork it, tar it, and hand it to literally any agent — Claude Code, Cursor, Copilot, Try any of that with an embedding. You can't code-review a vector.
Then Google published an open specification for this pattern — not a product, a spec. The entire required schema is one YAML field per document. It fits on a page. And it explicitly promises never to require a proprietary SDK to read or write.
When a company whose whole business is proprietary APIs ships a format anyone can implement in a text editor, they're not being generous. They're telling you where the moat isn't. The format layer(Semantic knowledge for your company) got commoditised.
Conclusion: F Files are the point. Knowledge as an artifact you own, not a service you rent.
v3 — "We tried wikis. Wikis rot. Everyone knows this"
Every company wiki I've ever touched was a archive of how the system worked three years ago. Confluence is where documentation goes to describe the past.
What is issue in it: Wikis die of bookkeeping — updating cross-references, reconciling the new page with the twelve old pages it contradicts, keeping the index honest. The maintenance burden compounds faster than the value, so humans rationally quit.
That' the problem language models are freakishly good at. Touching fifteen files in one pass to keep them consistent is miserable for a human and trivial for an agent. The new tooling already treats this as table stakes: docs regenerate on every push, diff against the last commit, only rebuild the pages the changes actually touched, open a PR with the update. Documentation as a build artifact, not a side project.
Conclusion: "Wiki rot wasn't a law of nature. It was a labor shortage, so LLM to synthesis enterprise wiki."
v4 — "So this is basically solved, then"
Its solved then but another things came.
What broke it ?
Many agents reading one artifact is the efficiency win. Many agents reading one wrong artifact is the blast radius. A bad RAG chunk misleads one query. A wrong wiki page misleads every agent, every session, silently, until a human notices — and the entire premise of the system is that humans read less.
Then it gets darker: a wiki is a persistence layer for prompt injection. Poison one ingested document, and the malicious content gets compiled into an authoritative-looking page that every future agent treats as ground truth. Measured injection success rates against agentic coding tools already run 50–80%.
The teams actually running this in production should follow this- lint the wiki on a timer (orphan pages, contradictions, stale claims). Every write goes through a PR; the serving layer is physically read-only. Bring Audit practice — every AI-generated page enters as unverified and can't be cited by other pages until checked against a primary source, because an unverified page citing another unverified page is circular evidence. The best security idea in this whole ecosystem is double-entry bookkeeping.
Conclusion: the pattern works, but only wrapped in trust machinery. The wiki is easy. The epistemics are the product.
Benefit of using this
- 1-The token economics
The wiki-memory literature doesn't publish head-to-head benchmarks yet, but the adjacent agent-memory field does, and it measures the same underlying effect: pre-compressing knowledge collapses per-query cost. Mem0's ECAI 2025 paper established the baseline against full-context; their April 2026 algorithm update moved it substantial
- 2 — Onboarding collapses
This is the benefit with the least marketing spin on it, because both vendors and the community independently reach for the same anecdote. Cognition opens with it shouldn't take hours to get up to speed on a new codebase. Understand-Anything opens with you just joined a new team. The codebase is 200,000 lines of code. Where do you even start? Factory reports that internally at Factory, AutoWiki saves engineers critical hours during codebase onboarding by turning each repository into a navigable system map, and frames the dual audience precisely: engineers and Droids share the same foundation to navigate a codebase and plan the next change.
- 3 — One knowledge layer, every tool
This is where the format argument pays off, and it's the strongest reason to prefer wiki memory over a vendor's memory service. Understand-Anything's graph is just JSON — commit it once, and teammates skip the pipeline, and once committed, anyone on the team can open it with one command — no Claude Code, no LLM, no API key. Only Node.js is required. Everything is served read-only from local disk — no LLM calls, no data leaves your machine. One expensive generation; unlimited free reads, by any tool, including humans.
- 4 — The maintenance argument (the real one)
- 5 — Provenance, inspection, and institutional memory
It's git file, you get the audit trail free. One practitioner running ~4,000 interlinked concepts in production reports: the wiki is just a private git repo, auto-synced. Teammates browse in Obsidian or hit the same MCP server. Git history doubles as the log.md audit trail for free.
What are different options:
Recommendation for companies:
If you're a startup
Run /understand or openwiki --init on your main repo. Commit the output. Wire it into AGENTS.md. Add the CI refresh. Then — and this is the part most teams skip — point the Karpathy pattern at your non-code knowledge: your competitive landscape, your customer-call notes, your architecture decisions. That's where the compounding actually shows up, because that's where nothing else is indexing it. Use a local model for the first big pass if token spend is a concern. Do not buy an enterprise catalog. You don't have an estate; you have a repo and some opinions.
If you're an enterprise
Invert the order. Governance before generation. The single most expensive mistake available to you is generating 40,000 pages of plausible AI documentation across your estate before deciding who owns it, who reviews it, what the trust grades mean, and what happens when a page is wrong. You will not be able to un-ring that bell; nobody will trust any of it.
Concretely: pick one high-pain domain (a warehouse subject area, one gnarly legacy service). Adopt OKF as your internal contract even if you also buy a catalog — it's your exit option, and it costs nothing. Enforce PR-gated writes and a read-only serving layer. Put verification status on every page. Then generate. Then roll horizontally.
If you're an Developer: Understand anything
Turn any code into an interactive knowledge graph you can explore, search, and ask questions about. Works with Claude Code, Codex, Cursor, Copilot, Gemini CLI, and more.
https://github.com/Egonex-AI/Understand-Anything
Sample github repo to explain this
https://github.com/neelampawar2026-ai/tokenomics-for-agents
