Recursive Research Compiler

https://www.danielkliewer.com/blog/2026-07-14-recursive-research-compiler-knowledge-compiler-sdk

I see you shared the link to your post: **“Recursive Research Compiler: Knowledge Compiler SDK”**. I pulled it up and it looks like it fits directly into the “compile-time AI” idea you have been developing. citeturn0search1turn0search3 The interesting framing is that you are moving the AI workload from **runtime inference** to **offline compilation**: - Traditional RAG: ``` User query ↓ Retrieve documents ↓ Stuff context into LLM ↓ Reason at runtime ↓ Answer ``` - Knowledge compiler / recursive research compiler: ``` Raw knowledge sources ↓ Research agents explore + reason ↓ Extract concepts, relationships, heuristics ↓ Build knowledge graph + semantic artifacts ↓ Compile deployable artifact ↓ Runtime becomes lookup + lightweight reasoning ``` That is a meaningful distinction. You are basically treating knowledge the way software treats source code: **the expensive transformation happens during compilation, not every time the program executes.** This also connects with emerging ideas around compiled knowledge formats and knowledge operations: turning unstructured documents into typed, structured packages rather than repeatedly making models rediscover the same relationships. citeturn0search5 The strongest part of your concept, in my opinion, is the **recursive research loop**: 1. Ingest sources. 2. Generate hypotheses about the domain. 3. Create questions an expert would ask. 4. Research those questions. 5. Update the graph. 6. Generate artifacts. 7. Repeat until diminishing returns. That is closer to how a human researcher builds expertise. A human does not reread every book every time someone asks a question; they build mental models, summaries, heuristics, and associations. The compiled output could be something like: ``` knowledge/ ├── ontology.json ├── entities/ ├── relationships/ ├── reasoning_rules/ ├── FAQs/ ├── decision_trees/ ├── citations/ ├── embeddings/ └── app/ └── static Next.js deployment ``` Then the runtime system is no longer "AI reading documents." It is "AI querying a compiled intelligence artifact." That is a subtle but important shift. The analogy I would sharpen in the article is: > RAG is like interpreting source code every time you run a program. Compile-time AI is like building a binary: the expensive reasoning, indexing, optimization, and representation work happens once, then users interact with the optimized artifact. The other interesting angle is that your project sits between: - RAG systems (retrieval) - knowledge graphs (structure) - agentic research (generation) - compilers (optimization and transformation) - static applications (distribution) Your Sovereign Intelligence Stack already has a similar direction: persistent structured knowledge, reasoning layers, orchestration, and applications rather than disposable chat sessions. citeturn0search7 A possible one-line positioning: > **The Knowledge Compiler is a compiler toolchain for intelligence: it transforms raw information into optimized, deployable reasoning artifacts that make AI cheaper, faster, and more sovereign.** I think the biggest thing to emphasize is that you are not saying "replace RAG." The stronger argument is: > RAG is the runtime linker. The knowledge compiler is the build system. RAG still has a place for dynamic information, but many enterprise and domain-specific questions are predictable enough that paying the reasoning cost millions of times is wasteful. That distinction makes the idea much easier for engineers to immediately understand.

what do you think of this email I sent about this: I've been chewing on this idea I call Compile Time AI. The core concept is simple but powerful: take everything expensive about systems like RAG and GraphRAG—the repeated retrieval, reasoning, entity extraction, and context assembly that burns tokens and adds latency on every single query—and shift as much of that heavy lifting as possible into a one-time compilation step upfront. Instead of paying the token tax and latency hit every time a user asks something, you analyze the full knowledge domain once, perform deep reasoning over the source material, resolve contradictions, deduplicate, cluster semantically, extract entities/relationships/claims, map likely question paths, and output a rich, low-latency intermediate representation. That artifact then powers something like a statically deployed Next.js app on Vercel—precomputed knowledge graphs, APIs, and query surfaces that feel instant and sovereign. Many questions in a given domain are predictable. By treating knowledge like source code and running it through a compiler pipeline—entity extraction → claim validation → contradiction resolution → semantic clustering → higher-order JSON graphs—you end up with a compiled knowledge artifact rather than a pile of raw documents. The runtime becomes cheap, deterministic where possible, and far more secure because sensitive reasoning happens offline, once, before deployment. I built a working example that turns a corpus into exactly this: a live Next.js frontend exposing the compiled graph and APIs. I explain the architecture in more detail through the following post, GitHub repo, NotebookLM, and live demo in greater detail. This feels like the future to me because it fundamentally flips the cost model: massive upfront compute for dramatically lower ongoing costs, better privacy/security (no live data exfiltration or repeated model calls), and snappier user experiences. It's aligned with the broader sovereign/local-first stack I've been building—where intelligence compounds offline and runs on your terms. Would love your thoughts—especially on how this could extend into agentic workflows, code generation, or domain-specific products. Best, Daniel Kliewer danielkliewer.com Austin, TX

