Why RAG Is Already Outdated: The Compounding Intelligence Pattern

Most people's experience with AI and documents is retrieval-augmented generation: upload files, ask questions, get answers derived from scratch each time. NotebookLM, ChatGPT file uploads, most enterprise "AI document" solutions work this way. It works, but it doesn't compound. Ask a question that requires synthesising five documents and the AI pieces it together from scratch every time. Nothing is built up. The system knows nothing more after a thousand queries than it did after the first.

RAG was a necessary step. It made large document sets queryable without blowing context windows. But the architecture has a ceiling, and most enterprise deployments are already hitting it. The pattern that breaks through that ceiling is compounding intelligence, and the difference in outcomes is not marginal.

The Pattern That Changes Everything

Andrej Karpathy articulated this pattern publicly and clearly. The core insight: instead of deriving answers from raw documents every time, you compile a persistent wiki from your documents and maintain it as new material arrives. The wiki is the intelligence layer. Queries run against the wiki, not the raw sources. The distinction sounds simple. The implications are significant.

Three layers define the architecture. The first is raw sources: your immutable documents, never modified, always available as the source of truth. PDFs, contracts, research reports, emails, whatever your organisation produces and receives. They are the ledger. The second layer is the knowledge wiki: a structured, LLM-maintained collection of markdown pages that synthesise everything in the raw sources. Entity pages for people, organisations, and obligations. Concept pages for compliance requirements and regulatory interpretations. Comparison pages that auto-generate when new data contradicts what the wiki already knows. The wiki is compiled once and kept current, not re-derived on every query. Cross-references already exist. Contradictions are already flagged. Synthesis already reflects everything ingested. The third layer is the schema: the structure that tells the AI how to organise the wiki. Per-industry, per-customer. It co-evolves as the wiki grows.

The key difference from RAG is where the intelligence lives. In RAG, intelligence is produced at query time from raw documents. In compounding intelligence, it accumulates permanently in the wiki. Each new document enriches the wiki. Each query can enrich it further. The system genuinely gets smarter over time.

Why This Matters for Enterprise

Consider a fund manager with $27 billion under management. Portfolio knowledge lives in PM spreadsheets, Bloomberg terminals, and people's heads. When a senior portfolio manager leaves, that knowledge walks out the door. Their mental model of a sector, their interpretation of how a particular issuer has evolved over three years of engagements, their intuition about a counterparty - none of it is captured. The next PM starts from scratch.

With compounding intelligence, every reconciliation resolved, every scenario modelled, every question asked builds the institutional knowledge base permanently. The wiki accumulates everything: which data discrepancies were real and which were artefacts, how specific positions were rationalised under different market conditions, what the risk committee concluded in previous reviews. After six months, you do not just have a dashboard. You have a queryable brain. New analysts inherit that intelligence on day one.

This is not about replacing human judgment. It is about ensuring human judgment is not lost when the human leaves. The compounding pattern preserves institutional knowledge in a form that is searchable, cross-referenced, and continuously updated.

Document Intelligence That Gets Smarter Over Time

Apply the same pattern to document processing and the implications multiply. Most document processing treats each document in isolation. A contract review tool reads the contract, extracts the relevant clauses, and stops there. Each document is an island. With compounding intelligence, document number fifty benefits from everything learned in documents one through forty-nine.

Cross-document intelligence emerges that is impossible in isolated processing. "This clause contradicts your 2024 master services agreement." "This compliance requirement changed since your last regulatory audit." "Three of your active contracts reference the same counterparty representation that was disputed in the 2023 arbitration." None of these observations require a human to read all the documents and hold them in mind simultaneously. The wiki holds them in mind permanently.

The customer's knowledge base gets richer with every document ingested. The wiki is the moat. Switching costs are not contractual, they are epistemic - the accumulated intelligence is unique to that customer's document corpus, compiled over time, and not reproducible from a standing start. A competitor cannot replicate six months of wiki compilation overnight.

Three Layers, Not One

The architecture is worth spelling out precisely because the temptation is to collapse it into a single system. Each layer has a distinct role and must be kept separate.

• Layer 1 - Raw Sources: Immutable documents that are never modified. Every contract, report, email, and dataset in its original form. This is the source of truth. Nothing in the wiki is more authoritative than the raw source it derives from. The raw sources are indexed but not changed.
• Layer 2 - The Knowledge Wiki: LLM-generated and maintained structured markdown. Entity pages compile everything known about a person, organisation, or obligation across all source documents. Concept pages synthesise regulatory interpretations, compliance requirements, and analytical frameworks. Comparison pages auto-generate when new ingestion contradicts existing wiki entries - the AI flags the contradiction, documents both versions, and surfaces it for resolution. The wiki updates every time a new document is ingested.
• Layer 3 - The Schema: The structural definition that tells the AI how to organise the wiki. Which entity types exist. Which relationships are tracked. Which concepts have dedicated pages. The schema is per-industry and per-customer. A fund manager's schema tracks issuers, mandates, and portfolio events. A professional services firm's schema tracks clients, projects, and regulatory touchpoints. The schema co-evolves as the wiki grows - new patterns in the data suggest new organisational structures.

