The Sovereign Knowledge Compiler: Compile-Time Memory for Local-First AI Agents

Github Link to Project

Abstract

The original Sovereign Memory Bank (SMB) proposal argued that agent memory should be local and private rather than cloud-hosted. That argument still holds, but it undersells the more interesting claim buried inside it: memory doesn't have to be retrieved at all — it can be compiled. This revision keeps the local-first commitment but replaces the "documents → embeddings → vector store → agent query" pipeline with a compiler pipeline: raw material goes in once, expensive reasoning happens once, and the runtime does cheap lookups against a set of static, inspectable artifacts. This reframing turns out to track something already happening at the frontier — OpenAI's Agents SDK now ships a built-in Memory() capability that distills raw conversation into consolidated files across two explicit phases, and third-party memory layers like Mem0 and Hindsight are converging on the same "extract once, retrieve cheaply" shape. The difference is where the compiled artifacts live and who owns the compiler.

Compile, Don't Retrieve

Retrieval-augmented generation treats every query as an opportunity to re-derive meaning: embed the query, search a vector index, stuff the top-k chunks into context, and let the model re-reason over raw material it has never seen organized. That cost is paid on every single call. A compiler makes a different bet: pay the reasoning cost once, at ingestion time, and produce artifacts — summaries, entity graphs, FAQs, timelines, code examples — that the runtime can serve almost for free. This is the same trade a compiled language makes against an interpreted one, and it's a trade that gets more attractive, not less, as context windows grow and inference costs matter more at scale.

This distinction — pay once vs. pay per query — is the actual thesis. Local-first is a deployment property of the compiler; it isn't the compiler's reason for existing.

The Problem, Restated

The original framing was that cloud RAG threatens privacy and racks up API costs. Both are true, but the more precise architectural failure is that RAG conflates storage with cognition. A vector database is good at similarity search and bad at synthesis — it hands the model raw fragments and asks it to reconstruct understanding on every call, which is why RAG systems still hallucinate connections that a one-time pass of careful reasoning would have caught and recorded.

Notably, the frontier labs are already correcting for this, just not in a sovereign direction. OpenAI's April 2026 Agents SDK update ships a Memory() capability with an explicit two-phase pipeline: a "conversation extraction" phase that summarizes a completed run, followed by a "layout consolidation" phase where a separate agent reads the raw extracts and distills them into a persistent MEMORY.md. That is a compiler front-end and a compiler back-end, running on OpenAI's infrastructure, over your conversations. Mem0 and the newer entrant Hindsight do something structurally similar — Hindsight in particular runs four retrieval strategies (semantic, BM25, graph traversal, temporal) with cross-encoder reranking and entity resolution, explicitly positioning itself as "a memory engine, not a database." The industry has already accepted that raw vector similarity isn't enough and that some compilation step is necessary. The open question is who runs the compiler and where the compiled state lives.

Existing Approaches

The useful correction here is that "local vector DB" was never actually the missing piece — Mem0 already proves you can run a fully local stack (Ollama for extraction, Chroma or Qdrant for storage, nomic-embed-text for embeddings) with zero API keys. What's missing from that stack is the compilation step itself: none of the local-first options currently produce durable, versioned, inspectable artifacts the way OpenAI's hosted Memory() capability does. The gap isn't privacy vs. capability. It's that the capability worth having — compiled, structured memory — currently only exists in a form that isn't sovereign.

The Concept

The Sovereign Knowledge Compiler (SKC) treats an agent's accumulated experience — documents, conversations, decisions, code — as source material to be compiled, not a corpus to be searched. Compilation happens locally, once per unit of new material, and produces a layered set of artifacts that the runtime reads directly. There is no local-first constraint being bolted onto RAG here; local-first is simply what you get when the compiler and its output both live on the user's machine.

A Memory Hierarchy, Not a Single Store