I think this is a strong email. It communicates a genuinely interesting architectural idea, and it is much clearer than some of the earlier versions where the concept risked sounding like "RAG but faster." The strongest part is that you are framing it as a **change in where computation happens**, not merely an optimization. A few thoughts: ## What works well ### 1. The compiler analogy is excellent This sentence is the core: > "By treating knowledge like source code and running it through a compiler pipeline..." That is the mental model people immediately understand. Software engineers already intuitively understand: - source code → compiler → optimized binary → execution - raw knowledge → knowledge compiler → intelligence artifact → application That analogy gives the whole idea a foundation. ### 2. You correctly identify the hidden cost of RAG This is probably the most compelling technical argument: > "the repeated retrieval, reasoning, entity extraction, and context assembly that burns tokens and adds latency on every single query" Most discussions around RAG focus on retrieval quality. Your angle is that **the system is repeatedly rediscovering structure that could have been learned once**. That is a legitimate systems argument. ### 3. The "intermediate representation" terminology is very good I would actually lean into this more. Compilers do not translate source code directly into machine instructions in one magical step. They create intermediate representations (IRs) because IRs allow optimization. Your idea naturally maps: ``` Documents ↓ Knowledge IR ↓ Optimized domain artifact ↓ Application/runtime ``` That is probably the most novel framing. --- ## Where I would tighten it The main risk is that some AI researchers may read it and think: > "Isn't this just fine-tuning, embeddings, indexing, caching, distillation, or precomputation?" You want to proactively distinguish it. The key difference is: - Fine-tuning changes model weights. - Embeddings optimize retrieval. - Caching stores previous outputs. - RAG retrieves context dynamically. - **Compile-time AI creates a domain-specific reasoning artifact.** I would add a paragraph like: > "This is not replacing RAG, fine-tuning, or agents—it is moving the expensive intelligence-building phase earlier in the lifecycle. RAG is useful for dynamic retrieval; compile-time AI is for domains where the structure, concepts, and likely reasoning paths can be discovered ahead of time." That prevents the obvious objection. --- ## One thing I would change This part: > "resolve contradictions" is ambitious. It sounds like the compiler is magically creating truth. I would soften it: > "identify contradictions, confidence levels, and competing claims" because a compiler does not necessarily decide what the correct program logic is—it detects and transforms. Similarly: > "deterministic where possible" is good. Keep that. It shows you understand the limits. --- ## The biggest opportunity I think the email undersells the agentic aspect. The really interesting part is not just: "take documents and make JSON." Lots of systems do that. The interesting part is: ``` Agent researcher ↓ Question generation ↓ Evidence gathering ↓ Hypothesis testing ↓ Knowledge graph evolution ↓ Compilation ↓ Deployable intelligence artifact ``` That is closer to a **research compiler** than a document processor. The compiler is not just transforming data. It is doing knowledge acquisition. --- ## My suggested positioning sentence I would probably replace: > "This feels like the future to me because it fundamentally flips the cost model" with something slightly more precise: > "The fundamental shift is treating intelligence as something that can be built, optimized, and deployed—not something that must be regenerated from raw information at every interaction." That is the thesis. --- Overall, I think the email is probably the strongest articulation of this idea you've written. The concept is becoming less "AI architecture buzzword" and more of a systems thesis: **RAG made AI useful by connecting models to knowledge. Compile-time AI makes AI scalable by turning knowledge into optimized artifacts.** The main thing I would do before sending it to technical audiences is add the distinction from existing approaches (RAG, fine-tuning, caching, distillation), because that is the first comparison they will make.

now rewrite it as a linkedin post

:::writing{variant="social_post" id="58391"} **I think the next evolution of AI systems is moving from runtime intelligence to compiled intelligence.** I've been exploring an idea I call **Compile-Time AI**. Today, systems like RAG and GraphRAG make LLMs useful by connecting them to external knowledge. But there is a fundamental inefficiency: every user query often repeats expensive work—retrieval, context assembly, entity extraction, relationship discovery, and reasoning over the same domain knowledge. What if we moved much of that computation earlier? Instead of asking an AI system to rediscover a knowledge domain every time someone asks a question, we could compile that knowledge upfront. The pipeline looks something like: **Raw information** ↓ **Agentic research + deep analysis** ↓ **Entity extraction, semantic clustering, claim mapping, contradiction detection** ↓ **Knowledge graph + reasoning structures** ↓ **Compiled knowledge artifact** ↓ **Low-latency AI applications** The result is not just a collection of documents. It is an intermediate representation of knowledge—a compiled artifact that can power applications, APIs, and interfaces. The analogy is software compilers: A compiler does not interpret source code from scratch every time a program runs. It performs expensive transformations ahead of time and produces an optimized artifact. Compile-Time AI applies the same idea to knowledge: **Documents are the source code. The knowledge compiler creates the optimized artifact. Applications execute against that compiled intelligence.** This changes the cost model: - Lower runtime inference costs - Faster user experiences - More predictable behavior - Better privacy and sovereignty - More intelligence that can run locally or in controlled environments This does not replace RAG, agents, or fine-tuning. Instead, it changes where the expensive work happens. RAG remains powerful for dynamic information retrieval. But for stable domains—medicine, law, engineering, internal company knowledge, research repositories, technical documentation—there is an opportunity to build intelligence once and deploy it many times. I've been building a prototype Knowledge Compiler SDK that turns knowledge sources into a live, queryable Next.js application with compiled graphs and APIs. The broader vision is a shift from AI systems that constantly regenerate intelligence to systems where intelligence compounds over time. The model is not the product. The compiled knowledge artifact is. I would love to hear thoughts from people working on RAG, agents, knowledge graphs, and AI infrastructure. 🔗 https://www.danielkliewer.com/blog/2026-07-14-recursive-research-compiler-knowledge-compiler-sdk #AI #GenerativeAI #RAG #KnowledgeGraphs #AgenticAI #AIAgents #SoftwareArchitecture :::