The Science Behind Borg
Borg's memory architecture is not an aesthetic choice. It is a response to how memory fails in LLM systems, and it is grounded in cognitive science, information retrieval, temporal data management, and database design.
The core claim is simple: LLM memory is not a search problem. It is a knowledge compilation problem.
The Core Problem
LLMs are stateless inference engines. Every call starts from zero, so the memory layer has to do more than retrieve text.
Common Approach
Naive RAG
Vector search over raw conversation logs.
Conversation chunks are noisy, context-dependent, and often stale. A chunk that says "we use Redis" becomes actively harmful after the team has moved to PostgreSQL. Without supersession, decay, or trust, retrieval becomes contamination.
Common Approach
Summarization Chains
Periodic summaries that get summarized again.
Lossy compression compounds. After a few passes you are left with clean, generic prose that sounds helpful but has lost the specific facts, edge cases, and decision rationale that matter during real work.
Why Borg Takes a Different Path
Each major design choice solves a real failure mode in LLM memory systems.
Scientific Anchor
Tulving's episodic and semantic memory model
Evidence-Grounded Memory
Borg treats conversations as episodic memory and extracted facts as semantic memory. The offline pipeline turns raw episodes into structured facts, procedures, and entities with provenance. That gives the system something it can compare, supersede, and rank instead of treating an old conversation chunk as permanent truth.
Scientific Anchor
Fellegi-Sunter record linkage theory
Prefer Fragmentation Over Collision
When entity resolution is uncertain, Borg would rather keep two references separate than merge the wrong things together. A false merge poisons every downstream fact. A temporary split is inconvenient, but recoverable. That tradeoff is the right one when the output feeds an LLM that will reason over bad context with confidence.
Scientific Anchor
Faceted retrieval and constrained ranking
Faceted Retrieval Under Budget
Borg does not bet everything on one ranked list. It retrieves across entities, facts, procedures, and snapshots, then applies memory-type weights per task and namespace. That makes context selection more robust when the real budget is not documents, but a few thousand tokens inside a model window.
Scientific Anchor
Bitemporal data management
Temporal Consistency Through Supersession
Facts in Borg have a lifecycle. They are not merely true or false. They are observed, current, superseded, or archived with valid time and recording time. That prevents the classic memory failure where a system retrieves both "Python 3.9" and "Python 3.12" with no attempt to resolve which one still applies.
Scientific Anchor
Lost in the Middle and resource-aware retrieval
Namespace Scoping and Token Budgets
LLMs do worse when useful context is diluted by unrelated material. Borg scopes memory by namespace before retrieval and applies configurable token budgets per namespace. Context is treated like a scarce runtime resource, not an infinite dump target.
Scientific Anchor
Consistency over system sprawl
PostgreSQL as the Source of Truth
pgvector covers similarity search. Recursive CTEs cover graph traversal. ACID transactions keep mutations coherent. pgAudit preserves traceability. A separate vector database or graph store adds new consistency boundaries and new failure modes. Borg stays PostgreSQL-native to avoid an entire class of distributed-state bugs.
Measured Results (April 2026)
The compilation thesis tested on real production episodes from cloud-infrastructure engineering.
Across 10 benchmark tasks, Borg compiled context (C) achieved 10/10 task success compared to 8/10 for vector RAG (B) and 0/10 for no memory (A). Retrieval precision reached 0.913, with a 78% lower stale fact rate and 61% less irrelevant content than vector RAG. Knowledge coverage improved by 16% (0.908 vs 0.782).
The gain comes from what is included, not from using fewer tokens — context token counts are comparable between B and C (2,806 vs 3,026). Full benchmark methodology and per-task results are on the benchmarks page.
Compilation, Not Search
This is the architectural bet underneath the whole system.
RAG treats memory as a search problem: query in, documents out. Borg treats memory as a compilation problem: messy source material goes through a sequence of extraction, validation, resolution, supersession, ranking, and formatting passes before any context reaches a model.
The compiler analogy is literal. Source code is redundant, inconsistent, and written for humans. A compiler turns it into a smaller, structured artifact that machines can use. Conversations are the same. They are contradictory, local, emotional, and full of dead ends. Borg's offline pipeline compiles them into memory that can be trusted enough to retrieve.
That is why the pipeline has multiple passes. Embeddings, entity extraction, three-pass resolution, fact extraction, supersession, serving-state updates, procedure extraction, and snapshots each preserve a guarantee you lose if you cut the step out.
Bottom Line
The systems that win at AI memory will treat it as data engineering, not vector search with better marketing.
Borg is built around that assumption from the start.
See The Implementation
The theory only matters if the runtime and data model reflect it.