Treating these as one system collapses the architecture. The raw sources must remain immutable or you lose auditability. The wiki must be structured or it becomes a blob of text that is no more queryable than the raw sources. The schema must be explicit or the wiki grows inconsistently and becomes difficult to maintain.

The Compounding Loop

Four operations make the system work. Each one reinforces the others.

• Ingest: A new document arrives. The LLM reads it in the context of the existing wiki - not in isolation. It updates relevant wiki pages, creates new pages where needed, generates cross-references to related entities and concepts, and flags contradictions with existing knowledge. The wiki after ingestion is more complete than before. The improvement is permanent.
• Query: Questions run against the wiki, not the raw documents. Answers are richer because the wiki already contains synthesis, cross-references, and resolved contradictions. Answers can be filed back as new wiki pages - an investigation that resolves a question becomes part of the permanent knowledge base. Explorations compound.
• Lint: Periodic health checks run against the wiki itself. The AI identifies contradictions that were not flagged at ingestion time, stale data whose underlying sources have been superseded, orphan pages that have lost their cross-references, and missing connections that should exist based on the schema. The lint pass suggests new questions to investigate - gaps in the wiki that indicate gaps in the underlying document corpus.
• Evolve: The schema and wiki structure improve over time as patterns emerge. Early in the process, the schema reflects what you knew you needed. Later, the wiki reveals what you actually have - entity types that appear frequently but have no dedicated structure, relationships that recur but are not tracked, concept clusters that deserve their own organisational layer. The schema evolves to match the intelligence that has accumulated.

What This Means in Practice

Three application areas where the compounding pattern changes the output materially:

• Fund management: PM knowledge capture that persists beyond individual tenure. Attribution data that reflects reconciled source data, not re-derived estimates. Cross-portfolio intelligence that surfaces correlations and concentration risks across the full book, not just within individual mandates. The wiki becomes the institutional memory that does not leave when people do.
• Professional services: Every project outcome feeds the next proposal. Fee calibration informed by a wiki that tracks what was charged, what was delivered, and what the client said about it across every prior engagement. Council and regulatory intelligence compiled from every consent application, every notice of requirement, every relevant decision - not retrieved from scratch for each new project. Pre-flight checks generated automatically from compiled knowledge before each new engagement begins.
• Healthcare compliance: Clinical records cross-referenced so that patient history is presented in context, not as isolated entries. Compliance gaps detected automatically when new documentation contradicts or updates prior clinical decisions. Patient history trending over time, with the wiki surfacing patterns that would require a human to read years of records to identify manually.

Why Bloomberg and Aladdin Cannot Do This

The major enterprise platforms are stateless analytics systems. Bloomberg PORT recalculates from scratch on every query. The output is only as current as the data feed, and the system holds no memory of prior calculations, prior questions, or prior resolutions. Aladdin is a massive monolith with a three to four year RFP cycle and an implementation timeline measured in years. Neither builds persistent institutional knowledge. They are powerful calculators. Powerful calculators do not compound.

This is not a criticism. These systems are excellent at what they are designed for: real-time analytics, order management, risk calculation. They are not designed to maintain a persistent, evolving knowledge base that gets richer with every document and every question. The architecture that produces stateless analytics is fundamentally different from the architecture that produces compounding intelligence. You cannot bolt compounding onto a stateless system. It requires a different foundation.

The same is true of RAG implementations built on top of these platforms. Adding a vector database and a retrieval layer to Bloomberg does not change the underlying architecture. You still retrieve from raw sources. You still derive answers from scratch. You still forget everything between queries.

Where This Is Going

The shift from "ask AI a question" to "build AI that compounds knowledge" is fundamental. RAG was a good start - it made large document sets queryable and demonstrated that LLMs could do useful work on domain-specific corpora. Compounding intelligence is where it goes next. The systems that will matter in enterprise in three years are the ones being built with this architecture today, not the ones that retrieve faster from raw documents.

We are building compounding intelligence into every product we ship: document intelligence for professional services and healthcare, enterprise platforms for fund managers, operational knowledge capture for firms whose institutional memory lives in people's heads. If your AI forgets everything between sessions, you are leaving compounding value on the table. The pattern is not complicated. The implementation is.