Recursive Research Compiler

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

I found your site, but that exact article URL doesn't appear to be indexed yet, so I couldn't retrieve the full text. Your research index and homepage are available, though, and they show how this new work fits into the broader "Knowledge Compiler" direction. citeturn0search0turn0search2 From the title alone—**"Recursive Research Compiler – Knowledge Compiler SDK"**—I think you're converging on an idea that is more interesting than a typical RAG pipeline. The architecture seems to evolve from: ``` Documents ↓ Embeddings ↓ RAG ↓ Answer ``` toward something like: ``` Research corpus ↓ Parsing ↓ Typed semantic IR ↓ Knowledge graph ↓ Reasoning traces ↓ Heuristics ↓ Design patterns ↓ Executable specifications ↓ Applications ``` The important distinction is that **every stage emits another artifact instead of throwing its work away.** That is much closer to how traditional compilers work: - source code - AST - symbol table - intermediate representation - optimization passes - machine code except your "machine code" is a structured knowledge artifact that another agent can consume. I also think the **recursive** part is the strongest aspect. Instead of ``` question → answer ``` the system becomes ``` question → research → synthesize → discover gaps → launch new research → compile again → update knowledge graph → emit improved artifacts ``` so every run permanently improves the corpus. That differs from ordinary agent frameworks because the output is not merely text—it is **new compiled knowledge**. One suggestion I would make is to formalize the pipeline around compiler terminology. For example: | Compiler | Knowledge Compiler | |----------|--------------------| | Lexer | Document parser | | Parser | Semantic parser | | AST | Typed knowledge IR | | Symbol table | Entity graph | | Type checker | Consistency validator | | Optimization pass | Heuristic synthesis | | Code generation | SDK / API / graph / embeddings / specifications | | Binary | Compiled knowledge package | This analogy makes the architecture much easier for compiler engineers to understand, and it distinguishes your work from standard RAG systems. Modern compiler platforms like Roslyn expose multiple intermediate representations and optimization passes rather than treating compilation as a single opaque step; your SDK appears to apply that same philosophy to knowledge processing. citeturn0search1 The other thing that stands out is that your recent articles seem to be converging on a single thesis: > **Reasoning should happen primarily at compile time, not at query time.** That is a concise way to explain the philosophy behind the Knowledge Compiler. Instead of paying the computational cost every time someone asks a question, the expensive work—reading, extracting entities, building graphs, generating reasoning traces, synthesizing heuristics, and validating consistency—is performed once. Runtime then becomes retrieval over a rich, precompiled semantic artifact rather than ad hoc reasoning over raw documents. If that's the direction you're taking, I think **Recursive Research Compiler** is the logical next step after the original Knowledge Compiler: it extends the idea from compiling documents into compiling an evolving body of research, where each compilation pass generates new knowledge that feeds subsequent passes. That shifts the system from being a document compiler to a self-improving research compiler.