Treating "memory" as one undifferentiated blob is the original proposal's biggest oversimplification. A compiler needs to know what kind of artifact it's producing:

• Episodic memory — raw conversations, actions, and decisions, kept as an append-only log (the compiler's source material, analogous to source code)
• Semantic memory — facts, entities, and relations extracted from episodic memory (the compiler's intermediate representation)
• Procedural memory — code, APIs, and reusable skills the agent has learned to invoke
• Working memory — the runtime scratchpad for a single session, discarded or folded back in after compilation
• Compiled memory — the actual build output: FAQs, entity graphs, timelines, summaries, generated documentation — what the runtime actually queries

This maps closely onto how OpenAI's SDK already separates ephemeral Session history (working/episodic) from the distilled MEMORY.md (compiled), which is a reasonable existence proof that the layering is worth keeping even outside a sovereign context.

Architecture

• Compiler Frontend (was: Memory Ingestion Layer) — parses and normalizes incoming material: documents, transcripts, tool outputs.
• Knowledge Compiler (was: Semantic Indexing Engine) — the expensive step. Runs a local model (e.g., a Llama or Qwen variant served through Ollama) once per batch of new material to extract entities, build or update the knowledge graph, and generate the compiled artifacts (summaries, FAQs, timelines).
• Runtime API (was: Agent Interface) — a thin FastAPI service that serves compiled artifacts to agents. No reasoning happens here; it's lookup, not inference.
• Privacy Guard — enforces what gets compiled, retained, or discarded, and gates anything leaving the device.

Incremental Compilation

A compiler that rebuilds everything from scratch on every new document isn't actually solving the "pay once" problem — it's just moving the RAG-style cost to ingestion time instead of query time. The SKC needs dependency-aware incremental builds: when a new document arrives, only the graph nodes, summaries, and FAQs it actually touches get regenerated; everything else stays untouched. This is the same problem build systems like Bazel or Make solve for source code, and the same discipline applies here — track which compiled artifacts depend on which source material, and invalidate narrowly.

Forgetting and Decay

A compiler that never prunes its output isn't sovereign, it's a hoarder. As episodic memory accumulates, the compiled layer needs a decay policy — not deleting raw source material by default, but demoting compiled artifacts that haven't been referenced or reinforced in a long time, and recursively summarizing older episodic memory into coarser semantic memory rather than keeping every session at full fidelity forever. This is a compaction problem more than a deletion problem: the goal is to keep the working set of compiled artifacts small and relevant, while raw episodic memory remains available for a full recompile if the decay policy turns out to have been too aggressive.

Conflict Resolution

Compiled artifacts will disagree with each other over time — a fact extracted from a March conversation may contradict one from June. Rather than silently overwriting, the Knowledge Compiler needs a lightweight truth-maintenance layer: each semantic-memory assertion carries provenance (which episodic memory it was compiled from) and a timestamp, and conflicting assertions are surfaced rather than resolved automatically wherever the disagreement changes what the agent would recommend. This is a smaller, more tractable version of the same entity-resolution problem Hindsight already implements over vector and graph retrieval — the difference is that here it happens once at compile time rather than being re-run on every query.

Cross-Device Sync

The original future-work section mentioned peer-to-peer memory sharing without naming a mechanism. CRDTs (Conflict-free Replicated Data Types) are the correct fit: libraries like Automerge and Yjs already let JSON-like documents merge automatically across devices with no central server, and newer Rust-based implementations like Loro push performance further while keeping the same conflict-free guarantee. Applied here, the compiled knowledge graph — not the raw episodic log — is the natural CRDT payload: it's smaller, it changes at compile time rather than continuously, and merge conflicts at that layer are exactly the conflicts the truth-maintenance layer above needs to handle anyway. Two devices compiling from different sessions can sync their compiled graphs without either device's data ever touching a central server.

Cold Start

An empty Knowledge Compiler is a compiler with no source material, not a broken one — the right move is not to pre-seed it with generic domain knowledge, which just gives the agent confident-sounding priors that weren't actually derived from anything true about the user. Better to let compiled memory start empty and grow strictly from episodic memory the agent has actually observed, while letting the agent be explicit with the user about what it doesn't yet know. Pre-seeding is reasonable for narrow, declared domains (importing an existing document corpus, for instance) but should be treated as a distinct, labeled compilation pass — not folded silently into the same memory the agent later presents as things it has "learned" about the user.

Implementation

1. Set up a local environment with Python, Ollama, and a local vector/graph store (Chroma or Qdrant).
2. Build the Compiler Frontend to parse and normalize source material from your chosen inputs.
3. Implement the Knowledge Compiler as a batch job: entity extraction, graph construction, and artifact generation (summaries, FAQs, timelines) against a local model.
4. Add dependency tracking so new material triggers incremental rebuilds, not full recompilation.
5. Expose the Runtime API as a FastAPI service serving only compiled artifacts — no live reasoning.
6. Layer in the Privacy Guard, decay policy, and provenance-tagged conflict resolution.
7. If cross-device sync is needed, sync the compiled graph via Automerge or Yjs rather than the raw episodic log.

Evaluation

The original draft reported specific accuracy, latency, and privacy-compliance numbers as though they came from a completed experiment. They didn't — no implementation has been built and benchmarked yet, and reporting fabricated figures would misrepresent this as empirical work rather than an architectural proposal. The honest version is a list of the dimensions worth measuring once a reference implementation exists:

These are the metrics that would actually validate the "compile once, retrieve cheaply" thesis. Until they're measured against a working system, they should be read as a proposed evaluation plan, not results.

Applications

• Personal knowledge management — a compiled, private second brain that grows from a user's own material rather than a static import.
• Enterprise, on-premise assistants — compiled artifacts can be reviewed and audited before an agent is allowed to act on them, which a live vector search can't offer.
• Multi-agent research — agents sharing a compiled graph (via CRDT sync) get consistent, provenance-tagged facts instead of independently re-deriving the same conclusions.

Future Work

• A reference implementation benchmarked against the evaluation dimensions above, replacing this proposal's placeholder numbers with real ones.
• Multi-agent access patterns where several agents read from and write to the same compiled graph under the conflict-resolution rules above.
• Exploring which parts of compilation genuinely need a local LLM pass versus cheaper deterministic extraction (regex, structured parsing) — not everything needs to be compiled by inference.

Conclusion

The strongest version of this idea isn't "private memory instead of cloud memory" — it's "compiled memory instead of retrieved memory," with local-first as a natural consequence rather than the headline. OpenAI's own Agents SDK now distills conversations into consolidated memory files, which is a useful signal that the industry already treats raw retrieval as insufficient. The sovereign version of that same insight keeps the compiler, the compiled state, and the decision about what gets forgotten or synced on the user's own devices.

References

• OpenAI, "The next evolution of the Agents SDK" (April 2026) — native sandbox execution and configurable Memory() capability
• OpenAI Agents SDK documentation, "Agent memory" — two-phase distillation (conversation extraction, layout consolidation)
• Mem0, "Give Your Local AI Agent Memory with Mem0" — fully local Ollama + Chroma/Qdrant memory stack
• Hindsight, "OpenAI Agents Forget Everything Between Runs" — multi-strategy retrieval and entity resolution as a memory engine
• Automerge and Yjs project documentation — CRDT-based local-first document sync
• doc-135: Sovereign Memory Bank: Autonomous Cognitive Memory for Agent Systems (original post this revises)

Next Steps

• Build the Knowledge Compiler as a standalone batch job before wiring up any agent runtime.
• Prototype incremental rebuild tracking on a small personal document corpus.
• Prototype CRDT sync of the compiled graph (not the raw episodic log) between two devices using Automerge.
• Replace the placeholder evaluation table with real measurements once the reference implementation exists.