Knowledge Compiler SDK Github

Live Demo

The Recursive Research Compiler: Turning Compile-Time AI Inward with the Knowledge Compiler SDK

A few weeks ago I wrote a survey of Compile-Time AI — the pattern, showing up independently in projects like kib, Kompile, Brian Letort's Context Compilation Theory, llm-wiki-compiler, OVIR, and the SkCC paper, of moving semantic work out of the request path and into a build step. That post was a taxonomy. This one is the implementation.

The Knowledge Compiler SDK is my own entry in that space, and it's designed to answer a question the taxonomy post left open: once you accept that knowledge should be compiled rather than re-derived at query time, what does the compiler itself look like, and what happens when you point it at your own source code? The second half of that question is where things get interesting, because the SDK doesn't just compile documents — paired with an autonomous agent, it can compile itself forward, one architectural gap at a time.

The runtime tax, restated

The core complaint against standard Retrieval-Augmented Generation is simple: every query pays full price. Vector retrieval, context assembly, and generation all happen fresh, even when the underlying knowledge domain hasn't changed since the last query. A RAG pipeline answering the same class of question for the thousandth time does exactly the same work it did the first time. Nothing is retained except the raw chunks sitting in the vector store.

Compile-Time AI treats this as a systems-design failure, not a fact of nature. If a knowledge domain is static — or changes on a build cadence rather than a per-request cadence — then the semantic understanding, the multi-hop reasoning, and the concept aggregation belong in a build step, not in the hot path. A token, in this framing, is this era's CPU cycle: something you spend once, deliberately, to produce an artifact that's cheap to consume forever after.

Software compilers already solved this problem for code. Expressive, redundant source gets transformed into an optimized executable; the compiler pays the analysis cost once, up front, so that runtime doesn't have to. The Knowledge Compiler SDK applies the same discipline to Markdown:

That last row is worth sitting with. The deployable unit isn't a chatbot with a system prompt bolted onto a vector index — it's a static application. The reasoning already happened. What ships is the result.

What the SDK actually is

It's worth being precise about what the Knowledge Compiler SDK is not. It isn't a chatbot framework, it isn't a RAG wrapper, and it isn't a curated prompt library. It's compiler infrastructure, and it takes that seriously in three specific ways.

First, every artifact it produces is immutable and transparent — written once as JSON, GraphML, or TypeScript, and fully inspectable afterward. Nothing about the reasoning is hidden in a model's context window or a chat transcript that evaporates when the session ends. If the compiler concluded something about how two concepts relate, that conclusion is a file you can open, diff, and put under version control.

Second, inference is local-first. The pipeline is built to run against a local OpenAI-compatible server — llama.cpp or Ollama — so the compilation step never has to leave your machine. This matters for a project explicitly framed around sovereignty: if the compiler itself depends on a cloud API, you haven't decoupled reasoning from infrastructure you don't control, you've just moved the dependency one layer down.

Third, it ships with reusable structure for agents to act on: seventeen agent skills in the repository's skills/ directory, written for tools like Hermes or Claude Code. This is the part that turns the SDK from "a compiler" into "a compiler an agent can operate," and it's the hinge the rest of this post turns on.

Compiling the compiler: the recursive research loop

The most interesting use of any compiler is compiling itself. For a knowledge compiler, that means pointing the pipeline not just at your notes, but at your own codebase and the research literature around it — and letting the agent propose the next version of the compiler based on what it finds missing.

Here's the loop, driven with the kc CLI:

Initialize the local substrate. Start a local inference server on a port you control, then bring the compiler up against it:

kc run --local --port 8080 --model hermes-2-pro

Ingest and parse. The first passes are deterministic and don't touch the model at all — pass-01-collect and pass-02-normalize walk the Markdown sources and build a clean AST. Only at pass-03-extract-concepts does the agent step in, loading a specific skill from the repo and reading the raw AST to extract entities and concepts into a strict JSON artifact. The determinism-first ordering matters: cheap, mechanical work happens before anything model-dependent, so the expensive step only ever sees clean input.

Cybernetic comparison. Once the external research — papers, related repos, systems-design literature — is compiled into an architecture graph at pass-05, the agent acts as a comparator rather than a summarizer. It compares the newly compiled external knowledge against the SDK's own active architecture, using AST-level semantic diffing instead of line-by-line text diffs. That distinction is the difference between finding "this paragraph changed" and finding "this system has a concept — say, dead-knowledge elimination — that our architecture graph doesn't."

Harness engineering and self-evolution. When pass-10-update-sdk finds a real gap, the loop closes: the agent proposes a new declarative compiler pass in YAML, specifying exactly what it consumes and produces. The orchestrator runs it, and every artifact the new pass generates is evaluated across nine dimensions, including hallucination, provenance, and consistency. If the model returns malformed output, the scaffold retries with exponential backoff; if it still fails, the compiler exits loudly rather than silently shipping a bad artifact. A build that fails honestly is more useful than one that succeeds by accident.

Why the ephemeral-conversation model can't do this

It's worth naming why this loop specifically requires the compile-time framing rather than a long-running agentic chat session. Conversational agents keep their reasoning in a transcript. That's fine for a single task, but it means the reasoning is state-locked to the session: when the chat ends, so does the understanding, and the next session starts back at zero unless someone manually re-feeds context. Over enough iterations, that produces the kind of cognitive drift and non-determinism that makes long-term architectural maintenance genuinely hard — not because the model got worse, but because there's no durable substrate underneath the conversation for it to check its work against.

Treating intermediate representations as first-class, durable state solves this directly. The architecture graph the SDK builds of its own codebase isn't a summary living in someone's chat history — it's a file. The next agent session, run days or weeks later, doesn't have to reconstruct an understanding of the system from scratch; it loads the graph and picks up the comparison where the last run left off. Reasoning becomes something you can explicitly query, validate, and debug, rather than something you have to hope survived the last context window.

Where this sits in the taxonomy

Set against the earlier survey — kib and Kompile's knowledge-compilation approach, Context Compilation Theory's framing of context itself as a build artifact, llm-wiki-compiler's durable-pages pattern, OVIR, SkCC's formal treatment of skill compilation — the Knowledge Compiler SDK occupies a specific niche: it's the version of this pattern applied reflexively, to the compiler's own architecture. Most compile-time systems compile an external domain — your notes, your codebase's documentation, a wiki. This one is explicitly built to also compile the gap between what exists in the literature and what the system itself currently does, and to propose closing that gap as a typed, YAML-declared pass rather than an ad hoc patch.

That reflexivity is what makes "recursive" the right word rather than just "automated." The system isn't only applying a fixed set of passes to new input — it's using the same pipeline to evaluate and extend the set of passes it has.

Sovereign AI, concretely

This is also, I think, the clearest existing illustration of what I mean by Sovereign AI: intelligence you own, running on infrastructure you control, making decisions from a knowledge substrate compiled from your own sources rather than rented from someone else's API. The Knowledge Compiler SDK doesn't just avoid cloud inference as a cost-saving measure — it makes locality a structural requirement, because the entire value proposition depends on the compiled artifacts being fully yours: inspectable, versionable, and reproducible without a subscription.

The broader claim, and the one both this post and the taxonomy piece before it are circling, is that the future of this kind of engineering isn't models writing better code snippets one conversation at a time. It's systems that compile raw knowledge into stable, inspectable architectures, evaluate their own weaknesses against that architecture, and write the next iteration of their own compiler passes — with every step of that process sitting in a file you could hand to another engineer, or another agent, and say: here's exactly what we know, and how we came to know it.

Every few years, systems programming rediscovers the same lesson: expensive work done once, ahead of time, beats expensive work done repeatedly, on demand. That lesson is why we have compilers instead of interpreting source code line-by-line on every execution. It's why we have query planners instead of re-deriving an execution strategy for every SQL statement. And it is, I'd argue, why a scattered but growing set of teams — with no coordination between them — have independently started describing their AI systems using the vocabulary of compilers: intermediate representations, lowering passes, optimizers, emitters, static analysis.

I don't think this is a coincidence, and I don't think it's marketing convergence. I think it's the AI industry rediscovering a systems-design pattern that is older than AI itself, applied to a resource that changed the economics: tokens.

This piece is a survey and a taxonomy, not a pitch for any one project. I looked closely at six efforts — kib, Kompile, Brian Letort's Context Compilation Theory, llm-wiki-compiler, OVIR, and the SkCC academic paper on skill compilation — plus the compiler literature they explicitly or implicitly borrow from (LLVM, MLIR). I want to show you the pattern underneath all of them, where they diverge, and where I think the analogy to traditional compilers breaks down.

The Core Thesis: Runtime AI vs. Compile-Time AI

Most AI systems built since 2023 follow the same shape. A question arrives. The system searches, retrieves, assembles a prompt, and asks a large model to reason over it — from scratch, every single time.

Traditional RAG (Runtime AI)

  Documents
     |
     v
  Embeddings
     |
     v
  Vector DB
     |
     v
     LLM  <-----  every query pays full reasoning cost
     |
     v
  Answer

This works. It is also, structurally, an interpreter. Every query re-derives meaning from raw material. Nothing compounds. If you ask the same conceptual question twice, phrased two different ways, the system does the same expensive work twice, with no memory that it already did it once.

Compile-Time AI proposes a different shape: do the expensive reasoning once, offline, and compile it into a structured artifact that cheap runtime processes can consume.

Compile-Time AI

  Documents
     |
     v
    IR1  (extraction / parsing)
     |
     v
    IR2  (concept / entity normalization)
     |
     v
  Semantic Passes  (dedup, contradiction detection, linking)
     |
     v
  Knowledge Graph
     |
     v
  Optimization  (pruning, confidence scoring, compaction)
     |
     v
  Static Application / Runtime Artifact
     |
     v
  Deployment  <-----  queries hit compiled artifact, not raw reasoning

The reasoning still happens — this isn't "avoid LLMs." It happens once, offline, at compile time, and the output of that reasoning becomes the thing that gets served. Compare that to a traditional compiler pipeline, and the analogy holds up better than you'd expect:

Source Code                    Human Knowledge
     |                               |
     v                               v
    AST                        Document IR
     |                               |
     v                               v
     IR                        Concept IR
     |                               |
     v                               v
Optimization                 Relationship IR
     |                               |
     v                               v
Machine Code                  Heuristic IR
                                     |
                                     v
                              Application IR
                                     |
                                     v
                                  Website

A traditional compiler frontend turns source text into an AST, lowers it into one or more intermediate representations, runs optimization passes, and emits machine code that a much dumber, much faster CPU can execute directly. Compile-Time AI systems turn raw documents into structured semantic objects, lower them through progressively more typed representations, run passes that deduplicate and validate and score confidence, and emit an artifact — a graph, a wiki, a static app — that a cheap runtime process can serve without re-reasoning.

The question worth asking isn't "is this a real trend." It's "why now." Two forces are pushing simultaneously: token economics (frontier-model reasoning is expensive at the volumes production systems now operate at, so amortizing it across many future queries is financially rational), and reliability (a system that reasons fresh every time is also nondeterministic every time — compiling a decision once and auditing it once is a fundamentally different governance posture than re-deriving it under time pressure on every request).

Six Independent Efforts, One Pattern

kib — the headless knowledge compiler

kib is the most literal instance of the pattern. It's a CLI-first tool, built by Keegan Thompson, that ingests URLs, PDFs, YouTube transcripts, GitHub repos, and images, then runs an explicit compile step that turns those raw sources into a structured, queryable markdown wiki. The workflow is unapologetically compiler-shaped: kib init, kib ingest, kib compile, kib query. Search is BM25 full-text over the compiled artifact, not embedding search over raw chunks, and the whole thing ships as an MCP server so agents in Claude Code, Cursor, or Claude Desktop can drive the pipeline directly. Output is plain markdown files under version control — no proprietary database, no lock-in.

What's notable architecturally is the framing on their own site: the tool doesn't call itself a RAG system or a note-taking app. It calls itself a compiler, and the CLI verbs mirror that self-description precisely.

Kompile — enterprise-scale, three-pillar compilation

Kompile is the most ambitious of the group and the one furthest from a single-developer tool. It frames itself around three simultaneous compilation targets: models, knowledge, and applications. On the model side, it runs models through a 25-pass fixed-point graph optimizer — documented to reduce LLaMA cast operations from 668 down to 108 — doing fusion, dead-code elimination, constant folding, and hardware targeting that will look immediately familiar to anyone who has read an LLVM or XLA paper. On the knowledge side, it crawls an organization's data estate (Confluence, Jira, Slack, databases, email) through an eight-phase pipeline — load, classify, route, chunk, extract, resolve, compute edges, index — and compiles it into a typed, hierarchical knowledge graph with seven node levels, full provenance on every mutation, and support for Multi-Entity Bayesian Networks for causal and probabilistic reasoning over the graph. On the application side, it presents one unified interface so a business can swap LLM providers, vector stores, or embedding models without rewriting application logic.

Kompile is the clearest expression of "sovereign AI architecture" among the projects surveyed here: everything runs on the customer's own infrastructure, with air-gapped model archives (.karch files) explicitly built for regulated, disconnected environments. It's early access only as of this writing, so the production-scale evidence isn't public yet, but the architectural ambition is the most complete instance of "compile the whole stack" I found.

Brian Letort's Context Compilation Theory — the missing layer, formalized

Of everything surveyed, Brian Letort's work is the most rigorous attempt to give this pattern a formal theory rather than just an implementation. His argument, laid out across a series of posts, starts from a measurement problem: existing AI benchmarks evaluate answer quality but don't expose the compilation decisions that produced the context a model reasoned over. That gap points to something structural — a layer between retrieval and reasoning that has no name and no theory.

He names it context compilation, and defines Context IR (Context Intermediate Representation) as the portable object that sits between raw source context and runtime execution — typed semantic objects (facts, events, entities, commitments, issues, preferences, contradictions) plus governance metadata (provenance, policy, freshness, confidence, and explicit omission markers recording what was excluded and why).

The architectural claim is a six-layer stack: source context, memory and knowledge substrate, context compiler, Context IR, lowering, and experience runtimes. His insight — and I think this is the sharpest single idea in the entire survey — is that layers three and four, the compiler and the IR, form a stable core that survives changes above and below it. Swap your data source from email to Slack, swap your model from one frontier lab to another, swap your interface from chat to voice: the compiled Context IR doesn't have to change, because policy decisions and relevance selection happened once, in IR space, and only the lowering step is runtime-specific. He calls this property continuity of cognition, and formalizes compilation quality as a constrained optimization over task utility, token cost, latency, policy risk, and provenance loss simultaneously — not relevance alone. That framing is important: a lot of naive knowledge-compilation systems optimize only for "will the model find this useful," and ignore that a compiled artifact also carries governance and cost obligations that a fresh retrieval never had to account for.

llm-wiki-compiler — Karpathy's pattern, implemented as a CLI

llm-wiki-compiler takes its name and inspiration directly from Andrej Karpathy's informally described "LLM Wiki" pattern: instead of re-discovering the same relationships between concepts on every query, compile sources once into a persistent, interlinked, browsable markdown wiki that compounds as you feed it more material.

The implementation is a genuinely two-phase compiler in the classical sense — phase one extracts every concept from every source before anything is written, phase two generates the actual wiki pages — which the maintainers describe as necessary to avoid order-dependence and to catch failures before any output lands on disk. It's incremental (SHA-256 hash checks skip unchanged sources), it supports a review queue so generated pages can be approved or rejected before merging into the live wiki (candidate pages carry confidence scores and provenance state — extracted, merged, inferred, or ambiguous — and can be flagged as contradicted by other pages), and it has claim-level provenance down to specific line ranges in the source document. There's also an explicit lint command that checks the compiled wiki for broken links, orphaned pages, low-confidence content, and contradictions — a genuine static-analysis pass over a knowledge artifact, not a code artifact.

The project is explicit that this is complementary to RAG, not a replacement for it: RAG stays useful for ad-hoc retrieval over large uncompiled corpora, while the compiled wiki is what you retrieve from once material has been through the pipeline.

OVIR — offline compilation of specialist runtimes

OVIR (Offline Verifiable Inference Runtime Network) takes the "compile once, run cheap" idea and applies it to entire domain-specific inference systems rather than to a knowledge graph or a wiki. Its central claim is blunt: frontier models are too expensive to use as the primary runtime reasoner, and should instead be used offline as compilers that produce cheaper systems.

The mechanism is a double-compilation model. Stage one: frontier AI, working offline against a domain's problem definition, data, tools, papers, and constraints, compiles a grid of specialist agents — versioned "skill files" organized across four axes (pipeline stage, vertical domain, conceptual function, abstraction layer). Stage two: those compiled agents then assemble the actual runtime — data pipelines, graphs, search indices, classical ML models (scikit-learn, XGBoost), rules engines, and monitoring loops — with the explicit constraint that the resulting runtime should have no frontier-model dependency unless an escalation path is triggered. Every runtime ships with a verification harness (synthetic evaluations, historical replay, thresholds, trace logging) baked in, and failures at runtime become new compiler input for the next recompilation pass — a closed loop that resembles profile-guided optimization more than typical MLOps retraining.

OVIR's philosophy statement is worth noting because it states the thesis of this entire article as plainly as I've seen it stated anywhere: computing is moving from general-purpose runtime reasoning toward domain-optimized runtime compilation, and the winning system won't be the biggest model, it'll be the best-compiled runtime.

SkCC — a peer-reviewed instance of the pattern, applied to agent skills

The academic literature is starting to catch up to what these production tools are already doing. SkCC (Sun Yat-sen University, preprint 2026) is the cleanest formal instance I found: a compiler for LLM agent skills that introduces classical compiler design — lexer, parser, typed IR, optimizer, target emitter — directly into how SKILL.md files get deployed.

The motivating problem is concrete and measured, not hand-waved: the same skill markdown file, deployed identically across Claude Code, Codex CLI, Gemini CLI, and Kimi CLI, produces wildly different pass rates, because each model's training distribution has a documented format preference (Claude performs better with XML-tagged structure; GPT-series models are hurt by a "JSON format tax"; deeply nested data parses best as YAML). Authoring separately for every framework is an m×n problem. SkCC's answer is SkIR, a strongly-typed intermediate representation that captures what a skill means independent of how it's formatted, plus a static Security Optimizer that scans procedure text for dangerous patterns (unsafe HTTP calls without timeouts, unbounded loops, destructive database operations) and injects safety constraints directly into the IR before any framework-specific emission happens — meaning the constraint survives translation into every target format automatically, rather than depending on each author remembering to add it.

The empirical results are the most rigorous evidence in this entire survey that compilation produces real gains, not just architectural elegance: pass rates improved on every tested framework (Claude Code: 21.1% → 33.3%; Kimi CLI: 35.1% → 48.7%), compilation itself runs in under 10 milliseconds per skill, the security optimizer triggered protective constraints on 94.8% of 233 real-world community skills audited, and — despite adding structural overhead in the form of XML tags and injected constraints — net runtime token consumption still dropped 10-46% across frameworks, because structured formatting reduced the model's trial-and-error during execution. The paper also runs the experiment that matters most for anyone tempted to treat "the compiled format" as universal: the same Kimi-optimized output helps Kimi, is neutral on GLM, and is mildly negative on DeepSeek. There is no one-size-fits-all compiled format. Compilation gains are model-specific, which is itself an argument for a real compiler architecture — a shared IR with pluggable, per-target emitters — rather than a single hand-tuned prompt template.

An Original Taxonomy of the Compile-Time AI Ecosystem

Laying these six efforts side by side, they cluster into layers that map cleanly onto where in an AI system's pipeline the compilation happens. I'd propose the following taxonomy:

Knowledge Compilation — turning raw documents into structured, queryable, persistent artifacts. kib and llm-wiki-compiler are the clearest instances: both take heterogeneous sources and compile them into an interlinked markdown wiki, with provenance and confidence metadata attached at the page level.

Context Compilation — turning heterogeneous available context (not just documents, but memory, preferences, prior commitments) into a governed working set for a specific reasoning task. Brian Letort's Context Compilation Theory is the formal treatment of this layer; it sits conceptually above knowledge compilation, consuming compiled knowledge as one of several inputs.

Application Compilation — turning compiled knowledge and context into deployable interfaces. Kompile's "applications" pillar and my own SOVEREIGN architecture (a unified stack that collapses a knowledge graph, a persona-routing MoE orchestrator, and a governance layer into a single deployable system) both live here.

Skill / Agent Compilation — turning reusable agent capabilities into portable, verified, framework-targeted artifacts. SkCC is the rigorous academic instance of this; it's the layer closest to traditional software compilation, because the artifact being compiled (a SKILL.md file) is itself closer to source code than to prose.

Runtime Optimization — reducing the cost and latency of the model or system that finally executes at inference time. Kompile's model-compilation pillar (the 25-pass graph optimizer) and OVIR's entire premise both live here — this is the layer where "compile-time AI" most literally reuses classical compiler techniques like fusion, dead-code elimination, and hardware targeting.

Sovereign AI — not a compilation layer at all, but a cross-cutting property that most of these projects share by design choice rather than accident: the compiled artifact is something you own, can inspect, can version with git, and can run without a network dependency. kib's "no lock-in, plain markdown files" stance, Kompile's air-gapped .karch archives, and OVIR's "owned infrastructure instead of rented runtime cognition" framing are all the same underlying value — compilation and sovereignty reinforce each other, because a compiled artifact is portable and auditable in a way a black-box API call never is.

I'd place my own work at DanielKliewer.com — particularly the SOVEREIGN synthesis, which collapses a Neo4j/NetworkX dual-substrate knowledge graph, a persona-routing mixture-of-experts orchestrator, and an execution-path governance layer into one architecture, and the Telemetry Intelligence Engine, which compiles GA4 analytics and site content into a queryable behavioral knowledge graph — inside the Knowledge Compilation and Application Compilation quadrants, with the sovereignty property treated as a hard architectural constraint rather than a nice-to-have.

Where the Compiler Analogy Breaks Down

I want to be careful here, because it would be easy to overstate this. Compile-Time AI is not "solved," and it does not replace runtime reasoning — it defers and restructures it.

Determinism is aspirational, not guaranteed. A real compiler is deterministic: the same source produces the same machine code every time (modulo explicit nondeterminism like randomized register allocation heuristics). None of these systems can make that promise, because the compilation step itself runs an LLM. Compile the same document corpus twice with kib or llm-wiki-compiler and you may get slightly different concept boundaries, slightly different summaries, slightly different confidence scores. That's not a bug in any one implementation — it's a structural property of using a stochastic process as your compiler frontend. The best of these systems (llm-wiki-compiler's confidence and provenance metadata, SkCC's structural validation, Kompile's audit trails) manage this by making the uncertainty itself a first-class, inspectable output rather than hiding it, which is a reasonable adaptation but is not the same thing as true determinism.

Staleness is a real cost that traditional compilers don't have. Source code doesn't change meaning between compiles. Knowledge does. A compiled knowledge graph or wiki is a snapshot; if the underlying domain shifts — new regulations, a product pivot, updated research — the compiled artifact silently drifts out of alignment with reality until something recompiles it. Every project here that takes this seriously (OVIR's recompilation loop, llm-wiki-compiler's hash-based incremental recompilation, Kompile's TTL sweep and confidence pruning maintenance tasks) treats this as an ongoing operational problem, not a one-time build step. This is arguably the single biggest way Compile-Time AI differs from traditional compilation: you don't just compile once and ship, you have to keep recompiling against a moving target, forever.

Not everything should be compiled. Ad-hoc, novel, one-off questions over a corpus that will never be asked again are exactly the case where runtime RAG remains the right tool — there's no return on investment for compiling something you'll query once. Even llm-wiki-compiler is explicit that it complements rather than replaces RAG for this reason. The right mental model isn't "compile everything," it's closer to a JIT compiler's tiered execution: interpret (retrieve) the long tail of rare queries, and only promote patterns to compiled status once they show up often enough to amortize the compilation cost — a threshold that today, in every project surveyed here, is set by human judgment rather than by the system itself.

Hybrid architectures, not replacement, are where this is heading. The realistic near-term shape of most production systems is going to be a compiled core — a knowledge graph, a Context IR, a set of compiled skills — surrounded by a runtime layer that still does live retrieval and live reasoning for anything the compiler hasn't seen yet, with a feedback loop (much like OVIR's) that promotes recurring runtime patterns into the compiled layer over time. That's a genuinely different system architecture from either "pure RAG" or "static compiled app," and none of the six projects surveyed here have fully solved the hand-off between the two — it's the most interesting open engineering problem in this whole space.

Questions Worth Investigating Further

A few threads this survey raised that I don't think anyone has definitively answered yet:

• Can Context IR become an actual open standard, the way LLVM IR became a de facto standard that multiple frontends and backends independently target? Brian Letort's work is the strongest formal candidate I've seen, but a standard needs more than one implementation before it's a standard rather than one team's convention.
• What does a "linker" look like for compiled knowledge? Traditional compilation has a well-understood step where separately compiled units get combined. None of these systems have a mature answer for merging two independently compiled knowledge graphs or wikis from different teams — Kompile's fuzzy-dedup graph merge and llm-wiki-compiler's page-level merge-on-shared-slug are early, partial answers.
• How do you version and diff a compiled knowledge artifact the way you'd diff a compiled binary or a git commit? Provenance metadata gets you partway there, but "what changed semantically between compile N and compile N+1" is a much harder question for a knowledge graph than for source code.
• Where does the SkCC result generalize? If compiled output really is model-specific — Kimi's optimal format is neutral-to-negative on other models — every layer of this taxonomy, not just skill compilation, probably needs to take model-specific emission seriously rather than assuming one compiled artifact serves every downstream consumer equally well.

The Shape of the Thing

None of the six teams surveyed here cite each other. Kompile doesn't reference kib; the SkCC authors don't cite OVIR; Brian Letort's Context Compilation Theory doesn't cite Kompile's knowledge graph pipeline. That absence of cross-citation is, to me, the most convincing evidence that this is a real convergent trend rather than a marketing narrative — independent teams, working from independent premises (a solo CLI tool, an enterprise platform, a formal theory paper, a Karpathy tweet, a runtime-cost argument, and an academic security paper), arrived at variations of the same architecture: parse, build a typed intermediate representation, run passes over it, emit into one or more targets.

Compilers won because interpreting the same source over and over is wasteful once you know what you're going to do with it often enough to justify the upfront cost. AI systems are rediscovering that the same logic applies to knowledge, to context, and to agent skills — and that a token is, functionally, this era's CPU cycle.

External References

• kib — https://www.kib.dev/
• Kompile — https://www.getkompile.com/
• Brian Letort, "The Missing Layer" (Context Compilation, Part 2) — https://www.brianletort.ai/blog/context-compilation-part-2-missing-layer
• llm-wiki-compiler — https://github.com/atomicstrata/llm-wiki-compiler
• OVIR — https://www.ovir.net/
• Ouyang et al., "SkCC: Portable and Secure Skill Compilation for Cross-Framework LLM Agents" (2026) — https://www.alphaxiv.org/abs/2605.03353v4

Related Posts on DanielKliewer.com

• SOVEREIGN: The Unified Architecture — https://www.danielkliewer.com/blog/2026-03-29-sovereign-synthesis
• Building a Local LLM-Powered Knowledge Graph — https://www.danielkliewer.com/blog/2025-10-19-building-a-local-llm-powered-knowledge-graph
• Local LLM Document Processing Pipeline Blueprint — https://www.danielkliewer.com/blog/2025-03-22-local-llm-document-pipeline-blueprint

Repository: github.com/kliewerdaniel/knowledge-compiler Overview video: NotebookLM

This is not a chatbot. It is a compiler.

Why does an AI system need to rediscover the same knowledge every time it answers a question?

This is the fundamental inefficiency that most knowledge systems silently accept. Every query against a RAG pipeline pays the full cost of retrieval, context assembly, and generation — even when the knowledge domain is static. Even when the question has been asked before. Even when the answer could have been precomputed.

Knowledge Compiler is an exploration of a different tradeoff: what if semantic understanding is performed at compile time instead of runtime? What if the artifacts of that compilation — knowledge graphs, concept hierarchies, vector embeddings, cluster maps — are themselves the deployable unit?

What if a knowledge application can be compiled like software, served from a static CDN, and never touch an LLM at inference time?

I built this to find out.

I. The Runtime Tax

Let's be concrete about the costs that current architectures accept as unavoidable.

Retrieval-Augmented Generation (RAG)

Every query in a standard RAG pipeline:

1. Embeds the query (one API call, ~100-500ms)
2. Searches a vector index (one ANN search, ~10-100ms)
3. Retrieves context chunks (one or more document lookups)
4. Constructs a prompt with the retrieved context
5. Sends the prompt to an LLM (one generation call, ~500ms-5s depending on output length)

Per-query cost: ~1-6 seconds of latency, $0.001-$0.01 in API fees, and one round of GPU inference.

Scale this to an organization processing thousands of queries per day against a stable knowledge base — documentation, legal archives, medical literature, scientific papers — and you are paying the same tax for every single query, even though the underlying knowledge has not changed.

GraphRAG

GraphRAG improves retrieval quality by organizing documents into a graph structure, enabling multi-hop reasoning and community detection. Microsoft's GraphRAG paper demonstrated that graph-based retrieval significantly outperforms naive vector search on complex, sensemaking queries.

But GraphRAG introduces its own runtime costs:

• Query expansion to identify graph-relevant entities
• Graph traversal across multiple hops
• Community summarization at query time (often requiring additional LLM calls)
• Secondary retrieval to fetch supporting evidence

The architectural assumption is the same: intelligence happens at query time.

Agentic Knowledge Systems

The current frontier — multi-agent systems that navigate knowledge bases, break down queries, and synthesize answers — multiplies these costs further. Each agent in the swarm may independently retrieve, reason, and generate. Task decomposition, tool selection, and result synthesis each require LLM calls.

The result is a system that is powerful but expensive, both in latency and in compute.

II. The Compiler Alternative

There is a well-understood precedent for this class of problem.

Software compilers transform source code (human-readable, expressive, redundant) into optimized executables (machine-efficient, pre-analyzed, deployable). The compilation step is expensive. The runtime step is cheap. The fundamental insight is that analysis can be amortized across all executions.

Knowledge Compiler applies this same amortization strategy to knowledge. Instead of analyzing documents at query time, it performs a complete semantic analysis during a build step, producing artifacts that encode the full relational and semantic structure of the knowledge base.

The compiled artifacts are not an index into the source documents. They are a self-contained reasoning substrate.

III. Architecture of the Knowledge Compiler

The compiler is organized as a monorepo with seven packages and one application:

packages/
  ir/          — Intermediate Representation types (Zod schemas)
  config/      — Configuration system (cosmiconfig + Zod validation)
  cache/       — Two-level cache (L1 memory, L2 disk, XXH3 hashing)
  artifacts/   — Artifact serialization (binary embeddings, atomic writes)
  plugins/     — Plugin registry and pass lifecycle interfaces
  core/        — Pipeline engine, scheduler, 23 built-in passes
  cli/         — CLI tool (cac-based), binary: kc
apps/
  web/         — Next.js app for browsing compiled knowledge

The Compilation Pipeline

The pipeline executes 9 phases in sequence, each containing one or more compiler passes. Passes declare dependencies (hard and optional), and the scheduler resolves them via topological sort (Kahn's algorithm).

Source (Markdown)
    │
    ▼
  1. PARSING           Glob resolution → File reading → Frontmatter extraction → MDAST parsing
    │
    ▼
  2. ANALYSIS          Link extraction → Named entity recognition → TF-IDF keywords → Concept hierarchy
    │
    ▼
  3. GRAPH             Knowledge graph construction → PageRank → Graph statistics
    │
    ▼
  4. EMBEDDING         Sentence-level chunking → Vector embedding → Dimensionality reduction
    │
    ▼
  5. CLUSTERING        Similarity matrix → Connected-component clustering → Centroid computation
    │
    ▼
  6. OPTIMIZATION      Edge pruning → SimHash near-duplicate detection → Int8 quantization
    │
    ▼
  7. GENERATION        Artifact serialization → Manifest building
    │
    ▼
  8. COMPLETE          Report aggregation

I'll walk through each phase.

Phase 1: Parsing (4 passes)

GlobResolverPass uses fast-glob to resolve user-specified patterns (default **/*.md) against the base directory, with a manual recursive-walk fallback.

FileReaderPass reads each file asynchronously with SHA-256 content hashing.

FrontmatterParserPass extracts YAML frontmatter using js-yaml, with a hand-written parseSimpleYaml() fallback.

MDASTParserPass parses markdown into an MDAST (Markdown Abstract Syntax Tree) using unified/remark with GFM and frontmatter support. The resulting AST is stored in the IR store as a DocAST:

interface DocAST extends IRGraph<DocNode> {
  sourcePath: string;
  sourceHash: string;
  rootNodeId: UUID;
  totalTokens: number;
  statistics: DocStatistics;
}

Each DocNode tracks its source position (start/end line and column), parent-child relationships, and node-type-specific metadata (heading levels, code language, link URLs, etc.).

Token estimation uses a simple heuristic: Math.ceil(words.length * 1.3). In practice this correlates well with actual token counts for technical prose.

Phase 2: Analysis (4 passes)

LinkExtractorPass walks the AST recursively, classifying links as internal (matching *.md patterns) or external. Internal links become candidates for knowledge graph edges between documents.

EntityExtractorPass performs regex-based named entity recognition against 13 patterns:

• PERSON (with honorific prefixes: Dr., Prof., Sen., etc.)
• ORG (with suffixes: Inc., Corp., LLC, Ltd.)
• LOCATION (known US cities and common locations)
• DATE (full date formats and ISO dates)
• MONEY, EMAIL, URL, PHONE, CODE (constant identifiers)

Entities are deduplicated and ranked by frequency across the document.

KeywordExtractorPass implements classic TF-IDF:

// Tokenization: lowercase, strip non-alphanumeric, filter stop words (100+), min length 3
// TF normalized by max term frequency in document
// IDF: log((N + 1) / (df + 1)) + 1  (smooth IDF)
// Score: TF_norm * IDF
// Return top N by score (default 20 per document)

This is textbook TF-IDF — and that is intentional. It is deterministic, interpretable, and requires no model inference. Given the same document set, it produces identical keyword assignments every time.

ConceptHierarchyPass aggregates entities and keywords into a hierarchical concept graph. Entities with frequency >= 5 become level-0 concepts (broad), frequency >= 2 become level-1, and keywords become level-2 (narrow). This produces an automatic taxonomy without manual intervention:

Level 0: "Machine Learning"  (frequency: 47)
Level 1: "Neural Networks"   (frequency: 12)
Level 2: "transformer"       (keyword)
Level 2: "backpropagation"   (keyword)

Phase 3: Graph Construction (3 passes)

KnowledgeGraphBuilderPass constructs the unified knowledge graph. For each document, it creates document nodes, entity nodes (with type-prefixed IDs like Entity:PERSON:Einstein), and edges representing containment ("document contains entity") and document-to-document links. Entity edges are weighted by frequency. Document-to-document edges use link count as weight.

Node importance is computed as degree / 10 capped at 1.0 — simple linear function of connectivity.

PageRankPass computes standard PageRank scores across the knowledge graph:

PR(v) = (1 - d) / N + d * sum(PR(u) / outDegree(u)) for all incoming neighbors u

Convergence threshold: 1e-6, damping factor: 0.85, max iterations: 100.

GraphStatisticsPass computes:

• Average clustering coefficient: triangle counting per node
• Graph density: 2E / (N * (N - 1))
• Connected components: BFS-based component discovery
• Diameter: BFS from first 1000 nodes (performance limit)

Phase 4: Embedding (3 passes)

TextChunkerPass splits document text into overlapping segments:

Split on sentence boundaries (/[^.!?]+[.!?]+/g)
Accumulate sentences until chunkSize (default 512 chars)
Save chunk with overlap overlap (default 64 chars)
Track character offsets
Estimate tokens: Math.ceil(words * 1.3)

EmbeddingGeneratorPass generates vector embeddings with a graceful fallback chain:

1. Primary: OpenAI Embeddings API (text-embedding-3-small, 1536 dimensions)
2. Fallback: TF-IDF-based pseudo-embeddings

The fallback is worth examining because it enables the entire pipeline to function without any external API key:

function generateTFIDFFallback(text: string, dimensions: number): Float32Array {
  const vec = new Float32Array(dimensions);
  const tokens = tokenize(text);
  const unique = new Set(tokens);
  for (const token of unique) {
    const idx = simpleHash(token) % dimensions;
    vec[idx] += 1 / Math.sqrt(unique.size);
  }
  // L2 normalization
  const norm = Math.sqrt(vec.reduce((s, v) => s + v * v, 0));
  for (let i = 0; i < dimensions; i++) vec[i] /= norm;
  return vec;
}

This produces vectors that are not semantically rich but are deterministic and locally computable. For a knowledge base that is never compared against external documents, they are sufficient for similarity-based clustering.

DimensionReducerPass applies random projection (an approximate PCA) to reduce embeddings from the source dimensionality to 256 dimensions. The projection matrix is sampled from Uniform(-1, 1) scaled by 2/sqrt(targetDim). This is a lossy but fast reduction.

Phase 5: Clustering (3 passes)

SimilarityMatrixPass computes pairwise cosine similarity between all embedding vectors, keeping the top 10 most similar for each vector.

ClusterAssignerPass performs connected-components clustering on the similarity graph (threshold >= 0.1), then merges clusters smaller than minClusterSize (default 5) into the nearest large cluster.

CentroidCalculatorPass computes cluster centroids by averaging member vectors with L2 normalization:

function computeCentroid(vectors: Float32Array[]): Float32Array {
  const centroid = new Float32Array(vectors[0].length);
  for (const vec of vectors) {
    for (let i = 0; i < vec.length; i++) centroid[i] += vec[i];
  }
  const norm = Math.sqrt(centroid.reduce((s, v) => s + v * v, 0));
  for (let i = 0; i < centroid.length; i++) centroid[i] /= norm;
  return centroid;
}

Phase 6: Optimization (3 passes)

PruningPass removes edges below a weight threshold and orphaned nodes. (Currently the threshold is effectively zero — this is the simplest possible pruner.)

DeduplicationPass implements SimHash for near-duplicate detection:

function computeSimHash(text: string): bigint {
  const hash = new Int32Array(64).fill(0);
  const tokens = tokenize(text);
  for (const token of new Set(tokens)) {
    const h = simpleHash(token);
    for (let i = 0; i < 64; i++) {
      if ((h & (1n << BigInt(i))) !== 0n) hash[i]++;
      else hash[i]--;
    }
  }
  return hash.reduce((acc, v, i) => acc | (BigInt(v > 0 ? 1 : 0) << BigInt(i)), 0n);
}

Documents with SimHash similarity >= 0.85 (fraction of matching 64-bit signs) are flagged as near-duplicates. This enables O(n) pairwise comparison via hash bucketing rather than O(n²) brute force.

CompressionPass quantizes Float32 embeddings to Int8, achieving 4x memory reduction:

function quantizeInt8(vector: Float32Array): Int8Array {
  const maxAbs = Math.max(...vector.map(v => Math.abs(v)));
  const scale = 127 / maxAbs;
  return new Int8Array(vector.map(v => Math.round(v * scale)));
}

Edge weights are also rounded to 3 decimal places.

Phase 7: Generation (2 passes)

ArtifactSerializerPass writes the final artifacts to disk:

• knowledge-graph.json — full graph structure
• cluster-graph.json — cluster assignments and centroids
• concept-hierarchy.json — concept taxonomy
• graph-statistics.json — graph metrics

All writes use an atomic write pattern: content is written to a .tmp.{uuid} file, then atomically renamed. This prevents partial artifacts from corrupt reads.

ManifestBuilderPass generates manifest.json with version metadata, configuration snapshot, timing, and SHA-256 hashes of all artifacts for integrity verification.

IV. The Runtime System

The compiled artifacts are designed to be served from any static file server — a CDN, S3 bucket, GitHub Pages, or local filesystem. The Next.js application in apps/web/ is the reference runtime.

The app uses:

• Zustand for client-side state management
• D3 force simulation (forceManyBody, forceLink, forceCenter, forceCollide) for interactive graph rendering
• Framer Motion for animated transitions
• CSS custom properties for dark/light theming

Key pages:

Every page reads from the compiled JSON artifacts. There is no database. There is no API server. There is no LLM call.

The search page, which might appear to require inference, actually searches a pre-built search index that was constructed during the generation phase. The knowledge graph pages render a pre-computed graph structure. The cluster pages show pre-computed cluster centroids and memberships.

Zero runtime inference. Zero backend infrastructure. Zero API costs.

V. What This Changes

The economics of deploying a knowledge application shift dramatically when you remove runtime inference.

Before (standard RAG):

After (compiled knowledge):

The compilation itself is a one-time cost. For my test corpus of 113 markdown documents (a blog archive), compilation takes ~1.5 seconds on a MacBook and produces ~45MB of artifacts.

This is not a marginal improvement. It is a three-order-of-magnitude reduction in operating cost.

VI. Applications

The sweet spot for compiled knowledge is any domain where the knowledge base is structured, bounded, and relatively stable.

Legal research. Law firms maintain vast libraries of case law, statutes, and regulations. These change slowly (annual legislative sessions, occasional court decisions). A compiled knowledge base of a firm's entire practice area could be deployed as an internal tool that associates can query instantly, with no per-search API costs and no data leaving the firm's network.

Medical knowledge systems. Clinical guidelines, pharmaceutical formularies, and treatment protocols are updated on defined cycles. A compiled knowledge base enables clinicians to search across thousands of pages of medical literature without the latency or privacy concerns of cloud-based AI.

Scientific literature. Researchers need to navigate an ever-growing corpus of papers in their field. Pre-compiled knowledge graphs of entire research domains could be distributed as datasets — like annotating an arXiv category with semantic structure.

Enterprise documentation. Internal wikis, runbooks, and technical documentation are the canonical use case: stable content, high query volume, and sensitivity to both latency and cost.

Education. Course materials can be compiled into interactive knowledge bases that students explore. The compiled artifacts can be distributed as static files — no server, no API key, no internet connection required beyond the initial download.

Personal knowledge management. A compiled knowledge base of your notes, research, and writing can be searched and navigated as a locally-hosted static site. Your knowledge, compiled and served from your own machine.

VII. Limitations

I want to be honest about where this approach falls short.

Compiled knowledge is static knowledge. If the source documents change, the artifacts must be regenerated. For rapidly changing domains (news, real-time data, evolving specifications), incremental compilation is the right direction but not yet fully implemented.

No open-ended reasoning. The compiled artifacts encode the relationships present in the source documents. A query that requires inference beyond those relationships — synthesis across unseen connections, analogical reasoning, creative extrapolation — cannot be answered without an LLM. The system can tell you what is in the documents and how things connect, but it cannot reason about what is not there.

Ambiguity and novelty. If a user asks a question that uses terminology not present in the source documents, retrieval degrades gracefully (TF-IDF-based keyword search still works) but will not surface conceptually related but terminologically distant content. An LLM-based system can bridge lexical gaps through semantic understanding in ways that compiled keyword/entity indexes cannot.

Compilation cost at scale. For very large corpora (millions of documents), the compilation step becomes significant. The pairwise similarity computation for clustering is O(n²) in the worst case. Current optimizations (top-10 thresholding, connected components) mitigate this, but the architecture has not been benchmarked at internet scale.

Where runtime LLM reasoning is still better:

• Personal assistant use cases (open-ended conversation)
• Questions requiring real-time information
• Creative synthesis across unrelated domains
• Tasks requiring instruction following or tool use
• Any scenario where the knowledge base is a secondary input rather than the primary domain

VIII. Future Research

Several directions are worth exploring:

Incremental compilation. When a few documents change, the current system recompiles the entire corpus. An incremental mode would detect changes, invalidate affected artifacts, and recompute only the impacted portions of the graph.

Multimodal knowledge artifacts. The IR schema supports arbitrary node types. Extending the parser to handle images, audio transcripts, and video metadata would produce richer knowledge graphs.

Distributed compilation. For large corpora, the compilation pipeline is embarrassingly parallel across documents (parsing, analysis, initial graph construction). The scheduler already supports batch execution — extending this to multi-machine distribution is a natural evolution.

Personalized compiled intelligence. If the compiled artifacts can be composed — merging a domain knowledge graph with a personal knowledge graph — the result is a reasoning substrate that knows both the domain and the user. This moves toward the vision of "Sovereign AI" that I've written about elsewhere: intelligence you own, running on infrastructure you control, making decisions on your behalf using knowledge compiled from your sources.

Active artifact evolution. The current pipeline is write-once, read-many. An evolution layer could incorporate feedback loops — tracking which queries are frequently asked but poorly answered, flagging gaps in the knowledge base, and suggesting document additions.

IX. The Broader Idea

Every knowledge system makes a tradeoff between compile-time and runtime computation.

• Search engines compile inverted indexes at crawl time and serve queries with zero inference.
• Databases compile query plans and maintain indexes; runtime query execution is deterministic.
• CDNs compile edge caches; runtime requests hit hot cache with minimal computation.

AI knowledge systems, by contrast, have largely abandoned compile-time optimization. Every query is treated as a novel reasoning problem, even when it targets a stable knowledge base.

Knowledge Compiler is an experiment in restoring that balance. The hypothesis is that for many knowledge domains — possibly most — the semantic structure can be extracted once, optimized, and deployed. The runtime system then becomes a thin client over a rich, pre-computed artifact.

The experiments so far are promising. On a 113-document corpus, the compiler produces a knowledge graph with 192,000 concept nodes and 1,500 edges, organized into a concept hierarchy, clustered into topic groups, and backed by searchable embeddings — in 1.5 seconds. The result is a deployable knowledge application that requires no server, no API, and no inference budget.

Perhaps the future of AI is not only models that think faster, but systems that learn how to organize knowledge before deployment.

You can explore the source code at github.com/kliewerdaniel/knowledge-compiler. The compiler is MIT-licensed and works entirely offline — no API keys required for the default pipeline.

For readers interested in the broader architecture of local-first intelligence systems, my book Sovereign AI: An Architectural Investigation into Local-First Intelligence covers the full stack, of which Knowledge Compiler is one component.

• Building and Evaluating a Local-First Research Assistant with GraphRAG
• SOVEREIGN: The Unified Architecture
• Breaking Free from ChatGPT
• Inference and the New Geography of Intelligence
• Autodata and the RAM Ecosystem

That gap is a reasoning problem, not a reporting problem. And reasoning problems are exactly what local LLMs plus a knowledge graph are good at, provided you're willing to build the plumbing yourself instead of waiting for a SaaS dashboard to grow a brain.

This post is the specification and MVP plan for the Telemetry Intelligence Engine (TIE) — a local-first GraphRAG system that treats website analytics as a behavioral knowledge graph rather than a spreadsheet, enriches it with local inference, and lets an operator ask it questions in plain language. It's a direct extension of the Dynamic Persona MoE RAG architecture I've written about previously, retargeted at analytics intelligence instead of general knowledge retrieval.

If you've been following the sovereign AI thread on this site, the pattern will be familiar: the information architecture — the graph, the audit trail, the relationships between entities — is the actual product. The model is just the reasoning engine you point at it.

The core idea

Standard analytics tools store events. TIE stores relationships between events, content, and outcomes, and lets an LLM walk that graph to answer questions no dashboard was designed to answer:

• "What topics are attracting the highest-value visitors?"
• "What content pathways lead people toward my projects?"
• "What concepts are underrepresented compared to visitor interest?"
• "What should I write next based on observed knowledge gaps?"
• "Why are visitors leaving after reading certain pages?"

These aren't aggregation queries. They require connecting a visitor's session, to the content they touched, to the topics that content covers, to the conversion events (or lack thereof) that followed — and then reasoning over that structure. That's a graph traversal problem wrapped in a retrieval-augmented generation problem, which is precisely the combination GraphRAG architectures are built for.

Architecture overview

At a high level, the system has four moving parts: a telemetry processor that normalizes raw GA4 exports, a behavioral graph that encodes relationships, a vector store that encodes semantic similarity, and a local RAG analyst that reasons over both.

                GA4 Export
                    |
                    v
           Raw Telemetry JSON
                    |
                    v
           Telemetry Processor
               /            \
              v              v
    Behavioral Graph    Vector Database
    (NetworkX / Neo4j)     (ChromaDB)
              \              /
               v            v
            Local RAG Analyst
           (Ollama / llama.cpp)
                    |
                    v
         Insights + Recommendations

The split between graph and vector store matters. The graph captures explicit structural relationships — this article discusses this topic, this session viewed this page, this page leads to this conversion event. The vector store captures semantic similarity — which graph summaries and content chunks are conceptually close to a given question, even when no explicit edge connects them. Query time uses both: semantic retrieval narrows the search space, then graph traversal pulls in the connected neighborhood the LLM actually reasons over.

Data sources

Analytics data

The initial data source is a GA4 export, normalized into a consistent event schema:

{
  "timestamp": "",
  "event_name": "",
  "page_path": "",
  "session_id": "",
  "user_country": "",
  "device_category": "",
  "traffic_source": "",
  "referrer": "",
  "engagement_time": "",
  "scroll_depth": "",
  "events": []
}

This is deliberately the minimum viable schema. Search Console data, GitHub traffic analytics, newsletter open/click metrics, social referral data, server logs, and error telemetry are all planned as future ingestion sources, but the MVP doesn't need them to prove the architecture out. Get one clean pipe of data flowing before adding more.

Content knowledge layer

The site's existing content — blog posts, project pages, essays — becomes graph entities in their own right, not just URLs that telemetry events point at:

/content
    |
    +-- blog/
    +-- projects/
    +-- essays/

Each document is parsed into a structured entity:

{
  "id": "dynamic_persona_rag",
  "type": "article",
  "title": "Dynamic Persona MoE RAG",
  "topics": ["RAG", "agents", "knowledge graphs"],
  "entities": ["Ollama", "ChromaDB", "LLMs"]
}

This is the piece most analytics tools skip entirely — they know a URL got 1,200 views, but they have no model of what that URL is actually about, or how it relates conceptually to everything else you've published. Without this layer, "what should I write next" isn't answerable at all.

Knowledge graph schema

The schema is organized into three node families, which keeps the graph legible as it grows instead of collapsing into an undifferentiated blob of "things."

Content nodes: Article, Project, Page, Repository, Topic, Keyword, Technology

User behavior nodes: Visitor Segment, Session, Traffic Source, Device Type, Conversion Event

Analytical nodes: Hypothesis, Recommendation, Opportunity, Knowledge Gap, Trend

That third category is the important one and the one most graph-based analytics prototypes leave out. Most systems model content and behavior; few model the analysis itself as first-class graph entities. Making hypotheses and recommendations nodes — rather than throwaway text in a report — means the system can later reason about which hypotheses it already tested, which recommendations it already made, and whether outcomes changed after implementation. That's what makes the self-improving loop in Phase 5 possible at all.

Relationships

The edges are what turn a pile of nodes into something queryable:

Visitor --viewed--> Article
Article --discusses--> Topic
Topic --related_to--> Project
Article --leads_to--> Conversion

And behavior paths chain these into traversable sequences:

Google Search
      |
      v
Ollama Article
      |
      v
Dynamic Persona RAG
      |
      v
GitHub Click

A path like this is exactly the kind of thing a traditional funnel report approximates with drop-off percentages, but a graph traversal states explicitly: this session entered through this search query, read this article, followed an internal link to this project page, and then clicked out to the repository. Once paths like this are graph-native, you can ask the LLM to generalize across hundreds of them and surface the pattern rather than eyeballing a funnel chart.

LLM enrichment pipeline

Raw telemetry is not semantic. "1,200 views, 240 seconds average time on page" doesn't mean anything on its own — it needs an interpretive layer between the raw numbers and the graph. That's the job of the enrichment pipeline, run locally, in three stages.

Stage 1 — Event summarization. Convert raw aggregates into a plain-language characterization:

// input
{"page": "/projects/rag", "views": 1200, "time": 240}

// output
{"meaning": "High-interest technical content attracting AI engineering audience"}

Stage 2 — Entity extraction. Pull structured topics, audience, and intent out of content and behavior:

Topics:
- AI Agents
- Retrieval Systems
- Local Inference
Audience:
- Developers
- Researchers
Intent:
- Technical exploration

Stage 3 — Relationship discovery. Propose new graph edges with a stated rationale, rather than silently inserting them:

Dynamic Persona RAG
  related_to
Knowledge Graphs
  because: Both discuss structured information retrieval

That "because" clause is worth keeping even in the MVP. Auto-discovered relationships are only trustworthy if you can audit why the model proposed them, and treating human approval as optional (rather than absent) keeps a review checkpoint available without making it mandatory for every low-stakes edge.

Vector database layer

ChromaDB is the right starting point — embedded, zero-ops, good enough for a single-operator dataset — with a clear migration path to Qdrant if the corpus outgrows it. Four collections cover the retrieval surface:

• analytics_events — embedded event summaries from Stage 1
• content_embeddings — embedded article/project content
• graph_summaries — embedded natural-language descriptions of graph neighborhoods
• recommendations — embedded past recommendations, for de-duplication and outcome tracking

Note that graph_summaries is doing something specific: it's not embedding raw content, it's embedding natural-language renderings of graph structure ("the visitor journey from local AI article to RAG project"), so that semantic search can retrieve structurally relevant neighborhoods even when the query doesn't share vocabulary with the underlying nodes.

The RAG query flow

When the operator asks a question, retrieval and reasoning happen in sequence, not in parallel:

Question
   |
   v
Semantic Retrieval  (vector search across the four collections)
   |
   v
Relevant Graph Neighborhood  (expand from retrieved nodes via graph edges)
   |
   v
LLM Reasoning  (local model reasons over the assembled context)
   |
   v
Answer

The semantic retrieval step is doing coarse filtering — find the handful of nodes and summaries plausibly relevant to the question — and the graph expansion step is doing precision — pull in everything structurally connected to those anchor nodes so the model isn't reasoning from disconnected fragments. This two-stage retrieval is the same pattern behind most production GraphRAG systems, and it's worth keeping distinct rather than collapsing into a single vector search, because pure similarity search will miss structurally important but semantically dissimilar neighbors (a conversion event rarely shares vocabulary with the article that led to it).

Analytical personas

If you've already built a persona-routing layer for a general RAG system, this reuses it directly — just with narrower, analytics-specific mandates instead of general-purpose ones.

SEO Analyst — focuses on impressions, rankings, search intent, and missing content. Output example: "Create article: Running Local AI on Apple Silicon."

Product Analyst — focuses on conversions, funnels, and user intent. Output example: "Add stronger CTA after technical articles."

Research Analyst — focuses on conceptual relationships between topics. Output example: "Knowledge gap: AI agents ↔ knowledge graphs."

UX Analyst — focuses on user journeys and friction. Output example: "Mobile visitors abandon project pages. Investigate animation performance."

Splitting these into distinct personas rather than one general-purpose analyst matters for the same reason it matters in any MoE-style routing setup: each persona has a narrow, well-defined lens, which keeps its outputs consistent and makes the recommendation engine's downstream categorization trivial — the persona that generated a recommendation already tells you what kind of action it implies.

The recommendation engine

Recommendations aren't generated directly from raw data. They pass through three explicit layers, each stored as its own graph entity:

Observations — facts pulled straight from the graph and telemetry:

Dynamic Persona RAG:
400 visitors
8 minute average reading time

Hypotheses — reasoned conclusions drawn from observations:

Technical architecture content attracts highly engaged visitors.

Actions — concrete recommendations derived from hypotheses:

Create navigation path:
RAG Article → Project Demo → GitHub

Keeping these three layers separate — rather than jumping straight from raw numbers to a recommendation — is what makes the system auditable. If a recommendation turns out to be wrong, you can trace it back to the hypothesis that produced it, and from there to the observation that produced the hypothesis, instead of treating the LLM's output as an opaque verdict.

Automated reports

Weekly, the system generates a structured report:

Telemetry Intelligence Report
1. New Trends
2. Visitor Behavior Changes
3. Content Opportunities
4. Technical Problems
5. Recommended Experiments

stored under /reports, e.g. 2026-07-09-analysis.md. The detail worth calling out: these reports are written back into the corpus and become RAG documents themselves. Over time, the system isn't just analyzing telemetry against static content — it's analyzing telemetry against its own accumulated history of analysis, which is what makes the self-improving loop in Phase 5 possible instead of aspirational.

Technology stack

Already in place:

• Frontend: Next.js, TypeScript, Tailwind
• Backend: Python, FastAPI
• AI: Ollama, llama.cpp, Qwen models
• Storage: SQLite, ChromaDB, NetworkX

Planned:

• Graph database: Neo4j (once NetworkX's in-memory model stops scaling)
• Observability: OpenTelemetry
• Analytics: PostHog (as a richer telemetry source than GA4 alone)

Starting with NetworkX instead of Neo4j is the right call for an MVP — no server to run, no schema migrations, and a graph small enough (a single site's worth of content and sessions) to fit comfortably in memory. The migration path exists precisely because it's a migration path, not a requirement to solve on day one.

MVP build plan

Phase 1 — Telemetry ingestion. Export GA4 data, normalize it to the JSON schema above, store it locally, and define the initial schema. This phase has one job: get data flowing end to end before anything gets clever.

Phase 2 — Graph construction. Create nodes and relationships from the normalized data, and produce a visualized output (website_behavior_graph.html) so you can eyeball whether the graph structure actually matches your mental model of the site before trusting an LLM to reason over it.

Phase 3 — RAG layer. Embed graph summaries, stand up the ChromaDB collections, and wire in the local model for retrieval.

Phase 4 — Analyst agent. Build the TelemetryAgent with three capabilities: query analytics, explain trends, and generate recommendations. This is the first point where the system is actually answerable-to in natural language.

Phase 5 — Self-improving loop. Close the loop:

Recommendation
      |
      v
Implement change
      |
      v
Measure outcome
      |
      v
Update confidence

This is the phase that turns TIE from a smart reporting tool into something closer to a research collaborator — it doesn't just recommend a change, it tracks whether the change worked and adjusts how much weight to give similar future hypotheses.

What success looks like

The bar isn't "can it summarize my traffic." Standard dashboards already do that well enough. The bar is whether the system can produce something like this, unprompted, from the graph structure alone:

"Visitors interested in local AI are not finding my business offerings. They are reading technical posts but never reaching the services page. Create a bridge article connecting these concepts."

That's a claim about a missing edge in the behavioral graph — a content gap identified not by keyword volume, but by the shape of the paths visitors actually take (or fail to take) through the site. A standard analytics dashboard can tell you the services page has low traffic. It cannot tell you why, or what to write to fix it. That's the difference between reporting on the past and reasoning about the system well enough to change its future.

I go deeper into the underlying architecture — the persona routing, the memory layers, and the broader case for treating your own information architecture as sovereign infrastructure rather than a rented dashboard — in Sovereign AI: Building Local-First Intelligent Systems, available on Amazon. If you're building something similar, I'd like to hear about it.

Intelligence is not the model. Intelligence is the accumulated decisions that shaped the model.

The Sovereign Intelligence Stack is a production-ready architecture for building sovereign AI systems. But how fast does it actually run? How much headroom does it have for real workloads? And how does it compare to alternative approaches?

I benchmarked every critical component to answer these questions. The results exceed expectations and validate the architectural decisions made across four years of development.

The Benchmarks

Recipe Compiler (Layer 1)

Key insight: The Recipe Compiler handles 1,375 structured decision records per second with full metadata, relationships, and versioning. That's 82,500 decisions per minute — or 120 days of continuous AI activity captured in a single second.

At the scale of a typical knowledge worker's daily usage (~500 decisions/day), the system can process 2.75 years of activity in one second. The SQLite backend provides durability without sacrificing throughput.

Signal Router (Layer 2)

Signal distribution:

• Cheap: 66.67% (simple tasks)
• Expert: 16.67% (complex tasks)
• Hybrid: 16.66% (multi-stage)

Key insight: Signal classification operates at 1.2M decisions per second. The routing decision (1.3μs) is dominated by Python overhead — in practice, this is effectively instantaneous.

A system processing 10,000 tasks per minute (already extremely high) would spend only 0.0017% of its time on routing decisions.

Evaluation Loop (Layer 3)

Key insight: Test generation operates at 1.7M cases per second. The drift detector provides real-time anomaly detection across all evaluation signals without impacting production throughput.

Comparative Analysis

Recipe Compiler vs. Alternative Systems

The Sovereign Stack operates at 20-40% of raw database throughput. This is the overhead of metadata management, relationship tracking, versioning, and the Recipe dataclass — an excellent tradeoff for structured, queryable, versioned decision records.

Signal Router vs. Traditional Rule Engines

The Signal Router is 15-7,500x faster than traditional rule engines because it operates on in-memory Python dataclasses with no serialization overhead.

Evaluation Loop vs. Manual Testing

The autonomous evaluation loop operates at speeds that make manual testing obsolete. The system can evaluate its own quality continuously without human intervention.

Scalability Projections

The system has massive headroom for typical workloads. The Python GIL becomes the bottleneck only at extremely high scales (>1M tasks/min), at which point parallelization via multiprocessing would address the issue.

Conclusions

The Sovereign Intelligence Stack meets and exceeds performance requirements for sovereign AI workloads:

• ✅ Sub-millisecond recipe compilation (>1,000/sec)
• ✅ Microsecond-level signal routing (>750,000/sec)
• ✅ Microsecond-level test generation (>1.7M/sec)
• ✅ Real-time drift detection (33,912 checks/sec)

These results validate the architectural decisions: SQLite for durability without throughput penalty, in-memory classification to eliminate serialization overhead, and dataclass-based design to avoid ORM overhead.

Related Posts

• Sovereign AI Architecture — The full architecture
• The Sovereign Intelligence Stack — Architecture with working code
• The Model Is Not the Product — Why intelligence is the loop, not the model

References

• Benchmark Report — Full technical report with methodology
• Benchmark Code — Reproducible benchmark suites

July 6, 2026

The most capable coding agents right now aren't the ones with the single best model. They're the ones where the model and the harness were built for each other — Claude Code paired to Claude, Codex paired to GPT-5, OpenCode paired to whatever open model it's been tuned against that week. Arize AI's Aparna Dhinakaran has been writing about the failure mode this produces: every agent harness eventually runs into the same wall, where the context window is too small for everything a long session wants to remember, and file reads, subagent calls, and tool output all compete for the same shrinking budget (Context Management in Agent Harnesses). Her fix is architectural — manage what the harness keeps in view, not just what the model can technically hold.

That's a real insight. But it also points at something bigger than any one harness: the tighter a harness and a model are fused, the more of the stack you don't actually own.

This week that tension became concrete in hardware. Zhipu AI's GLM-5.2 — a 753-billion-parameter, MIT-licensed, 1-million-token-context model built specifically for agentic coding work — is now runnable on a single workstation you could build yourself (GLM-5.2 overview). Not a research demo. A documented, repeatable bill of materials. And it landed two days after Washington ordered Anthropic to cut off foreign access to its Fable 5 and Mythos 5 models — open weights shipping into the exact gap that export controls create.

That's not a coincidence worth glossing over. It's the argument for owning your own stack, made concrete in real time.

The Three Layers, and Which One Is Actually Yours

The current AI stack has three layers, and only one of them compounds in your favor:

Layer 1: The Model. Qwen3.6, GLM-5.2, DeepSeek V4, Claude, GPT-5. The foundation, and the layer commoditizing fastest.

Layer 2: The Harness. Claude Code, Codex, OpenCode, DeerFlow. The agent wrapper that turns raw inference into planning, tool use, and multi-step execution.

Layer 3: The Sovereign Stack. Your recipe compilation, signal routing, and autonomous evaluation — the layer that decides how the first two layers get used, and the only one that's still yours after a vendor changes its pricing, its terms of service, or its export eligibility.

Here's what's actually happening to each layer in mid-2026:

Independent benchmarking from Artificial Analysis already ranks GLM-5.2 as the strongest openly available model on its agentic Intelligence Index, ahead of MiniMax-M3, DeepSeek V4 Pro, and Kimi K2.6, and within a few points of Claude Opus 4.8 on long-horizon coding benchmarks like Terminal-Bench and SWE-bench Pro — at roughly a sixth of the inference cost of a comparable closed model (GLM-5.2 vs. GPT-5.5, benchmark deep-dive). Layer 1 is being commoditized from the outside, by a lab that doesn't answer to U.S. export policy.

Layer 2 is fragmenting along vendor lines, exactly as Dhinakaran's harness research describes — and even the open entrants are converging on the same pattern. ByteDance's DeerFlow rewrote itself from a research framework into a general-purpose "SuperAgent" runtime built on LangGraph, with isolated per-subtask context and a persistent sandboxed workstation for long-horizon execution — I wrote about that architecture in detail back in March (DeerFlow 2.0). It's a harness. It's excellent. It is still, structurally, someone else's opinion about how your agent should think.

Layer 3 — the recipe compiler, the signal router, the evaluation loop — is the only layer where every decision you make feeds the next one. That's the compounding loop, and it's the whole thesis of the Sovereign Intelligence Stack.

GLM-5.2 on Your Own Hardware: What It Actually Takes

Let's get concrete, because vague sovereignty talk is cheap and a parts list isn't.

James O'Beirne's local-llm build guide, updated for July 2026, documents exactly this: a two-tier local stack running Qwen3.6-27B at the affordable end and GLM-5.2 at the frontier end (jamesob/local-llm). The GLM-5.2 tier runs on four NVIDIA RTX PRO 6000 Blackwell Workstation GPUs — 384GB of VRAM total — connected through a PCIe Gen4 switch from c-payne.com rather than exotic (and currently very expensive) PCIe Gen5 hardware. The switch lets the GPUs talk to each other directly during the all-reduce step of tensor parallelism instead of routing everything through the CPU's root complex, which is what makes multi-card inference tolerable without NVLink.

The published bill of materials: an ASRock Rack ROMED8-2T motherboard, an AMD EPYC Milan processor, 128GB of DDR4 ECC memory, dual redundant PSUs, and NVMe storage for weights, totaling roughly $5,600 before GPUs. The four RTX PRO 6000 cards add somewhere in the $46,000 range at current pricing — though as one Hacker News commenter on the guide pointed out, GPU pricing has been volatile enough this year that the real number is closer to $50–55K by the time you actually buy the cards (HN discussion). That's the honest range, not the marketing one.

What you get for it: GLM-5.2 served through vLLM in Docker, fronted by opencode, with speculative decoding pushing throughput into workable territory at large context sizes — independent community benchmarking on this same RTX PRO 6000 class of hardware puts multi-GPU GLM-5-family decode speed in the tens of tokens per second once you're past 100K+ tokens of context, which is the regime that actually matters for agentic coding sessions, not synthetic single-turn numbers (RTX 6000 Pro community wiki).

O'Beirne's own setup — what he calls the "clankhouse" — pairs the inference box with a sandboxed VM running opencode sessions, one tmux session per project directory, a private Gitea instance for issue tracking, and a Telegram bot for interactive check-ins. The agent can work with him directly or get farmed off to file PRs against Gitea issues on its own. The only channel out of the VM is a shared filesystem mount. That's not a toy — it's a production pattern for running an agent you actually control, end to end, without a subscription standing between you and your own workflow.

If $50K sounds steep, it isn't the entry price. Qwen3.6-27B is genuinely capable on a $2K pair of consumer GPUs, and that tier is where most people should start. The point isn't that everyone needs the frontier rig. The point is that the frontier rig now exists, is documented, and is buildable by one person in a weekend — which was not true a year ago.

Context Engineering Became Agent-Harness Engineering

If local inference is the hardware half of sovereignty, context engineering is the software half — and it's changed shape faster than most people have noticed.

Two years ago, "context engineering" meant writing better prompts. The dair-ai Prompt Engineering Guide, still one of the most widely used references in the field, has expanded well past prompting into full guides on RAG and agent design, running its own accompanying courses because the underlying discipline outgrew the original scope of prompt templates (dair-ai/Prompt-Engineering-Guide). Cole Medin's context-engineering-intro template made the sharper claim explicit: context engineering is what actually makes AI coding assistants work, as distinct from just writing clever instructions — it's about giving the assistant the examples, rules, and structured requirements it needs to finish a feature end to end, not just a good prompt to start with (coleam00/context-engineering-intro).

By 2026, even that framing is downstream of something bigger. The Awesome-Context-Engineering survey now argues the center of gravity has moved from "how do you pack the best prompt" to how an agent harness manages runtime state across an entire session — memory, tool calls, subagent checkpoints, sandboxes, human approval steps (Meirtz/Awesome-Context-Engineering). In other words: context engineering didn't get replaced. It got absorbed into harness design, which is exactly the layer-2 problem Dhinakaran keeps writing about and exactly the layer your own pipeline has to own if you don't want a vendor's harness making that call for you.

This is the part of the sovereignty argument that's easy to miss if you're only looking at model benchmarks. The bottleneck was never raw model capability. It's which context the system decides to keep, discard, and re-derive across a long session — and whether you're the one making that decision or a closed harness is making it for you.

The Compounding Loop

Here's the actual thesis, stated once and not repeated three different ways: models commoditize, harnesses lock you in, and the only thing that compounds in your favor is the layer that decides how the first two get used.

A Recipe Compiler turns your decisions into structured, reusable specs instead of one-off prompts. A Signal Router decides which context, which model, and which tool gets invoked for a given task. An Autonomous Evaluation Loop checks the output against your own objectives, not a vendor's benchmark suite. Every recipe you compile improves what the router has to work with. Every evaluation you run improves the next recipe. None of that requires a specific model — which means none of it disappears when a model gets deprecated, re-priced, or geofenced by an export control.

That's why GLM-5.2 running locally at frontier-adjacent quality matters less as "a cool benchmark" and more as proof of the underlying claim: the model layer is now interchangeable enough that betting your architecture on any single vendor's model-harness pair is the actual risk, not the caution.

Where I've Written the Whole Argument Down

This post is the six-month version of an argument I've been making in blog posts, in my Sovereign Intelligence Stack, and now in longer form in Sovereign AI: Building Local-First Intelligent Systems, my book on Amazon.

I wrote it because everything above — the RTX PRO 6000 build, the vLLM serving stack, the context-engineering shift, the compounding loop — is exactly the kind of thing that's scattered across GitHub READMEs, Discord threads, and blog posts that go stale in a month. The book is the version that doesn't assume you already know what a KV cache is or which quantization format your hardware actually supports.

It's 72 pages, working code included, and it walks through the stack in the order you'd actually build it:

• Why cloud-dependent AI is a trap, and what it actually costs you in control, not just money
• Running local models with Ollama and llama.cpp, and the quantization tradeoffs nobody puts in the marketing copy
• Structured knowledge — building the knowledge graphs that make an agent's reasoning inspectable instead of a black box
• Retrieval with ChromaDB and local embeddings, no API calls required
• Agents that perceive, reason, and act, and how to keep them auditable
• Connecting your agents to the outside world through MCP servers
• Shipping the whole thing as a real Django + Next.js application
• Dynamic expert selection, evaluation, and hardening the system once it's live

If this post made the case for why the sovereign stack is the layer that matters, the book is where I show you how to build one. It's available now on Amazon: Sovereign AI: Building Local-First Intelligent Systems.

Sources

• Dhinakaran, A. "Context Management in Agent Harnesses." Arize AI.
• O'Beirne, J. "local-llm: Everything I know about running LLMs locally." GitHub, 2026.
• "GLM-5.2 Just Beat GPT-5.5 at a Sixth of the Cost." Labellerr, 2026.
• "Understanding GLM 5.2 Beyond the Headlines." Machine Learning Made Simple, 2026.
• "GLM-5.2: China's Zhipu AI Beats Even Google's Top Models With Its New Open LLM." Trending Topics, 2026.
• local-inference-lab. "RTX 6000 Pro Wiki." GitHub, 2026.
• dair-ai. "Prompt-Engineering-Guide." GitHub.
• Medin, C. (coleam00). "context-engineering-intro." GitHub.
• Meirtz. "Awesome-Context-Engineering." GitHub, 2026.
• Kliewer, D. "DeerFlow 2.0: Building Sovereign AI Agent Systems with Local-First Architecture." danielkliewer.com, March 26, 2026.

Start small. Capture one recipe. Then watch the loop compound.

By Daniel Kliewer
Published: July 5, 2026
Reading Time: 15 minutes
Prerequisites: None (beginner to advanced)
This post is a beginner on-ramp — it defines terms and walks you through your first recipe capture. For the full sovereign AI architecture (5-layer stack, compounding intelligence, research validation), see the Sovereign AI Architecture pillar.

Executive Summary

This post is the zero-to-one on-ramp: it defines the three core concepts of sovereign AI (recipe compilation, signal routing, autonomous evaluation) in plain language, then walks you through capturing your first recipe in five steps using the Sovereign Intelligence Stack. If the Sovereign AI Architecture pillar is the full five-layer reference, this is the page you read first — no prerequisites, no code dumps, just the mental model you need before you start building.

What you'll learn:

• What sovereign AI is (and isn't)
• What recipe compilation means
• What signal routing means
• What autonomous evaluation means
• How to get started with the Sovereign Intelligence Stack
• Where to find more advanced resources

Ready for the full architecture? See the Sovereign AI Architecture pillar for the complete 5-layer stack, compounding intelligence design, and research validation.

What is Sovereign AI?

Sovereign AI is the idea that intelligence is not the model. Intelligence is the accumulated decisions that shaped the model.

This means:

• The model is just a snapshot of past decisions
• The loop is what keeps accumulating
• Systems that don't capture decisions are building castles on sand
• Compounding intelligence requires capture, evaluation, and storage

What Sovereign AI Is NOT

• Not just local LLMs — Local LLMs are a component, not the whole system
• Not just agent frameworks — Agent frameworks are tools, not architecture
• Not just RAG — RAG is retrieval, not intelligence
• Not just prompts — Prompts are inputs, not decisions

What Sovereign AI IS

• A compounding system — Gets smarter over time
• A recipe-based system — Captures decisions as immutable records
• A sovereign system — No cloud APIs required, data stays local
• An observable system — Every decision produces a timeline event

Key Concepts

Recipe Compilation

Definition: Capturing AI decisions as immutable records.

Why it matters: Without recipes, you have no history. You have no way to know why a model made a decision, what memory it used, what the outcome was.

What a recipe captures:

• Objective — What was the task?
• Model — Which model was used?
• Memory — What memory was injected?
• Prompt — What was the prompt (with versioning)?
• Reasoning Patterns — What reasoning patterns were used?
• Evaluation — How was it evaluated?
• Result — What was the result?
• Timestamp — When was it captured?

Example:

@dataclass
class Recipe:
    objective: str
    model: str
    memory_snapshot: Optional[str] = None
    prompt: Optional[str] = None
    reasoning_patterns: List[str] = field(default_factory=list)
    evaluation_score: Optional[float] = None
    outcome: str = "unknown"
    timestamp: datetime = field(default_factory=datetime.now)
    tags: List[str] = field(default_factory=list)

Signal Routing

Definition: Classifying incoming tasks and routing them through optimal evaluation paths.

Why it matters: Not all tasks are created equal. Simple tasks should be routed to fast, lightweight models. Complex tasks should be routed to capable models with full context.

Signal Types:

• Cheap — Simple tasks routed to fast, lightweight models
• Expert — Complex tasks routed to capable models with full context
• Hybrid — Tasks that benefit from multi-stage evaluation

Autonomous Evaluation

Definition: Self-improving loops that generate tests, evaluate performance, and detect drift.

Why it matters: Without evaluation, you have no way to know if your system is improving or degrading. Drift detection catches performance regressions before they compound.

Components:

• Signal Registry — Define what to evaluate
• Test Generator — Generate synthetic test cases
• Drift Detector — Detect performance drift (KS and PSI statistics)
• Loop Controller — Autonomous evaluation scheduling

How to Get Started

Step 1: Install the Sovereign Intelligence Stack

# Clone the repository
git clone https://github.com/kliewerdaniel/sovereign-intelligence-stack.git
cd sovereign-intelligence-stack

# Create virtual environment
python -m venv .venv
source .venv/bin/activate

# Install dependencies
pip install -e .

Step 2: Capture Your First Recipe

from src.recipe_compiler.models import Recipe
from src.recipe_compiler.storage import RecipeStorage

storage = RecipeStorage("my_stack.db")

recipe = Recipe(
    objective="Generate error handler for API calls",
    model="gpt-4",
    outcome="accepted",
    evaluation_score=0.92,
    tags=["error_handling", "api", "reliability"]
)

storage.create_recipe(recipe)
print(f"Recipe captured: {recipe.id}")

Step 3: Run the Full Pipeline

from src.integration.pipe import SovereignPipeline, PipelineConfig

config = PipelineConfig(db_path="intelligence.db")
pipeline = SovereignPipeline(config)
pipeline.initialize()

# Capture a recipe
recipe = Recipe(
    objective="Optimize database query",
    model="claude-2",
    outcome="accepted",
    evaluation_score=0.87,
    tags=["optimization", "database"]
)
result = pipeline.capture_recipe(recipe)

# Get intelligence summary
summary = pipeline.get_intelligence_summary()
print(summary)

Step 4: Run Autonomous Evaluation

from src.evaluation.loop import EvaluationLoop, LoopConfig

config = LoopConfig(
    signal_names=["code_correctness", "performance", "reliability"],
    test_count=50,
    interval_seconds=60
)
loop = EvaluationLoop(recipe_storage, config)
loop.start()

Step 5: Explore the Intelligence Observatory

from src.observatory.timeline import IntelligenceTimeline

timeline = IntelligenceTimeline(recipe_storage)
timeline.record_event(IntelligenceEvent(
    type="recipe_captured",
    recipe_id=recipe.id,
    timestamp=datetime.now()
))

# Get timeline
events = timeline.get_timeline(days=30)
for event in events:
    print(f"{event.timestamp}: {event.type} - {event.recipe_id}")

What's Next?

Start Here

1. Read the Sovereign AI Architecture pillar — The complete 5-layer stack, design principles, and research validation

For Beginners

1. Read the Sovereign Intelligence Stack post — Deep dive into the 5-layer architecture
2. Read the Model Is Not the Product post — Research validation and convergence

For Intermediate Readers

1. Read the Sovereign Memory Bank post — 7-layer memory system
2. Read the Dynamic Persona MoE RAG post — Persona-driven retrieval
3. Read the SovereignSpec post — Spec-driven development

For Advanced Readers

1. Read the Loop Is the Product post — Intelligence Observatory deep dive
2. Read the Autonomous Sovereign AI post — Autoresearch loops and expert fine-tuning
3. Contribute to the sovereign-intelligence-stack repository

FAQ

Is this just local LLMs?

No. Local LLMs are a component. Sovereign AI is the entire architecture: capture, route, evaluate, store, observe.

Do I need to use Ollama?

No. The stack works with any model provider (OpenAI, Anthropic, local LLMs, etc.). Ollama is just one option.

Is this production-ready?

Yes. The stack has 70 Python files, 7,757 lines of code, and 26 modules verified. It's used in production for autonomous research and expert fine-tuning.

Can I use this for my own projects?

Yes. The stack is open-source (MIT license). You can use it for any project, commercial or non-commercial.

What's the difference between this and CrewAI?

CrewAI is a multi-agent framework. The Sovereign Intelligence Stack is a compounding intelligence system that captures decisions, routes tasks, evaluates autonomously, stores knowledge, and observes patterns. It's the operating system that makes all of these pieces work together.

References

Related Posts

• Sovereign AI Architecture — Full 5-layer architecture, compounding intelligence, research validation (the pillar)
• The Sovereign Intelligence Stack — Architecture deep dive
• The Model Is Not the Product — Research validation
• The Loop Is the Product — Companion post
• Building Autonomous Sovereign AI — Autonomous evaluation
• Local AI Architecture — Local AI guide
• Retrieval Architecture — Retrieval guide

Related Repositories

• sovereign-intelligence-stack — Working code
• Sovereign Memory Bank — Memory system
• Dynamic Persona MoE RAG — Retrieval system
• Objective05 — Persistent infrastructure
• SovereignSpec — Spec-driven development

Research Papers

• Residual Context Diffusion Language Models (Hu et al., 2026) — Apple research
• SGLang (LMSYS, UC Berkeley) — Agentic execution graphs
• Context Engineering (13.5K stars) — Systematic replacement for vibe coding
• Agent Harnesses (ECC 225K + Superpowers 244K stars) — Operating system layer for agents
• Persistent Memory (Claude Mem, 85K stars) — Stateful agent collaboration
• Multi-Agent Orchestration (CrewAI, 55K stars) — Collaborative intelligence
• Spec-Driven Development — Structured specifications (117K stars ecosystem)
• GraphRAG (Microsoft, 70K+ stars) — Knowledge graph retrieval
• The Sovereign Intelligence Stack
• The Model Is Not the Product
• The Loop Is the Product
• Building Autonomous Sovereign AI
• Sovereign Memory Bank
• Dynamic Persona MoE RAG
• SovereignSpec

Related Repositories

• sovereign-intelligence-stack
• Sovereign Memory Bank
• Dynamic Persona MoE RAG
• Objective05
• SovereignSpec

Published July 5, 2026 by Daniel Kliewer
License: MIT

The hardware is the contract. The model is the commodity. The loop is the only thing that compounds.

By Daniel Kliewer
Published: July 5, 2026
Reading Time: 20 minutes
Prerequisites: None (beginner to advanced)
This post focuses on local inference infrastructure — Ollama, hardware selection, and running models on your own machine. For the full sovereign AI architecture (5-layer stack, compounding intelligence, research validation), see the Sovereign AI Architecture pillar.

Executive Summary

This post is about the physical infrastructure layer that sovereign AI runs on — not the architecture itself, but the hardware and inference stack you need to own it. If the Sovereign AI Architecture pillar describes what a compounding intelligence system does, this post covers how to build the machine that runs it: Ollama for local inference, model selection tradeoffs, hardware requirements from a $2K consumer rig to a $50K multi-GPU workstation, and how to wire local inference into the sovereign pipeline so your data never leaves your possession.

What you'll learn:

• Why local AI matters (sovereignty, privacy, cost, performance)
• How to install Ollama and run your first local model
• Hardware requirements from $2K consumer rigs to $50K workstations
• How local inference connects to context engineering and the Sovereign Intelligence Stack

Want the full architecture? See the Sovereign AI Architecture pillar for the complete 5-layer stack, compounding intelligence design, and research validation.

Why Local AI?

Sovereignty

Cloud AI: Your data goes to someone else's servers. You don't own it. You don't control it. You can't take it with you.

Local AI: Your data stays on your hardware. You own it. You control it. You can take it with you.

Privacy

Cloud AI: Your prompts, responses, and decisions are stored on remote servers. They can be accessed by third parties, used for training, or leaked in breaches.

Local AI: Your data never leaves your machine. No third-party access. No breaches. No training.

Cost

Cloud AI: Pay per token. Pay per API call. Pay per inference. Costs compound over time.

Local AI: Pay once for hardware. Run indefinitely. Costs are fixed.

Performance

Cloud AI: Latency depends on network. Availability depends on service uptime.

Local AI: No network latency. Always available. Always running.

The Local AI Stack

Layer 1: Ollama

Purpose: Run local LLMs with a simple, unified API.

Key Features:

• Unified API — One API for all models
• Model Library — Pre-built models for common tasks
• Quantization — Optimize models for your hardware
• Streaming — Real-time token streaming
• Multi-Model — Run multiple models simultaneously

Example:

# Pull a model
ollama pull llama3

# Run a model
ollama run llama3 "What is sovereign AI?"

# Use in code
curl http://localhost:11434/api/generate -d '{
  "model": "llama3",
  "prompt": "What is sovereign AI?"
}'

Why Ollama?

• Simple, unified API
• Pre-built models for common tasks
• Optimize models for your hardware
• Run multiple models simultaneously

Layer 2: Context Engineering

Purpose: Systematically manage context for local LLMs.

Why it matters: Context is the most expensive part of local AI. Bad context = bad results. Good context = good results.

Components:

• Context Templates — Reusable context templates
• Context Optimization — Optimize context based on performance
• Context Analysis — Analyze context effectiveness
• Context Condensation — Condense context to fit token budgets

Code Example:

from src.context.engineering import ContextTemplate, ContextOptimizer

template = ContextTemplate(
    role="You are a helpful assistant.",
    system="You specialize in sovereign AI architecture.",
    examples=[
        {"input": "What is sovereign AI?", "output": "Intelligence is not the model..."}
    ]
)

optimizer = ContextOptimizer()
optimized_context = optimizer.optimize(template, max_tokens=4096)

Why Context Engineering?

• Reusable context templates
• Optimize context based on performance
• Analyze context effectiveness
• Condense context to fit token budgets

Layer 3: Sovereign Intelligence Stack

Purpose: Compounding intelligence system for local AI.

Why it matters: Local AI without compounding is just local inference. The Sovereign Intelligence Stack adds capture, routing, evaluation, storage, and observation.

Components:

• Recipe Compiler — Capture AI decisions as immutable records
• Signal Router — Classify tasks and route to optimal evaluation paths
• Evaluation Loop — Autonomous self-improvement with drift detection
• Knowledge Systems — Graph + vector store + persistent memory
• Intelligence Observatory — Timeline, patterns, observability

Code Example:

from src.integration.pipe import SovereignPipeline, PipelineConfig

config = PipelineConfig(db_path="intelligence.db")
pipeline = SovereignPipeline(config)
pipeline.initialize()

# Capture a recipe
recipe = Recipe(
    objective="Generate error handler for API calls",
    model="llama3",
    outcome="accepted",
    evaluation_score=0.92,
    tags=["error_handling", "api", "reliability"]
)
result = pipeline.capture_recipe(recipe)

Why Sovereign Intelligence Stack?

• Capture AI decisions as immutable records
• Classify tasks and route to optimal evaluation paths
• Autonomous self-improvement with drift detection
• Graph + vector store + persistent memory
• Timeline, patterns, observability

Building a Local AI System

Step 1: Install Ollama

# macOS
brew install ollama

# Linux
curl -fsSL https://ollama.com/install.sh | sh

# Windows
# Download from https://ollama.com/download/windows

Step 2: Pull a Model

# Pull a model
ollama pull llama3

# Pull a smaller model for testing
ollama pull llama3:8b

Step 3: Run Your First Local Inference

# Run a model
ollama run llama3 "What is sovereign AI?"

Step 4: Integrate with Context Engineering

from src.context.engineering import ContextTemplate

template = ContextTemplate(
    role="You are a helpful assistant.",
    system="You specialize in sovereign AI architecture.",
    examples=[
        {"input": "What is sovereign AI?", "output": "Intelligence is not the model..."}
    ]
)

# Use with Ollama API
import requests

response = requests.post(
    "http://localhost:11434/api/generate",
    json={
        "model": "llama3",
        "prompt": template.render("What is sovereign AI?"),
        "stream": False
    }
)

print(response.json()["response"])

Step 5: Add Compounding Intelligence

from src.integration.pipe import SovereignPipeline, PipelineConfig

config = PipelineConfig(db_path="intelligence.db")
pipeline = SovereignPipeline(config)
pipeline.initialize()

# Capture the recipe
recipe = Recipe(
    objective="Explain sovereign AI",
    model="llama3",
    outcome="accepted",
    evaluation_score=0.95,
    tags=["explanation", "sovereign-ai"]
)
result = pipeline.capture_recipe(recipe)

Step 6: Monitor with the Observatory

from src.observatory.timeline import IntelligenceTimeline

timeline = IntelligenceTimeline(recipe_storage)
timeline.record_event(IntelligenceEvent(
    type="recipe_captured",
    recipe_id=recipe.id,
    timestamp=datetime.now()
))

# Get timeline
events = timeline.get_timeline(days=7)
for event in events:
    print(f"{event.timestamp}: {event.type}")

Advanced Local AI Patterns

Multi-Model Routing

Pattern: Route tasks to different models based on complexity.

Example:

• Simple tasks → Small model (llama3:8b)
• Complex tasks → Large model (llama3:70b)
• Expert tasks → Specialized model (llama3:code)

Code:

from src.signal_router.router import SignalRouter

router = SignalRouter()
signal_type = router.classify(task)

if signal_type == "cheap":
    model = "llama3:8b"
elif signal_type == "expert":
    model = "llama3:70b"
else:
    model = "llama3:code"

Context Condensation

Pattern: Condense context to fit token budgets.

Example:

• Full context: 10,000 tokens
• Condensed context: 4,000 tokens
• Retain semantic meaning

Code:

from src.context.context_condenser import TokenAwareContextCondenser

condenser = TokenAwareContextCondenser(max_tokens=4096)
condensed = condenser.condense(full_context)

Autonomous Evaluation

Pattern: Evaluate local model performance over time.

Example:

• Generate test cases
• Evaluate on local model
• Detect drift
• Alert on regressions

Code:

from src.evaluation.loop import EvaluationLoop, LoopConfig

config = LoopConfig(
    signal_names=["code_correctness", "performance", "reliability"],
    test_count=50,
    interval_seconds=60
)
loop = EvaluationLoop(recipe_storage, config)
loop.start()

Local AI Best Practices

1. Start Small

Start with a small model (llama3:8b) and scale up as needed. Don't over-engineer.

2. Optimize Context

Bad context = bad results. Invest time in context engineering.

3. Capture Recipes

Capture every decision. You'll learn what works and what doesn't.

4. Evaluate Continuously

Don't wait for problems. Detect drift early.

5. Observe Patterns

Look for patterns in the timeline. Intelligence compounds.

Local AI Resources

Ollama Resources

• Ollama Documentation
• Ollama Model Library
• Ollama GitHub

Context Engineering Resources

• Context Engineering Book
• Prompt Engineering Guide
• Context Condensation Paper

Sovereign Intelligence Stack Resources

• Sovereign Intelligence Stack GitHub
• Sovereign Intelligence Stack Documentation
• Sovereign Intelligence Stack Demo

FAQ

What hardware do I need for local AI?

Minimum: 8GB RAM, 4GB GPU VRAM
Recommended: 16GB RAM, 8GB GPU VRAM
Optimal: 32GB RAM, 16GB GPU VRAM

Which model should I start with?

Start with: llama3:8b
Scale to: llama3:70b for complex tasks
Specialize with: llama3:code for coding tasks

Can I use local AI for production?

Yes. Local AI is production-ready. The Sovereign Intelligence Stack is used in production for autonomous research and expert fine-tuning.

How does local AI compare to cloud AI?

Local AI:

• Pros: Sovereignty, privacy, cost, performance
• Cons: Hardware cost, maintenance, model quality

Cloud AI:

• Pros: Model quality, scalability, maintenance
• Cons: Cost, privacy, sovereignty, performance

What's the difference between local AI and sovereign AI?

Local AI is running models on your hardware.
Sovereign AI is building a compounding intelligence system that captures decisions, routes tasks, evaluates autonomously, stores knowledge, and observes patterns.

Local AI is a component of sovereign AI.

What's Next?

Start Here

1. Read the Sovereign AI Architecture pillar — The complete 5-layer stack, design principles, and research validation

For Beginners

1. Read the Getting Started with Sovereign AI post — On-ramp to sovereign AI
2. Try the Ollama quickstart — First local inference

For Intermediate Readers

1. Read the Context Engineering post — Systematic context management
2. Read the Sovereign Intelligence Stack post — 5-layer architecture
3. Read the Agent Recipes post — Recipe capture deep dive

For Advanced Readers

1. Read the Model Is Not the Product post — Research validation
2. Read the Loop Is the Product post — Intelligence Observatory deep dive
3. Contribute to sovereign-intelligence-stack — Open-source contribution

References

Related Posts

• Sovereign AI Architecture — Full 5-layer architecture, compounding intelligence, research validation (the pillar)
• Getting Started with Sovereign AI — Beginner on-ramp
• The Sovereign Intelligence Stack — Architecture implementation
• The Model Is Not the Product — Research validation
• The Loop Is the Product — Intelligence Observatory deep dive
• Building Autonomous Sovereign AI — Autonomous evaluation
• Retrieval Architecture — Retrieval guide

External Resources

• Ollama Documentation — Local LLMs
• Ollama GitHub — Local LLMs
• Context Engineering Book — Context engineering
• Prompt Engineering Guide — Prompt engineering

Related Repositories

• sovereign-intelligence-stack — Working code
• Sovereign Memory Bank — Memory system
• Dynamic Persona MoE RAG — Retrieval system
• Objective05 — Persistent infrastructure
• SovereignSpec — Spec-driven development
• Context Engineering
• Agent Recipes

Related Repositories

• sovereign-intelligence-stack
• Ollama
• Sovereign Memory Bank
• Dynamic Persona MoE RAG
• SovereignSpec

Books

• Sovereign AI: An Architectural Investigation into Local-First Intelligence — $88

Published July 5, 2026 by Daniel Kliewer
License: MIT

Memory without structure is noise. Structure without memory is stateless. Sovereign retrieval is both.

By Daniel Kliewer
Published: July 5, 2026
Reading Time: 20 minutes
Prerequisites: None (beginner to advanced)
This post focuses on memory systems and retrieval architecture — Sovereign Memory Bank, Dynamic Persona MoE RAG, Objective05, and GraphRAG. For the full sovereign AI architecture (5-layer stack, compounding intelligence, research validation), see the Sovereign AI Architecture pillar.

Executive Summary

This post isolates the memory and retrieval subsystems that make sovereign AI compound — the four pillars (Sovereign Memory Bank, Dynamic Persona MoE RAG, Objective05, and SovereignSpec) that sit beneath the Sovereign Intelligence Stack and turn flat, stateless RAG into a system where every retrieval improves the next. If the architecture pillar describes the full five-layer loop, this post goes deep on Layer 4 (Knowledge Systems) and the retrieval patterns that make it work: hierarchical memory promotion, persona-driven mixture-of-experts retrieval, Rust-backed persistent storage, and spec-driven GraphRAG.

What you'll learn:

• Why current RAG systems fail (fragmentation, statelessness, lack of compounding)
• The four pillars of sovereign retrieval (Memory Bank, Persona MoE, Persistent Infrastructure, Spec-Driven)
• How to build a retrieval system that compounds intelligence over time
• Where to find more advanced resources

Want the full architecture? See the Sovereign AI Architecture pillar for the complete 5-layer stack, compounding intelligence design, and research validation.

The RAG Problem

Current RAG Systems Are Fragmented

Right now, the RAG ecosystem is split across multiple disconnected systems:

These systems work independently. They don't talk to each other. They don't share memory. They don't compound intelligence.

This is the problem.

Current RAG Systems Are Stateless

Most RAG systems today are stateless. Every retrieval is a fresh start:

Query → Embed → Retrieve → Generate
          (no history)

This is like asking a librarian for a book, then forgetting what you learned. Next time, you start from zero.

Consequences:

• No history of what was retrieved
• No record of what worked and what didn't
• Every retrieval is a mystery
• No way to improve over time

The Sovereign Solution

The Sovereign Intelligence Stack solves this by building a unified retrieval architecture where every retrieval compounds into the next:

┌─────────────────────────────────────────────────────────────┐
│                  Sovereign Retrieval Architecture             │
├─────────────────────────────────────────────────────────────┤
│  Layer 1: Memory Bank     │  7-layer autonomous memory       │
├─────────────────────────────────────────────────────────────┤
│  Layer 2: Persona MoE     │  Persona-driven retrieval        │
├─────────────────────────────────────────────────────────────┤
│  Layer 3: Persistent Infra│  Objective05 (Rust infrastructure)│
├─────────────────────────────────────────────────────────────┤
│  Layer 4: Spec-Driven     │  SovereignSpec (GraphRAG)        │
├─────────────────────────────────────────────────────────────┤
│  Layer 5: Compounding     │  Recipes + Knowledge Graph       │
└─────────────────────────────────────────────────────────────┘

The Four Pillars of Sovereign Retrieval

Pillar 1: Sovereign Memory Bank

Purpose: 7-layer autonomous cognitive memory system.

Why it matters: Current memory systems are flat. Sovereign Memory Bank provides hierarchical, autonomous memory that compounds over time.

Seven Layers:

1. Sensory Buffer — Raw input from the environment
2. Working Memory — Active processing of current context
3. Short-Term Memory — Recent events and decisions
4. Long-Term Memory — Permanent storage of important patterns
5. Semantic Memory — Knowledge about the world
6. Episodic Memory — Personal experiences and events
7. Procedural Memory — Skills and how-to knowledge

Code Example:

from src.memory.management import MemoryManager, MemoryLayer

manager = MemoryManager()

# Store in working memory
manager.store(
    layer=MemoryLayer.WORKING,
    content="User asked about sovereign AI",
    metadata={"timestamp": datetime.now(), "source": "user_prompt"}
)

# Promote to long-term memory
if is_important(content):
    manager.promote(
        source_layer=MemoryLayer.WORKING,
        target_layer=MemoryLayer.LONG_TERM,
        content=content,
        metadata={"reason": "important_pattern"}
    )

Integration: Feeds into Layer 5 (Knowledge Systems) of the Sovereign Intelligence Stack.

Related Post: Sovereign Memory Bank

Pillar 2: Dynamic Persona MoE RAG

Purpose: Persona-driven mixture-of-experts retrieval.

Why it matters: Different queries benefit from different retrieval strategies. Dynamic Persona MoE RAG switches between personas based on the query.

How It Works:

1. Query Analysis — Analyze the query to determine the best persona
2. Persona Selection — Select the most relevant persona
3. Retrieval — Retrieve using the selected persona's strategy
4. Synthesis — Combine results from multiple personas

Personas:

• Expert Persona — Deep, technical retrieval
• Novice Persona — Simple, intuitive retrieval
• Creative Persona — Associative, lateral retrieval
• Analytical Persona — Structured, logical retrieval

Code Example:

from src.retrieval.persona_moe import PersonaMoE, Persona

moe = PersonaMoE()

# Analyze query
query = "How does the Sovereign Intelligence Stack work?"
persona = moe.select_persona(query)

# Retrieve with persona
results = moe.retrieve(
    query=query,
    persona=persona,
    top_k=10
)

# Combine results
synthesized = moe.synthesize(results)

Integration: Provides the retrieval layer for Layer 4 (Knowledge Systems) of the Sovereign Intelligence Stack.

Related Post: Dynamic Persona MoE RAG

Pillar 3: Objective05 (Persistent Infrastructure)

Purpose: Persistent intelligence infrastructure in Rust.

Why it matters: Rust provides performance, memory safety, and reliability for intelligence infrastructure.

Key Features:

• Persistent Storage — Durable, crash-safe storage
• High Performance — Sub-millisecond retrieval
• Memory Safety — No undefined behavior
• Concurrency — Safe parallel access

Architecture:

// Persistent storage engine
pub struct PersistentStorage {
    db: rusqlite::Connection,
    index: tantivy::Index,
}

impl PersistentStorage {
    pub fn new(path: &str) -> Result<Self> {
        let db = rusqlite::Connection::open(path)?;
        let index = tantivy::Index::open_in_dir(path)?;
        Ok(Self { db, index })
    }

    pub fn store(&mut self, content: &str, metadata: &serde_json::Value) -> Result<u64> {
        // Store in SQLite
        let id = self.db.execute(
            "INSERT INTO documents (content, metadata, created_at) VALUES (?1, ?2, datetime('now'))",
            rusqlite::params![content, metadata.to_string()]
        )?;

        // Index for full-text search
        self.index.store(content)?;

        Ok(id)
    }

    pub fn search(&self, query: &str, limit: usize) -> Result<Vec<Document>> {
        // Search with tantivy
        let results = self.index.search(query, limit)?;
        Ok(results)
    }
}

Integration: Provides the low-level infrastructure for Layer 4 (Knowledge Systems) and Layer 5 (Observatory) of the Sovereign Intelligence Stack.

Pillar 4: SovereignSpec (Spec-Driven GraphRAG)

Purpose: Spec-driven development with GraphRAG.

Why it matters: Specifications drive development, and GraphRAG retrieves relevant specs.

How It Works:

1. Spec Creation — Create specifications for tasks
2. Spec Storage — Store specs in a knowledge graph
3. Spec Retrieval — Retrieve relevant specs using GraphRAG
4. Spec Execution — Execute tasks using retrieved specs

Code Example:

from src.spec.graphrag import GraphRAG, SpecNode

graphrag = GraphRAG()

# Create a spec
spec = SpecNode(
    id="spec_001",
    type="error_handling",
    description="Handle API errors gracefully",
    pattern="""
    try:
        response = api_call()
    except Exception as e:
        log_error(e)
        retry(max_attempts=3)
    """,
    tags=["error_handling", "api", "reliability"]
)

graphrag.add_spec(spec)

# Retrieve relevant specs
query = "How do I handle API errors?"
relevant_specs = graphrag.retrieve(query, top_k=5)

Integration: Provides the spec-driven workflow that feeds into Layer 1 (Recipe Compiler) of the Sovereign Intelligence Stack.

Related Post: SovereignSpec

Building a Unified Retrieval System

Step 1: Initialize the Memory Manager

from src.memory.management import MemoryManager, MemoryLayer

manager = MemoryManager()
manager.initialize()

Step 2: Initialize the Persona MoE

from src.retrieval.persona_moe import PersonaMoE

moe = PersonaMoE()
moe.initialize()

Step 3: Initialize Objective05 (Rust Infrastructure)

from src.infrastructure.objective05 import PersistentStorage

storage = PersistentStorage("intelligence.db")
storage.initialize()

Step 4: Initialize GraphRAG

from src.spec.graphrag import GraphRAG

graphrag = GraphRAG()
graphrag.initialize()

Step 5: Unified Retrieval Pipeline

from src.retrieval.unified import UnifiedRetrieval

retrieval = UnifiedRetrieval(
    memory_manager=manager,
    persona_moe=moe,
    persistent_storage=storage,
    graphrag=graphrag
)

# Retrieve with unified system
query = "How does the Sovereign Intelligence Stack work?"
results = retrieval.retrieve(query, top_k=10)

# Results include:
# - Memory Bank results (hierarchical memory)
# - Persona MoE results (persona-specific retrieval)
# - Objective05 results (persistent storage)
# - GraphRAG results (spec-driven retrieval)

Advanced Retrieval Patterns

Pattern 1: Compounding Retrieval

Pattern: Each retrieval makes future retrievals better.

Example:

# First retrieval
results_1 = retrieval.retrieve("What is sovereign AI?")
print(results_1)

# Capture the recipe
recipe = Recipe(
    query="What is sovereign AI?",
    results=results_1,
    outcome="accepted",
    evaluation_score=0.92
)
recipe_storage.create_recipe(recipe)

# Second retrieval (now benefits from the recipe)
results_2 = retrieval.retrieve("What is sovereign AI?")
# → Results are better because the system learned from the first retrieval

Pattern 2: Multi-Persona Synthesis

Pattern: Combine results from multiple personas.

Example:

# Retrieve with all personas
expert_results = moe.retrieve(query, persona=Persona.EXPERT, top_k=5)
novice_results = moe.retrieve(query, persona=Persona.NOVICE, top_k=5)
creative_results = moe.retrieve(query, persona=Persona.CREATIVE, top_k=5)

# Synthesize
synthesized = moe.synthesize([
    expert_results,
    novice_results,
    creative_results
])

Pattern 3: Memory Promotion

Pattern: Promote important memories to long-term storage.

Example:

# Check if memory is important
if is_important(memory_content):
    # Promote to long-term memory
    manager.promote(
        source_layer=MemoryLayer.WORKING,
        target_layer=MemoryLayer.LONG_TERM,
        content=memory_content,
        metadata={"reason": "important_pattern"}
    )

Pattern 4: Spec-Driven Execution

Pattern: Use specs to drive task execution.

Example:

# Retrieve relevant specs
specs = graphrag.retrieve("How to handle errors?", top_k=3)

# Execute task using specs
for spec in specs:
    execute_task(spec.pattern)

Retrieval Best Practices

1. Start with Memory Bank

Start with the Memory Bank for hierarchical memory. It's the foundation.

2. Use Persona MoE for Diversity

Use Persona MoE for diverse retrieval strategies. It prevents tunnel vision.

3. Leverage Objective05 for Performance

Use Objective05 for high-performance, durable storage. It's fast and safe.

4. Use GraphRAG for Specs

Use GraphRAG for spec-driven development. It's structured and reliable.

5. Compound Over Time

Capture every retrieval. You'll learn what works and what doesn't.

Retrieval Resources

Sovereign Memory Bank

• Sovereign Memory Bank GitHub
• Sovereign Memory Bank Documentation

Dynamic Persona MoE RAG

• Dynamic Persona MoE RAG GitHub
• Dynamic Persona MoE RAG Documentation

Objective05

• Objective05 GitHub
• Objective05 Documentation

SovereignSpec

• SovereignSpec GitHub
• SovereignSpec Documentation

GraphRAG

• Microsoft GraphRAG
• GraphRAG Documentation

FAQ

What's the difference between Sovereign Memory Bank and traditional memory?

Traditional Memory: Flat, stateless, no hierarchy.
Sovereign Memory Bank: Hierarchical, autonomous, 7-layer system that compounds over time.

How does Persona MoE work?

Persona MoE analyzes the query to determine the best retrieval persona (Expert, Novice, Creative, Analytical). It retrieves using that persona's strategy and synthesizes results from multiple personas.

Why use Rust for infrastructure?

Rust provides performance, memory safety, and reliability. It's ideal for intelligence infrastructure where crashes are unacceptable.

What is GraphRAG?

GraphRAG combines knowledge graphs with retrieval. It retrieves not just by similarity, but by structural relationships in the graph.

Can I use these systems independently?

Yes. Each system works independently. You can use just the Memory Bank, or just Persona MoE, or all four together.

What's Next?

Start Here

1. Read the Sovereign AI Architecture pillar — The complete 5-layer stack, design principles, and research validation

For Beginners

1. Read the Getting Started with Sovereign AI post — On-ramp to sovereign AI
2. Try the Sovereign Memory Bank quickstart — First memory system

For Intermediate Readers

1. Read the Sovereign Intelligence Stack post — 5-layer architecture
2. Read the Dynamic Persona MoE RAG post — Persona-driven retrieval
3. Read the SovereignSpec post — Spec-driven development

For Advanced Readers

1. Read the Model Is Not the Product post — Research validation
2. Read the Loop Is the Product post — Intelligence Observatory deep dive
3. Contribute to sovereign-memory-bank — Open-source contribution

References

Related Posts

• Sovereign AI Architecture — Full 5-layer architecture, compounding intelligence, research validation (the pillar)
• Getting Started with Sovereign AI — Beginner on-ramp
• The Sovereign Intelligence Stack — Architecture implementation
• The Model Is Not the Product — Research validation
• The Loop Is the Product — Intelligence Observatory deep dive
• Building Autonomous Sovereign AI — Autonomous evaluation
• Local AI Architecture — Local AI guide

GitHub Repositories

• Sovereign Memory Bank — 7-layer autonomous cognitive memory
• Dynamic Persona MoE RAG — Persona-driven mixture-of-experts
• Objective05 — Persistent intelligence infrastructure in Rust
• SovereignSpec — Spec-driven development with GraphRAG

External References

• Microsoft GraphRAG — Knowledge graph retrieval
• GraphRAG Documentation — GraphRAG
• Context Engineering (13.5K stars) — Systematic replacement for vibe coding
• Agent Harnesses (225K + 244K stars) — Operating system layer for agents
• Getting Started with Sovereign AI
• The Sovereign Intelligence Stack
• The Model Is Not the Product
• The Loop Is the Product
• Building Autonomous Sovereign AI
• Sovereign Memory Bank
• Dynamic Persona MoE RAG
• SovereignSpec

Related Repositories

• sovereign-intelligence-stack
• sovereign-memory-bank
• dynamic-persona-moe-rag
• objective05
• sovereignspec

Books

• Sovereign AI: An Architectural Investigation into Local-First Intelligence — $88

Published July 5, 2026 by Daniel Kliewer
License: MIT

Intelligence is not the model. Intelligence is the accumulated decisions that shaped the model.

By Daniel Kliewer
Published: July 5, 2026
Reading Time: 25 minutes
Prerequisites: None (beginner to advanced)
Related Posts: The Sovereign Intelligence Stack, The Model Is Not the Product, The Loop Is the Product, Building Autonomous Sovereign AI, Performance Benchmarks Related Repositories: Related Repositories: sovereign-intelligence-stack, Sovereign Memory Bank, Dynamic Persona MoE RAG, Objective05, SovereignSpec

Executive Summary

This post synthesizes four years of architectural investigation into sovereign AI into a single, coherent system. It ties together the Sovereign Intelligence Stack, Sovereign Memory Bank, Dynamic Persona MoE RAG, Objective05, and SovereignSpec into one unified architecture.

The key insight: Intelligence is not the model. Intelligence is the accumulated decisions that shaped the model.

This means we need to build systems that:

1. Capture decisions (not just outputs) as immutable records
2. Route tasks intelligently based on confidence and context
3. Evaluate autonomously with drift detection and self-improvement
4. Store knowledge in graphs that compound over time
5. Observe patterns across the full intelligence timeline

The result is a system that gets smarter over time — not through retraining, but through compounding intelligence.

Part 1: The Problem with Current AI Systems

Stateless Interactions

Most AI systems today are stateless. Every interaction is a fresh start:

User Prompt → Model Inference → Response
                (no history)

This is like asking a consultant for advice, then forgetting everything they told you. Next time, you start from zero.

Consequences:

• No history of decisions
• No record of what worked and what didn't
• Every conversation is a mystery
• No way to improve over time

The Loop Problem

Even when systems have some state, they lack loops — systems that capture decisions, evaluate outcomes, and compound intelligence:

User Prompt → Model Inference → Response
                        ↓
              Capture Decision → Evaluate → Compound Intelligence

Without this loop, you have:

• No way to know why a model made a decision
• No record of what memory was used
• No evaluation of outcomes
• No compounding intelligence

The Sovereign Solution

The Sovereign Intelligence Stack solves this by building a 5-layer architecture where every layer produces data that makes the next layer better:

┌─────────────────────────────────────────────────────────────┐
│                  Intelligence Layer                          │
│  Context Engineering  │  Apprenticeship Engine  │ Orchestration  │
├─────────────────────────────────────────────────────────────┤
│              Layer 5: Intelligence Observatory              │
│        Timeline │ Pattern Detection │ Reporting              │
├─────────────────────────────────────────────────────────────┤
│              Layer 4: Knowledge Systems                      │
│          Graph Store  │  Persistent Memory  │ GraphRAG       │
├─────────────────────────────────────────────────────────────┤
│              Layer 3: Evaluation Loop                        │
│          Signal Drift │ Test Generation │ Autonomous         │
├─────────────────────────────────────────────────────────────┤
│              Layer 2: Signal Router                          │
│        Classification │ Routing Logic  │ Signal Types         │
├─────────────────────────────────────────────────────────────┤
│              Layer 1: Recipe Compiler                        │
│         Immutable Recipes │ SQLite FTS5 │ Relationships      │
├─────────────────────────────────────────────────────────────┤
│                    Integration Layer                         │
│                  SovereignPipeline                           │
└─────────────────────────────────────────────────────────────┘

Part 2: The Five Layers Explained

Layer 1: Recipe Compiler

Purpose: Capture AI decisions as immutable records.

Why it matters: Without recipes, you have no history. You have no way to know why a model made a decision, what memory it used, what the outcome was.

What it captures:

• Objective — What was the task?
• Model — Which model was used?
• Memory — What memory was injected?
• Prompt — What was the prompt (with versioning)?
• Reasoning Patterns — What reasoning patterns were used?
• Evaluation — How was it evaluated?
• Result — What was the result?
• Timestamp — When was it captured?

Code Example:

@dataclass
class Recipe:
    objective: str
    model: str
    memory_snapshot: Optional[str] = None
    prompt: Optional[str] = None
    reasoning_patterns: List[str] = field(default_factory=list)
    evaluation_score: Optional[float] = None
    outcome: str = "unknown"
    timestamp: datetime = field(default_factory=datetime.now)
    tags: List[str] = field(default_factory=list)

Integration: Recipes are stored in SQLite with FTS5 full-text search, enabling fast semantic search across all captured decisions.

Related Posts:

• Agent Recipes — Deep dive into recipe capture
• Sovereign Intelligence Stack — Layer 1 implementation

Layer 2: Signal Router

Purpose: Classify incoming tasks and route them through optimal evaluation paths.

Why it matters: Not all tasks are created equal. Simple tasks should be routed to fast, lightweight models. Complex tasks should be routed to capable models with full context.

Signal Types:

• Cheap — Simple tasks routed to fast, lightweight models
• Expert — Complex tasks routed to capable models with full context
• Hybrid — Tasks that benefit from multi-stage evaluation

Code Example:

class SignalRouter:
    def classify(self, task: str) -> SignalType:
        """Classify task into signal type."""
        if self.is_simple(task):
            return SignalType.CHEAP
        elif self.is_complex(task):
            return SignalType.EXPERT
        else:
            return SignalType.HYBRID
    
    def route(self, task: str, signal_type: SignalType) -> Route:
        """Route task to appropriate evaluation path."""
        if signal_type == SignalType.CHEAP:
            return self.route_to_fast_model(task)
        elif signal_type == SignalType.EXPERT:
            return self.route_to_expert_model(task)
        else:
            return self.route_to_hybrid_evaluation(task)

Integration: The router uses the knowledge graph (Layer 4) to make routing decisions based on historical performance.

Related Posts:

• Sovereign Intelligence Stack — Layer 2 implementation
• Context Engineering — Context optimization for routing

Layer 3: Evaluation Loop

Purpose: Autonomous self-improvement through continuous test generation and drift detection.

Why it matters: Without evaluation, you have no way to know if your system is improving or degrading. Drift detection catches performance regressions before they compound.

Components:

• Signal Registry — Define what to evaluate
• Test Generator — Generate synthetic test cases
• Drift Detector — Detect performance drift (KS and PSI statistics)
• Loop Controller — Autonomous evaluation scheduling

Code Example:

class EvaluationLoop:
    def __init__(self, recipe_storage: RecipeStorage, config: LoopConfig):
        self.recipe_storage = recipe_storage
        self.config = config
        self.signal_registry = SignalRegistry()
        self.test_generator = TestCaseGenerator()
        self.drift_detector = DriftDetector()
    
    def run(self):
        """Run autonomous evaluation loop."""
        while True:
            # Generate test cases
            tests = self.test_generator.generate(self.config.test_count)
            
            # Evaluate on signal registry
            results = self.evaluate(tests)
            
            # Detect drift
            drift = self.drift_detector.detect(results)
            
            # Alert on drift
            if drift.severity > self.config.alert_threshold:
                self.alert(drift)
            
            # Wait for next cycle
            time.sleep(self.config.interval_seconds)

Drift Detection: Uses Kolmogorov-Smirnov (KS) and Population Stability Index (PSI) statistics to detect performance regressions.

Related Posts:

• Sovereign Intelligence Stack — Layer 3 implementation
• Autonomous Sovereign AI — Autonomous evaluation

Layer 4: Knowledge Systems

Purpose: Persistent knowledge representation combining graph and memory systems.

Why it matters: Intelligence compounds over time. Each recipe makes future decisions smarter through the knowledge graph.

Components:

• Graph Store — NetworkX-based knowledge graph
• Vector Store — ChromaDB-based vector embeddings (optional)
• GraphRAG — Hybrid retrieval combining graph + vector search
• Persistent Memory — SQLite-based memory with relevance scoring
• Memory Management — Memory lifecycle with relevance scoring

Code Example:

class KnowledgeGraph:
    def __init__(self):
        self.graph = nx.DiGraph()
    
    def add_recipe(self, recipe: Recipe):
        """Add recipe to knowledge graph."""
        node_id = recipe.id
        self.graph.add_node(node_id, **recipe.dict())
        
        # Add relationships
        for tag in recipe.tags:
            self.graph.add_edge(node_id, f"tag:{tag}", weight=1.0)
        
        for memory in recipe.memory_snapshot:
            self.graph.add_edge(node_id, f"memory:{memory}", weight=0.8)
    
    def query(self, query_str: str, limit: int = 10) -> List[Recipe]:
        """Query knowledge graph with hybrid retrieval."""
        # Graph-based retrieval
        graph_results = self.graph_search(query_str)
        
        # Vector-based retrieval
        vector_results = self.vector_search(query_str)
        
        # Hybrid fusion
        return self.hybrid_fusion(graph_results, vector_results, limit)

Integration: The knowledge graph feeds into the signal router (Layer 2) and the evaluation loop (Layer 3).

Related Posts:

• Sovereign Intelligence Stack — Layer 4 implementation
• Sovereign Memory Bank — 7-layer memory system
• Dynamic Persona MoE RAG — Persona-driven retrieval
• GraphRAG — Microsoft's GraphRAG implementation

Layer 5: Intelligence Observatory

Purpose: Generate intelligence timelines and detect emerging patterns.

Why it matters: Observability is the operating system. Without a timeline, you have no way to see how intelligence compounds over time.

Components:

• Timeline — Intelligence events chronologically ordered
• Detectors — Pattern detection (errors, drift, optimization)
• Reporter — Report generation
• Visualizer — Timeline visualization (HTML/JSON)
• Extended — Dashboard, telemetry, archive, extended API

Code Example:

class IntelligenceTimeline:
    def __init__(self, storage: RecipeStorage):
        self.storage = storage
        self.events = []
    
    def record_event(self, event: IntelligenceEvent):
        """Record an intelligence event."""
        self.events.append(event)
    
    def get_timeline(self, days: int = 30) -> List[IntelligenceEvent]:
        """Get timeline for last N days."""
        cutoff = datetime.now() - timedelta(days=days)
        return [e for e in self.events if e.timestamp > cutoff]
    
    def detect_patterns(self) -> List[Pattern]:
        """Detect emerging patterns."""
        patterns = []
        
        # Error patterns
        errors = self.get_events_by_type("error")
        if self.is_spike(errors):
            patterns.append(Pattern("error_spike", errors))
        
        # Drift patterns
        drifts = self.get_events_by_type("drift")
        if self.is_sustained(drifts):
            patterns.append(Pattern("sustained_drift", drifts))
        
        # Optimization patterns
        optimizations = self.get_events_by_type("optimization")
        if self.is_trend(optimizations):
            patterns.append(Pattern("optimization_trend", optimizations))
        
        return patterns

Extended Features:

• Dashboard — Interactive HTML dashboard with Chart.js
• Telemetry — Real-time metrics collection
• Archive — Historical data compression
• Extended API — FastAPI endpoints for dashboard

Related Posts:

• Sovereign Intelligence Stack — Layer 5 implementation
• The Loop Is the Product — Intelligence Observatory deep dive

Part 3: The Compounding Architecture

The Feedback Loop

The Sovereign Intelligence Stack is not a linear pipeline. It's a feedback loop:

Recipe Compiler → Signal Router → Evaluation Loop
         ↑                              ↓
         └──── Knowledge Systems ← Observatory

1. Recipes are captured by the Recipe Compiler
2. Signals are classified by the Signal Router
3. Evaluations are run by the Evaluation Loop
4. Knowledge is stored in the Knowledge Systems
5. Observability is provided by the Intelligence Observatory

The loop:

• Recipes inform the Knowledge Systems
• Knowledge Systems improve Signal Routing
• Signal Routing improves Evaluation Quality
• Evaluation Quality improves Recipe Capture
• Observatory monitors the entire loop

Compounding Intelligence

Every iteration of the loop makes the next iteration better:

• Iteration 1: Capture 100 recipes. Build a small knowledge graph.
• Iteration 2: Route tasks based on the graph. Generate better tests.
• Iteration 3: Detect drift early. Capture more nuanced recipes.
• Iteration 4: Optimize routing. Detect patterns. Compounding begins.

This is what makes the stack "sovereign": It doesn't just run AI — it compounds intelligence.

Part 4: Related Systems

Sovereign Memory Bank

Purpose: 7-layer autonomous cognitive memory system.

Layers:

1. Sensory Buffer
2. Working Memory
3. Short-Term Memory
4. Long-Term Memory
5. Semantic Memory
6. Episodic Memory
7. Procedural Memory

Integration: The Sovereign Memory Bank feeds into Layer 4 (Knowledge Systems) of the Sovereign Intelligence Stack.

Related Post: Sovereign Memory Bank

Dynamic Persona MoE RAG

Purpose: Persona-driven mixture-of-experts over local graphs.

Key Insight: Different tasks benefit from different "personas" — specialized retrieval strategies.

Integration: The Dynamic Persona MoE RAG provides the retrieval layer for Layer 4 (Knowledge Systems).

Related Post: Dynamic Persona MoE RAG

Objective05

Purpose: Persistent intelligence infrastructure in Rust.

Key Insight: Rust provides performance and memory safety for intelligence infrastructure.

Integration: Objective05 provides the low-level infrastructure for Layer 4 (Knowledge Systems) and Layer 5 (Observatory).

SovereignSpec

Purpose: Spec-driven development with GraphRAG.

Key Insight: Specifications drive development, and GraphRAG retrieves relevant specs.

Integration: SovereignSpec provides the spec-driven workflow that feeds into Layer 1 (Recipe Compiler).

Related Post: SovereignSpec

Part 5: Research Validation

Converging Research Threads

The Sovereign Intelligence Stack is validated by three converging research threads:

1. Apple's Residual Context Diffusion (RCD) — arXiv:2601.22954

   • Validates: Intelligence lives in residual state, not just the model
   • Paper: Residual Context Diffusion Language Models

2. LMSYS/SGLang Agentic Execution Graphs

   • Validates: Intelligence lives in execution graphs, not just inference
   • Repo: github.com/sgl-project/sglang

3. Constrained Optimization for Agent Loops

   • Validates: Intelligence lives in optimization loops, not just prompts
   • Paper: Constrained Optimization for Agent Loops

Key Researchers

Part 6: Implementation Guide

Quick Start

# Clone the repository
git clone https://github.com/kliewerdaniel/sovereign-intelligence-stack.git
cd sovereign-intelligence-stack

# Create virtual environment
python -m venv .venv
source .venv/bin/activate

# Install dependencies
pip install -e .

# Run the demo
python examples/sovereign_stack_demo.py

Capture a Recipe

from src.recipe_compiler.models import Recipe
from src.recipe_compiler.storage import RecipeStorage

storage = RecipeStorage("my_stack.db")

recipe = Recipe(
    objective="Generate error handler for API calls",
    model="gpt-4",
    outcome="accepted",
    evaluation_score=0.92,
    tags=["error_handling", "api", "reliability"]
)

storage.create_recipe(recipe)

Run the Full Pipeline

from src.integration.pipe import SovereignPipeline, PipelineConfig

config = PipelineConfig(db_path="intelligence.db")
pipeline = SovereignPipeline(config)
pipeline.initialize()

# Capture a recipe
recipe = Recipe(
    objective="Optimize database query",
    model="claude-2",
    outcome="accepted",
    evaluation_score=0.87,
    tags=["optimization", "database"]
)
result = pipeline.capture_recipe(recipe)

# Get intelligence summary
summary = pipeline.get_intelligence_summary()

Autonomous Evaluation

from src.evaluation.loop import EvaluationLoop, LoopConfig

config = LoopConfig(
    signal_names=["code_correctness", "performance", "reliability"],
    test_count=50,
    interval_seconds=60
)
loop = EvaluationLoop(recipe_storage, config)
loop.start()

Apprenticeship Progression

from src.apprentice.stages import AutonomyState

state = AutonomyState()
# supervised → assisted → monitored → semi-independent → fully independent
state.record_decision(True)  # Success
state.record_decision(False)  # Failure
state.record_decision(True)

if state.can_promote():
    state.promote()
    print(f"Promoted to: {state.level.value}")

Part 7: Design Principles

1. Immutability

Principle: Recipes are captured once, never modified. Updates are tracked as new versions.

Rationale: Immutability ensures history is preserved. You can always go back to understand why a decision was made.

2. Local-First

Principle: All data stays local; no cloud APIs required.

Rationale: Data sovereignty is a core value. Cloud APIs introduce latency, cost, and privacy risks.

3. Compounding

Principle: Each recipe makes future decisions smarter through the knowledge graph.

Rationale: Intelligence compounds over time. The system gets smarter with use.

4. Autonomy

Principle: The system evaluates itself, detects drift, and phases into higher autonomy.

Rationale: Autonomous evaluation catches regressions before they compound.

5. Observability

Principle: Every decision produces a timeline event. Nothing is lost.

Rationale: Observability is the operating system. You can't improve what you can't measure.

Part 8: Known Limitations

Vector Store

Limitation: ChromaDB requires Pydantic 2.x which conflicts with the current Python environment.

Workaround: The graph store (NetworkX) works fully. Vector embeddings are optional and gracefully degrade when unavailable.

Future: Update Pydantic to 2.x in a dedicated venv, then re-enable ChromaDB.

Part 9: What's Next

Immediate Priorities

1. Add benchmarks — Performance tests for recipe compilation, signal routing, evaluation loop
2. Add documentation — API docs, contributing guide, usage examples
3. Add diagrams — Architecture diagrams for the 5-layer stack
4. Add tests — Unit and integration tests for all layers

Medium-Term Goals

1. Deploy to production — Real-world validation
2. Add federated sync — Distributed intelligence exchange
3. Add tacit judgment extraction — Expert session analysis
4. Add MCP server — Expose knowledge graph via MCP

Long-Term Vision

1. Apprenticeship Engine — Automated skill extraction with phased autonomy
2. Federated Intelligence — Multi-agent coordination with consensus
3. Intelligence Marketplace — Share intelligence across instances
4. Autonomous Research — Self-improving research loops

Conclusion

The Sovereign Intelligence Stack is not just another AI framework. It's a compounding intelligence system that captures decisions, routes tasks, evaluates autonomously, stores knowledge, and observes patterns.

It's built on the principle that intelligence is not the model. Intelligence is the accumulated decisions that shaped the model.

The stack is implemented in sovereign-intelligence-stack with 70 Python files, 7,757 lines of code, and 26 modules verified.

The Sovereign Intelligence Stack is sovereign.

References

Related Posts

• The Sovereign Intelligence Stack
• The Model Is Not the Product
• The Loop Is the Product
• Building Autonomous Sovereign AI
• Agent Recipes
• Sovereign Memory Bank
• Dynamic Persona MoE RAG
• SovereignSpec
• Context Engineering
• GraphRAG

Related Posts

• The Sovereign Intelligence Stack — 5-layer architecture with working code
• The Model Is Not the Product — Research validation: three converging threads
• The Loop Is the Product — Intelligence Observatory deep dive
• Building Autonomous Sovereign AI — Autoresearch loops and expert fine-tuning
• Getting Started with Sovereign AI — Beginner on-ramp
• Local AI Architecture: Building Intelligence You Own — Local-first implementation guide
• Retrieval Architecture: Building Intelligent Memory Systems — Memory and retrieval systems synthesis

Related Repositories

• sovereign-intelligence-stack — Working code: 70 Python files, 7,757 lines
• Sovereign Memory Bank — 7-layer autonomous cognitive memory
• Dynamic Persona MoE RAG — Persona-driven mixture-of-experts
• Objective05 — Persistent intelligence infrastructure in Rust
• SovereignSpec — Spec-driven development engine

Research Papers

• Residual Context Diffusion Language Models (Hu et al., 2026) — Apple research on intermediate uncertainty
• SGLang (LMSYS, UC Berkeley) — Agentic execution graphs
• Context Engineering (13.5K stars) — Systematic replacement for vibe coding
• Agent Harnesses (ECC 225K + Superpowers 244K stars) — Operating system layer for agents
• Persistent Memory (Claude Mem, 85K stars) — Stateful agent collaboration
• Multi-Agent Orchestration (CrewAI, 55K stars) — Collaborative intelligence
• Spec-Driven Development — Structured specifications (117K stars ecosystem)
• GraphRAG (Microsoft, 70K+ stars) — Knowledge graph retrieval

Published July 5, 2026 by Daniel Kliewer
License: MIT

The model is not the product. The model is the ingredient.

Every AI system that matters — every one that actually delivers value — runs on a loop. Not a single prompt, not a single inference call, but a loop that captures decisions, evaluates outcomes, and compounds intelligence over time.

The model is a snapshot of accumulated decisions. The loop is the engine that keeps accumulating.

If you build AI systems that don't capture their own decisions, you're building castles on sand. Every session resets. Every conversation starts from zero. Every failure is a mystery because you have no record of why it failed.

This is the problem the Sovereign Intelligence Stack solves.

The Architecture in 11 Lines

The Sovereign Intelligence Stack is a 5-layer architecture where each layer produces data that makes the next layer better. It's not a monolith. It's a pipeline of compounding intelligence.

Layer 1: Recipe Compiler    → Captures AI decisions (immutable records)
Layer 2: Signal Router      → Routes tasks to appropriate evaluation paths
Layer 3: Evaluation Loop    → Autonomous self-improvement with drift detection
Layer 4: Knowledge Systems  → GraphRAG + Persistent Memory
Layer 5: Intelligence Observatory → Timeline, patterns, observability

Nothing is wasted. Every decision becomes a recipe. Every recipe becomes a signal. Every signal becomes knowledge. Every piece of knowledge becomes intelligence.

Why This Matters Now

The AI ecosystem is exploding. In the past 6 months, the star counts have shifted dramatically:

These aren't just tools. They're pieces of a stack that no one has fully built yet.

Context engineering replaced vibe coding. Agent harnesses replaced agent frameworks. Persistent memory replaced stateless conversations. Spec-driven development replaced ad-hoc prompts.

But they're all disconnected. They talk to each other through APIs and conventions, not through a unified architecture.

The Sovereign Intelligence Stack is the glue. It's the operating system that makes all of these pieces work together.

Layer 1: The Recipe Compiler

Every AI decision should be captured as an immutable record. This is the foundation.

Without this, you have no history. You have no way to know why a model made a decision, what memory it used, what the outcome was. You're flying blind.

The Recipe Compiler captures:

• Objective — What was the task?
• Model — Which model was used?
• Memory — What memory was injected?
• Prompt — What was the prompt (with versioning)?
• Reasoning Patterns — What reasoning patterns were used?
• Evaluation — How was it evaluated?
• Outcome — What was the result?
• Timestamps — When was it captured?

Here's what it looks like in code:

@dataclass
class Recipe:
    """Immutable AI decision record."""
    
    # Objective - what was the task?
    objective: str
    
    # Core identity
    id: str = field(default_factory=lambda: 
        f"recipe-{datetime.now().strftime('%Y%m%d-%H%M%S')}-{uuid.uuid4().hex[:8]}")
    model_name: str
    memory_context: str
    prompt_version: int = 1
    prompt_text: str
    reasoning_patterns: list = field(default_factory=list)
    evaluation_method: str
    evaluation_score: float = 0.0
    outcome: str
    outcome_details: str = ""
    created_at: datetime = field(default_factory=datetime.now)
    tags: list = field(default_factory=list)
    metadata: dict = field(default_factory=dict)

The storage layer uses SQLite with FTS5 (full-text search) for performance:

class SchemaManager:
    def __init__(self, db_path: str):
        self.db_path = db_path
        self.init_schema()
    
    def init_schema(self):
        with self.get_connection() as conn:
            conn.executescript("""
                CREATE TABLE IF NOT EXISTS recipes (
                    id TEXT PRIMARY KEY,
                    objective TEXT NOT NULL,
                    model_name TEXT NOT NULL,
                    memory_context TEXT,
                    prompt_version INTEGER DEFAULT 1,
                    prompt_text TEXT NOT NULL,
                    reasoning_patterns TEXT,
                    evaluation_method TEXT,
                    evaluation_score REAL DEFAULT 0.0,
                    outcome TEXT NOT NULL,
                    outcome_details TEXT,
                    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
                    tags TEXT,
                    metadata TEXT
                );
                
                -- Full-text search index
                CREATE VIRTUAL TABLE recipes_fts USING fts5(
                    objective, prompt_text, outcome,
                    content='recipes', content_rowid='id'
                );
            """)

This is Git for AI. Every recipe is an immutable commit. You can search across all decisions made. You can track how prompts evolve. You can see which models perform best on which tasks.

Why SQLite + FTS5?

Three reasons:

1. Local-first — No external dependencies. Runs on your machine, offline, forever.
2. FTS5 is fast — Full-text search at query time, not build time.
3. Immutable records — Append-only schema. Recipes are never modified, only extended.

Layer 2: The Expert Signal Router

Not all tasks are equal. A simple lookup doesn't need expert evaluation. A complex reasoning task does.

The Signal Router classifies tasks into three categories:

@dataclass
class SignalClassification:
    """Classification of a signal as cheap/expert/hybrid."""
    signal_id: str
    classification: str  # "cheap", "expert", "hybrid"
    reasoning: str
    confidence: float
    suggested_path: str

The router doesn't just classify — it routes. Each classification maps to an evaluation path:

class SignalRouter:
    def __init__(self):
        self.classifier = SignalClassifier()
        self.evaluation_paths = {
            "cheap": [self._cheap_path],
            "expert": [self._expert_path],
            "hybrid": [self._cheap_path, self._expert_path]
        }
    
    def route(self, signal: SignalDefinition) -> RoutingDecision:
        """Route a signal to the appropriate evaluation path."""
        classification = self.classifier.classify(signal)
        
        path = self.evaluation_paths[classification.classification]
        results = []
        
        for evaluator in path:
            result = evaluator(signal)
            results.append(result)
            
            # For hybrid: stop if cheap succeeds
            if classification.classification == "hybrid" and result.success:
                break
        
        return RoutingDecision(
            signal=signal,
            classification=classification,
            path=path,
            results=results
        )

This is expert systems meets agent routing. The router learns over time — as recipes accumulate, it can make more intelligent routing decisions.

Layer 3: The Autonomous Evaluation Loop

This is where intelligence compounds.

The evaluation loop doesn't just check correctness — it generates new test cases, detects drift, and self-improves.

Signal Definitions

class SignalRegistry:
    """Central registry for all evaluation signals."""
    
    def __init__(self):
        self._signals = {}
    
    def register(self, signal: EvaluationSignal):
        """Register a new signal definition."""
        self._signals[signal.name] = signal
        self._validate_signal(signal)
    
    def get(self, name: str) -> Optional[EvaluationSignal]:
        return self._signals.get(name)
    
    def get_all(self) -> List[EvaluationSignal]:
        return list(self._signals.values())

Drift Detection

Signals can drift over time — the definition of "correct" changes as the system evolves. The drifter catches this:

class SignalDrifter:
    """Detects when evaluation signals have drifted."""
    
    def __init__(self):
        self.history = []  # Historical signal definitions
    
    def add_signal(self, signal: EvaluationSignal):
        """Add a new signal definition to history."""
        self.history.append(signal)
        self._check_for_drift(signal)
    
    def _check_for_drift(self, new_signal: EvaluationSignal):
        """Check if the new signal has drifted from the previous version."""
        if len(self.history) > 0:
            prev = self.history[-1]
            drift_detected = False
            
            # Check for changes in validation criteria
            if prev.validation_criteria != new_signal.validation_criteria:
                drift_detected = True
            
            # Check for changes in expected results
            if prev.expected_results != new_signal.expected_results:
                drift_detected = True
            
            if drift_detected:
                self._log_drift(new_signal)

Autonomous Loop

The loop runs continuously:

class EvaluationLoop:
    """Autonomous evaluation loop that generates and evaluates signals."""
    
    def __init__(self, config: EvaluationLoopConfig):
        self.config = config
        self.generator = TestCaseGenerator()
        self.drifter = SignalDrifter()
        self._running = False
        self._iteration = 0
    
    async def run(self):
        """Run the autonomous evaluation loop."""
        self._running = True
        while self._running:
            self._iteration += 1
            
            # Generate new test cases
            test_cases = self.generator.generate(
                self.config.signal_names,
                count=self.config.test_count
            )
            
            # Evaluate against existing recipes
            results = await self._evaluate_test_cases(test_cases)
            
            # Update signal definitions based on results
            self.drifter.add_signal(results)
            
            # Log progress
            self._log_progress()
            
            # Wait before next iteration
            await asyncio.sleep(self.config.interval_seconds)

This is reinforcement learning for evaluation. The loop doesn't just check — it generates new ways to check, detects when its own checks are drifting, and improves over time.

Layer 4: Knowledge Systems

Two pillars: GraphRAG and Persistent Memory.

GraphRAG

GraphRAG combines vector similarity search with knowledge graph relationships. It's not just "find similar text" — it's "find similar text AND trace the relationships."

class GraphRAG:
    """Hybrid retrieval combining vector and graph search."""
    
    def __init__(self, vector_store: VectorStore, graph: KnowledgeGraph):
        self.vector_store = vector_store
        self.graph = graph
        self._alpha = 0.5  # Weight for vector vs graph results
    
    def retrieve(self, query: str, top_k: int = 10) -> GraphRAGResult:
        """Perform hybrid retrieval."""
        # Vector search
        vector_results = self.vector_store.search(query, top_k=top_k)
        
        # Graph search
        graph_results = self._graph_search(query, top_k=top_k)
        
        # Combine results
        combined = self._combine_results(vector_results, graph_results)
        
        return GraphRAGResult(
            query=query,
            vector_results=vector_results,
            graph_results=graph_results,
            combined_results=combined,
            retrieval_time_ms=combined["retrieval_time_ms"]
        )

The knowledge graph has 3,468 edges (from my earlier work on knowledge graphs). Each node represents a concept, each edge represents a relationship. When you retrieve, you're not just finding similar text — you're tracing through the knowledge graph to find related concepts.

Persistent Memory

Agents need memory that persists across sessions. Not just "remember what I said last time" — but project-based, context-aware memory that compounds.

class MemoryStorage:
    """Persistent memory storage with pruning."""
    
    def __init__(self, db_path: str):
        self.db_path = db_path
        self.init_schema()
    
    def add_memory(self, content: str, project_id: str, 
                   relevance_score: float = 0.5) -> MemoryEntry:
        """Add a memory entry with relevance scoring."""
        entry = MemoryEntry(
            id=f"mem-{datetime.now().strftime('%Y%m%d-%H%M%S')}-{uuid.uuid4().hex[:8]}",
            content=content,
            project_id=project_id,
            relevance_score=relevance_score,
            created_at=datetime.now(),
            last_accessed=datetime.now()
        )
        self._store_memory(entry)
        return entry

The memory system tracks:

• Relevance score — How useful was this memory?
• Last accessed — When was it last used?
• Access frequency — How often is it used?
• Project context — What project was it created for?

Over time, irrelevant memories are pruned. Relevant memories are retained and prioritized. This is cognitive pruning — the same thing that happens in human memory.

Layer 5: Intelligence Observatory

The observatory turns data into insight. It doesn't just store decisions — it tells you what they mean.

Intelligence Timeline

class IntelligenceTimeline:
    """Generates intelligence timelines from recipe data."""
    
    def __init__(self, recipe_store: RecipeStorage):
        self.recipe_store = recipe_store
    
    def generate(self, project_id: str, 
                 start_date: datetime, 
                 end_date: datetime) -> dict:
        """Generate an intelligence timeline."""
        recipes = self.recipe_store.get_by_project(
            project_id, start_date, end_date
        )
        
        timeline = {
            "project_id": project_id,
            "period": f"{start_date} to {end_date}",
            "total_recipes": len(recipes),
            "models_used": self._extract_models(recipes),
            "avg_quality": self._calculate_avg_quality(recipes),
            "quality_trend": self._calculate_quality_trend(recipes),
            "prompts_used": self._extract_prompts(recipes),
            "prompts_improved": self._detect_prompt_improvements(recipes),
            "errors_detected": self._detect_errors(recipes)
        }
        
        return timeline

Pattern Detection

class PatternDetector:
    """Detects patterns in intelligence data."""
    
    def detect_prompt_optimization(self, recipes: List[Recipe]) -> dict:
        """Detect prompt optimization patterns."""
        patterns = {}
        
        # Group by prompt version
        by_version = self._group_by_version(recipes)
        
        for version, version_recipes in by_version.items():
            avg_quality = self._calculate_avg_quality(version_recipes)
            
            if version > 1:
                prev_recipes = by_version.get(version - 1, [])
                if prev_recipes:
                    prev_quality = self._calculate_avg_quality(prev_recipes)
                    improvement = avg_quality - prev_quality
                    
                    if improvement > 0:
                        patterns[f"v{version}"] = {
                            "avg_quality": avg_quality,
                            "improvement": improvement,
                            "recipes": len(version_recipes)
                        }
        
        return patterns

Putting It All Together: The Compounding Effect

Here's what happens when these layers work together:

1. Day 1: You capture a recipe for a simple task. The recipe compiler stores it.
2. Day 2: You capture 10 more recipes. The signal router learns to classify tasks.
3. Day 3: The evaluation loop generates test cases based on the recipes.
4. Day 7: You have 100 recipes. The knowledge graph has 50 nodes and 200 edges.
5. Day 14: The observatory shows you that your prompts improved by 15% over two weeks.
6. Day 30: You have 1,000 recipes, 500 nodes, and your system is self-improving.

This is compounding. Each day makes the next day better. The system is learning from itself.

The Code

The working implementation is in the sovereign-intelligence-stack repository:

• Recipe Compiler: SQLite + FTS5, 14 tests passing
• Signal Router: Expert signal classification, 10 tests passing
• Evaluation Loop: Autonomous self-improvement, 21 tests passing
• Apprenticeship Engine: Phased autonomy, 14 tests passing
• Knowledge Graph: NetworkX, 3,468+ edges pattern
• Memory Storage: SQLite with relevance scoring

Total: 59 tests passing across all verified components.

What This Enables

With this stack, you can:

1. Track intelligence evolution — See how your AI system improves over time
2. Debug failures — Every failure is a recipe you can investigate
3. Optimize prompts — See which prompts work and why
4. Self-improve — The evaluation loop generates new ways to evaluate
5. Build knowledge — The knowledge graph accumulates over time
6. Maintain sovereignty — All data stays local, all decisions are captured

The Philosophy

This is not about building a better model. It's about building a better system for accumulating intelligence.

The model is a snapshot. The loop is the engine. The recipes are the fuel. The observability is the dashboard.

Intelligence is accumulated decisions. If you're not capturing decisions, you're not building intelligence — you're building amnesia.

Next Steps

The stack is working. The tests pass. The architecture is sound.

What's next?

1. Complete the knowledge graph — Integrate with the full 3,468-edge knowledge graph
2. Build the observatory dashboard — Next.js frontend for the timeline
3. Add the apprenticeship engine — Phased autonomy for agents
4. Connect to real LLMs — Ollama integration for local inference
5. Measure compounding — Track intelligence growth over time

The foundation is solid. The rest is engineering.

References

• Architecture of Autonomy
• The Model Is Not the Product
• Building Autonomous Sovereign AI
• Context Engineering
• GraphRAG (70K+ stars)
• Agent Harnesses (225K stars)
• Claude Mem (85K stars)
• Context Engineering (13.5K stars)

Related Posts

• Sovereign AI Architecture — Comprehensive synthesis of four years of work
• Getting Started with Sovereign AI — Beginner on-ramp
• Local AI Architecture — Local-first implementation guide
• Retrieval Architecture — Memory and retrieval systems

Related Repositories

• Sovereign Memory Bank — 7-layer autonomous cognitive memory
• Dynamic Persona MoE RAG — Persona-driven mixture-of-experts
• Objective05 — Persistent intelligence infrastructure in Rust
• SovereignSpec — Spec-driven development engine

Building sovereign AI infrastructure that compounds. Intelligence is accumulated decisions, not models.

July 3, 2026

The model is no longer the product. The loop is.

That idea keeps getting reinforced every time I look at new research from Apple, LMSYS, and the recent work on autoresearch and constrained optimization. They're not converging on a better chatbot. They're converging on something closer to a reconfigurable system of computation where "reasoning" is just one phase inside a larger machine.

What's changing isn't just capability. It's where intelligence lives.

It's shifting out of the model and into three places at once: residual state, execution graphs, and optimization loops.

This isn't abstract. Each of these threads has concrete implementations — and when you wire them together, you get something that looks less like a chatbot and more like a continuously recompiled cognitive engine. I've been building toward this architecture across several systems: Objective05 (persistent intelligence infrastructure in Rust), Sovereign Memory Bank (7-layer autonomous cognitive memory), Dynamic Persona MoE RAG (persona-driven mixture-of-experts over local graphs), and SovereignSpec (spec-driven development with GraphRAG). This post is the synthesis of what those systems are converging on — and what the research confirms.

1. From Tokens to Residual State

Apple's Residual Context Diffusion

Apple's Residual Context Diffusion (RCD) quietly breaks one of the core assumptions behind most LLM systems: that intermediate uncertainty should be discarded.

Paper: Residual Context Diffusion Language Models — arXiv:2601.22954 (Hu et al., 2026) Code: github.com/yuezhouhu/residual-context-diffusion

In standard generation pipelines, we sample, reject, and move on. Low-confidence paths disappear. Only the final sequence matters.

RCD changes that. Instead of throwing away "failed" intermediate states during diffusion, it feeds them forward as contextual residuals — entropy-weighted continuous embedding vectors injected into subsequent denoising steps.

Here's the core mechanism in pseudocode:

import torch
import torch.nn.functional as F

def residual_diffusion_step(
    x_t: torch.Tensor,           # masked embedding at step t
    logits: torch.Tensor,        # model logits over vocabulary
    embed_weight: torch.Tensor,  # vocabulary embedding matrix
    residual_buffer: list,       # accumulated residuals from prior steps
    temperature: float = 1.0,
    entropy_threshold: float = 0.5,
) -> tuple[torch.Tensor, torch.Tensor]:
    """
    One step of RCD decoding.

    Instead of hard-committing to argmax tokens and discarding the rest,
    RCD converts the full predictive distribution into a residual vector
    and feeds it forward into the next step.
    """
    # Compute token probabilities
    probs = F.softmax(logits / temperature, dim=-1)

    # Entropy-weighted residual: sum over vocab weighted by uncertainty
    # High-entropy (uncertain) positions contribute more residual signal
    entropy = -(probs * torch.log(probs + 1e-8)).sum(dim=-1, keepdim=True)
    normalized_entropy = entropy / entropy.max()

    # Residual = weighted sum of all vocabulary embeddings
    # NOT just the argmax token — every candidate contributes
    residual = torch.einsum("b v, v d -> b d", probs, embed_weight)
    residual = residual * (normalized_entropy > entropy_threshold).float()

    # Accumulate residual into buffer
    residual_buffer.append(residual.detach())

    # Blend: combine original masked embedding with residual history
    # The mixing weight is itself entropy-dependent
    blend_weight = torch.sigmoid(2.0 * normalized_entropy - 1.0)
    x_next = (1 - blend_weight) * x_t + blend_weight * residuals.mean(dim=0)

    return x_next, probs

That sounds like a small tweak. It isn't.

Results: RCD achieves 5–10 point accuracy gains on frontier diffusion LLMs, nearly 2× baseline on AIME, and 4–5× fewer denoising steps at equivalent accuracy — all from converting a standard dLLM with ~300M tokens of additional training. The paper shows this works because the residual buffer captures discarded hypotheses, low-probability reasoning paths, and partial structures that didn't resolve cleanly — everything we normally optimize away becomes state for the next iteration.

What This Means for System Architecture

In most LLM systems (including RAG), memory is treated as retrieval:

def standard_rag(query: str, top_k: int = 5) -> str:
    embedding = embedder.embed(query)
    results = vector_store.similarity_search(embedding, k=top_k)
    return format_context(results)

But RCD suggests a different model:

Memory is not retrieval. Memory is residue.

In my Sovereign Memory Bank architecture (post, repo), I implemented exactly this principle through the 7-layer memory hierarchy. Layer 0 (source) and Layer 1 (extracted concepts/claims/entities) are the residual accumulation layer — nothing is discarded, everything feeds forward:

# From Sovereign Memory Bank's memory hierarchy:
# Every extraction round preserves all intermediate representations
# as first-class graph nodes, regardless of "confidence"

class ExtractedClaim(BaseModel):
    text: str
    source_chunk_id: str
    confidence: float  # low-confidence claims are NOT filtered — they persist
    residual_embedding: list[float]  # distributional residual, not just argmax
    extraction_round: int  # provenance for evolution tracking
    status: Literal["candidate", "verified", "contradicted", "superseded"]

The principle is structural: even failure becomes state. In the context of Dynamic Persona MoE RAG (post, repo), this means a persona that produces a low-confidence response doesn't get ignored — its partial output feeds into the next persona's conditioning. The activation_cost and historical_performance fields on each persona schema become the residual signal that shapes future routing decisions.

2. From Tool Use to Executable Systems

LMSYS and SGLang Agents

The LMSYS work on agent-assisted SGLang development pushes the next abstraction shift: the agent is no longer just a consumer of tools. It becomes part of the system that defines execution.

Paper: SGLang: Efficient Execution of Structured Language Model Programs — arXiv:2312.07104 (Zheng et al., NeurIPS 2024) Repo: github.com/sgl-project/sglang (29.9k+ stars, 400k+ GPUs in production)

Instead of:

prompt → model → tool call → result

We start seeing:

agent → compiles execution graph → optimizes inference paths → rewrites runtime behavior → executes

SGLang already treats inference as a structured program through its Python-embedded DSL with primitives like gen, select, fork, join, and extend. What the agent layer adds is adaptability at the level of the execution graph itself.

Here's how SGLang represents a multi-step inference as a compilable graph:

import sglang as sgl

@sgl.function
def multi_step_reasoning(context: str, question: str):
    """
    SGLang compiles this into a computational graph
    that the runtime can optimize via code motion,
    instruction selection, and auto-tuning.
    """
    # Step 1: Analyze context
    analysis = sgl.gen("analysis", max_tokens=256)
    
    # Step 2: Fork — explore multiple reasoning paths in parallel
    fork_context = sgl.fork(3)
    with fork_context:
        hypothesis_1 = sgl.gen("path_1", max_tokens=128, temperature=0.3)
        hypothesis_2 = sgl.gen("path_2", max_tokens=128, temperature=0.7)
        hypothesis_3 = sgl.gen("path_3", max_tokens=128, temperature=0.9)
    
    # Step 3: Join — synthesize across paths
    sgl.join()
    synthesis = sgl.gen("synthesis", max_tokens=256)
    
    # Step 4: Constrained decode — output must match JSON schema
    final = sgl.gen(
        "final",
        max_tokens=512,
        schema={
            "type": "object",
            "properties": {
                "answer": {"type": "string"},
                "confidence": {"type": "number"},
                "reasoning_paths": {
                    "type": "array",
                    "items": {"type": "string"}
                }
            },
            "required": ["answer", "confidence"]
        }
    )
    return final

The runtime applies RadixAttention — a radix-tree LRU cache for KV tensors that enables automatic prefix reuse across calls. If the same context prefix appears in a later query, the KV cache is reused rather than recomputed. This gives up to 6.4× higher throughput vs vLLM on agent/reasoning/RAG/multi-turn workloads.

The critical architectural property: the execution graph is mutable at runtime. An agent can observe its own inference pattern and rewrite the execution graph — adding branches, merging paths, reordering operations — by generating new SGLang programs that describe the next iteration's structure.

What This Means for System Architecture

This matters because it dissolves the boundary between "model reasoning" and "system architecture."

The agent is no longer sitting on top of the stack. It is partially responsible for constructing the stack on each run.

Most agent frameworks today assume:

• Static tool definitions
• Fixed orchestration logic
• Stable execution pipelines

But real systems under SGLang-style design become:

• Dynamic execution graphs
• Query-dependent compilation
• Runtime-optimized inference paths

In my Objective05 architecture (post, repo), this maps directly onto the EventEngine and SchedulerService pattern. The scheduler emits typed events onto a message bus; pipeline workers consume events and dispatch to ingestion/extraction/correlation/maintenance functions. The critical insight from Objective05 is that the pipeline topology itself is query-dependent — different document types trigger different extraction chains, and the correlation engine's merge logic is parameterized by entity type and temporal proximity:

// From Objective05's EventEngine design:
// Execution paths are not fixed — they're compiled per event type

enum PipelineStage {
    Ingest { source: SourceAdapter },
    Extract { method: ExtractionMethod },   // heuristic vs LLM
    Correlate { threshold: f64 },           // merge threshold per entity type
    Maintain { action: MaintenanceAction }, // archive, promote, notify
}

struct ExecutionGraph {
    stages: Vec<PipelineStage>,             // compiled per event class
    cache_hint: Option<RadixKey>,           // KV cache strategy
    timeout: Duration,                      // budget constraint
}

impl SchedulerService {
    fn compile_graph(&self, event: &Event) -> ExecutionGraph {
        // The execution graph is generated — not hardcoded
        match event.class {
            EventClass::Financial => ExecutionGraph {
                stages: vec![
                    PipelineStage::Extract { method: ExtractionMethod::LLM },
                    PipelineStage::Correlate { threshold: 0.85 },
                ],
                cache_hint: Some(RadixKey::from(event.entity_id())),
                timeout: Duration::from_secs(30),
            },
            EventClass::Social => ExecutionGraph {
                stages: vec![
                    PipelineStage::Extract { method: ExtractionMethod::Heuristic },
                    PipelineStage::Correlate { threshold: 0.6 },
                    PipelineStage::Maintain { action: MaintenanceAction::Flag },
                ],
                cache_hint: None,  // social events have low cache reuse
                timeout: Duration::from_secs(10),
            },
        }
    }
}

Which leads to a harder conclusion:

If the execution graph is mutable, then "the system" is not static software. It is a generated artifact. And agents are compilers.

3. From Loops to Constrained Optimization

Autoresearch Systems as Formal Search Spaces

The third piece is more subtle, but it completes the picture.

Autoresearch-style systems framed through constrained optimization treat agent loops not as "iteration until better answer," but as structured search over a bounded space of possible reasoning trajectories.

Key references:

• Karpathy's autoresearch — github.com/karpathy/autoresearch: minimal agent loop (700 experiments in 2 days on H100, 20 optimizations discovered)
• Bilevel Autoresearch (Qu & Lu, 2026) — arXiv:2603.23420: outer loop optimizes inner loop's search mechanism
• Agent Contracts (Ye & Tan, 2026) — arXiv:2601.08815: formal resource-bounded agent execution with conservation laws
• CCPO (Si et al., 2026) — arXiv:2511.11828: conformal constrained policy optimization for cost-effective agents
• EvoTrainer (2026) — arXiv:2606.03108: co-evolving LLM policies and training harnesses

Instead of:

generate → critique → refine → repeat

We get:

explore hypothesis space → evaluate against constraints → allocate compute dynamically → converge under budgeted uncertainty

Here's what that looks like as a formal optimization loop:

from dataclasses import dataclass
from enum import Enum
from typing import Callable, Generic, TypeVar

State = TypeVar("State")
Action = TypeVar("Action")

class ResourceConstraint(Enum):
    TOKENS = "tokens"
    API_CALLS = "api_calls"
    ITERATIONS = "iterations"
    LATENCY_MS = "latency_ms"
    COST_USD = "cost_usd"

@dataclass
class Budget:
    """Formal resource budget from the Agent Contracts framework."""
    limits: dict[ResourceConstraint, float]
    consumed: dict[ResourceConstraint, float]

    def remaining(self, constraint: ResourceConstraint) -> float:
        return self.limits.get(constraint, float("inf")) - self.consumed.get(constraint, 0.0)

    def within_budget(self) -> bool:
        return all(
            self.consumed.get(k, 0.0) <= v
            for k, v in self.limits.items()
        )

@dataclass
class Trajectory:
    """A complete reasoning trajectory, not just the final answer."""
    steps: list[tuple[State, Action, float]]  # state, action, reward
    total_cost: float
    total_tokens: int

class ConstrainedOptimizationLoop(Generic[State, Action]):
    """
    An agent loop framed as constrained optimization over
    a bounded space of reasoning trajectories.

    Reference: CCPO (Si et al., 2026) + Agent Contracts (Ye & Tan, 2026)
    """

    def __init__(
        self,
        explore_policy: Callable[[State, Budget], Action],
        exploit_policy: Callable[[State, Budget], Action],
        evaluate: Callable[[Trajectory], float],
        budget: Budget,
        confidence_target: float = 0.95,
    ):
        self.explore = explore_policy   # cheap model for exploration
        self.exploit = exploit_policy   # expensive model for exploitation
        self.evaluate = evaluate        # objective function
        self.budget = budget
        self.confidence_target = confidence_target
        self.trajectories: list[Trajectory] = []

    def step(self, state: State) -> Action:
        """Adaptive action selection based on remaining budget and uncertainty."""
        uncertainty = self._estimate_uncertainty(state)
        remaining = self.budget.remaining(ResourceConstraint.TOKENS)

        # The explore/exploit decision is itself computed — not hardcoded
        if uncertainty > self.confidence_target and remaining > 1000:
            # Explore: cheap model, wide search
            return self.explore(state, self.budget)
        else:
            # Exploit: expensive model, precise answer
            return self.exploit(state, self.budget)

    def _estimate_uncertainty(self, state: State) -> float:
        """Conformal prediction over past trajectory outcomes."""
        if len(self.trajectories) < 10:
            return 1.0  # maximum uncertainty, always explore early
        return 1.0 - self._coverage_estimate()

    def _coverage_estimate(self) -> float:
        """Empirical coverage of correct answers in prediction sets."""
        correct = sum(1 for t in self.trajectories[-20:] if t.steps[-1][2] > 0.5)
        return correct / min(len(self.trajectories), 20)

The key shift is that the loop is no longer informal.

It has geometry:

• Constraints (compute, latency, hallucination risk, API budget)
• Objectives (accuracy, novelty, coherence, utility)
• Tradeoffs between exploration and exploitation, formalized via conformal prediction

This is important because it forces something most agent systems avoid: you have to define what "better" actually means in system terms.

In my Building Autonomous Sovereign AI post, I described this as the Inner Loop vs Outer Loop separation. The Inner Loop executes tasks; the Outer Loop observes performance and drives improvement. The Karpathy-style autoresearch system is the purest form — a model edits its own training script, runs for exactly 5 minutes, measures val_bpb, and keeps or discards the change. The binary keep/discard criterion is the objective function. The 5-minute wall-clock window is the resource constraint. The single editable file (train.py) is the trust boundary.

# From Karpathy's autoresearch pattern:
# The loop is the product. The model is a component.

class AutoresearchLoop:
    """
    Minimal constrained optimization over research trajectories.

    Key design decisions:
    - Fixed time budget per experiment (5 min)
    - Single mutable file (train.py)
    - Binary acceptance criterion (val_bpb improvement)
    """

    def __init__(self, experiment_dir: Path, time_budget_s: int = 300):
        self.experiment_dir = experiment_dir
        self.time_budget_s = time_budget_s
        self.history: list[ExperimentResult] = []
        self.best_bpb = float("inf")

    def propose_change(self, model, context: str) -> str:
        """Generate a code change hypothesis."""
        prompt = f"""Current validation bits-per-byte: {self.best_bpb:.4f}
History: {len(self.history)} experiments, {'improving' if self._trend() > 0 else 'plateauing'}

Propose a single-file change to train.py that could improve val_bpb.
Strategy: {context}
Return ONLY the diff."""
        diff = model.generate(prompt)
        return diff

    def execute(self, diff: str) -> ExperimentResult:
        """Apply change, run with fixed budget, measure outcome."""
        backup = (self.experiment_dir / "train.py").read_text()
        try:
            # Apply proposed change
            result = subprocess.run(
                ["git", "apply"],
                input=diff, text=True, capture_output=True, cwd=self.experiment_dir
            )
            if result.returncode != 0:
                return ExperimentResult(diff=diff, val_bpb=None, accepted=False)

            # Run with hard time budget
            start = time.time()
            proc = subprocess.run(
                ["python", "train.py"],
                timeout=self.time_budget_s, cwd=self.experiment_dir,
                capture_output=True, text=True
            )
            elapsed = time.time() - start

            # Parse validation metric
            val_bpb = self._parse_val_bpb(proc.stdout)
            accepted = val_bpb is not None and val_bpb < self.best_bpb
            if accepted:
                self.best_bpb = val_bpb

            return ExperimentResult(
                diff=diff, val_bpb=val_bpb,
                elapsed_s=elapsed, accepted=accepted
            )
        finally:
            (self.experiment_dir / "train.py").write_text(backup)

    def _trend(self) -> float:
        if len(self.history) < 5:
            return 0.0
        recent = [r.val_bpb for r in self.history[-5:] if r.val_bpb is not None]
        return (recent[0] - recent[-1]) / len(recent) if len(recent) >= 2 else 0.0

The Bilevel Autoresearch extension (Qu & Lu, 2026) takes this further: the outer loop doesn't just propose changes to the training script — it generates the search strategy itself (Tabu Search, Bandit, Orthogonal Exploration) as executable Python code, achieving 5× improvement over the inner loop alone.

4. Putting It Together: Residual Systems, Compiled Agents, and Optimization Loops

These three threads — Apple's residual diffusion framing, LMSYS's execution graph agents, and autoresearch/constrained optimization — aren't separate ideas. They're three layers of the same transition.

They map cleanly onto a new system stack that my projects are converging on:

Layer 1: Residual State (Memory)

• Not retrieval-based RAG
• But persistent accumulation of: failed reasoning, partial structures, unresolved hypotheses
• Memory becomes a living substrate, not a lookup table

In Sovereign Memory Bank (post, repo), this is Layers 0–2 of the 7-layer hierarchy: source documents → extracted concepts/claims/entities → structured relationships. The evolution engine autonomously merges, splits, promotes, and deprecates nodes based on incoming evidence — exactly the RCD principle applied at system scale.

Layer 2: Execution Graphs (Compute)

• Not static tool calling
• But dynamic inference compilation
• Agents participate in shaping runtime structure
• Execution becomes query-specific and mutable

In SovereignSpec (post, repo), this is the 12-step compilation pipeline: parse → validate → resolve_deps → check_contradictions → compute_drift → generate_plan → generate_tasks → generate_context → generate_docs → update_knowledge_graph → update_embeddings → commit_version. Each invocation compiles a new execution graph for the spec being processed, with the GraphEngine computing dependency chains and impact analysis via NetworkX.

In Objective05 (post, repo), the SchedulerService emits typed events onto a message bus — pipeline workers consume and dispatch to ingestion/extraction/correlation/maintenance functions. The pipeline topology per event is not hardcoded; it's compiled per event class with different cache strategies, timeouts, and processing chains.

Layer 3: Constrained Loops (Reasoning)

• Not open-ended generation
• But optimization over trajectories
• Bounded by compute, uncertainty, and objective functions

In the Dynamic Persona MoE RAG system (post, repo), the routing decision (which persona to activate for a query) is itself a constrained optimization. Each persona has an activation_cost; the router balances persona expertise against total compute budget. The historical_performance field feeds back into the routing policy, creating the explore/exploit dynamic formalized by CCPO.

# From Dynamic Persona MoE RAG: persona routing as constrained optimization

@dataclass
class Persona:
    name: str
    expertise: list[str]
    traits: dict[str, float]  # 1-9 scale
    activation_cost: int      # tokens consumed per invocation
    historical_performance: float  # running accuracy score
    last_activated: float      # timestamp for recency weighting

class ConstrainedPersonaRouter:
    """
    Routes queries to personas under resource constraints.

    This is the Layer 3 (Constrained Loops) instantiation in MoE RAG.
    """

    def __init__(self, personas: list[Persona], budget: Budget):
        self.personas = personas
        self.budget = budget

    def select(
        self,
        query: str,
        query_embedding: list[float],
        top_k: int = 3,
    ) -> list[Persona]:
        """
        Select top-k personas under budget constraints.

        Uses a scoring function that blends:
        1. Semantic similarity (query → persona expertise)
        2. Activation cost penalty
        3. Historical performance bonus
        4. Recency bonus (favor recently validated personas)
        """
        candidates = []
        remaining_tokens = self.budget.remaining(ResourceConstraint.TOKENS)

        for persona in self.personas:
            if persona.activation_cost > remaining_tokens:
                continue  # prune — violates budget constraint

            # Similarity + cost-aware scoring
            expertise_sim = cosine_similarity(query_embedding, persona_expertise_embedding(persona))
            cost_penalty = persona.activation_cost / 1000
            perf_bonus = persona.historical_performance * 0.3

            score = expertise_sim - cost_penalty + perf_bonus
            candidates.append((score, persona))

        candidates.sort(key=lambda x: x[0], reverse=True)
        selected = [p for _, p in candidates[:top_k]]

        # Deduct from budget
        total_cost = sum(p.activation_cost for p in selected)
        self.budget.consumed[ResourceConstraint.TOKENS] = (
            self.budget.consumed.get(ResourceConstraint.TOKENS, 0) + total_cost
        )

        return selected

The Unified Architecture

When combined, something new emerges:

A system where intelligence is not located in the model, but in the interaction between:

• residual memory (Sovereign Memory Bank, RCD)
• compiled execution (SGLang agents, Objective05 EventEngine, SovereignSpec pipeline)
• constrained iteration (autoresearch loops, CCPO, Dynamic MoE RAG router)

This is the architecture I described in the Sovereign Synthesis — the 7-layer unified architecture where Interface (Next.js) → API (FastAPI) → Orchestration (MoE/DeerFlow) → Governance (Control Boundary) → Reasoning (Persona Engine/SpecGen) → Memory (NetworkX + ChromaDB) → Inference (Ollama/llama.cpp). The three layers in this post (residual state, execution graphs, constrained loops) map directly onto the Memory, Reasoning, and Governance layers of the Synthesis.

5. What This Implies for Agent Systems

If you're building something like Dynamic Persona MoE RAG, Hermes-style orchestration, Objective05, Sovereign Memory Bank, or any autoresearch loop system, the implication is simple but uncomfortable:

Most current architectures are only simulating parts of this stack.

• RAG simulates memory, but discards residue
• Tool-using agents simulate execution, but don't compile graphs
• Prompt loops simulate optimization, but don't formalize objectives

The next step is not "better prompting" or "bigger models."

It is structural:

1. Stop treating failed outputs as waste. Treat them as state. — Implement residual accumulation (RCD-style) in your memory layer. Sovereign Memory Bank's evolution engine does this; so does Objective05's event merge pattern.

2. Stop treating execution as fixed. Treat it as compiled per query. — Generate execution graphs at runtime. Objective05's compile_graph() and SovereignSpec's 12-step pipeline are examples. SGLang shows how to make this efficient with RadixAttention.

3. Stop treating iteration as narrative. Treat it as constrained optimization. — Formalize your budget, objective function, and explore/exploit policy. CCPO and Agent Contracts provide the mathematical framework. Karpathy's autoresearch shows the minimal viable implementation.

Once you do that, the system stops looking like an LLM application.

It starts looking like a continuously recompiled cognitive engine.

6. Closing

The model is not the product anymore because it was never the full system in the first place.

What's emerging now is something closer to a programmable cognition substrate:

• memory that accumulates error as structure
• execution that compiles itself per task
• reasoning that optimizes under constraint

In that world, the interesting question is no longer:

"What can the model do?"

It becomes:

"What kind of loop are you running, and what does it optimize for?"

And that's where everything starts to converge.

References

1. Hu et al. Residual Context Diffusion Language Models. arXiv:2601.22954, 2026
2. Zheng et al. SGLang: Efficient Execution of Structured Language Model Programs. arXiv:2312.07104, NeurIPS 2024
3. Karpathy. autoresearch. GitHub, 2026
4. Qu & Lu. Bilevel Autoresearch. arXiv:2603.23420, 2026
5. Ye & Tan. Agent Contracts: A Formal Framework for Resource-Bounded Autonomous AI Systems. arXiv:2601.08815, 2026
6. Si et al. Conformal Constrained Policy Optimization for Cost-Effective LLM Agents. arXiv:2511.11828, AAAI 2026
7. Harris & Slivkins. Should You Use Your LLM to Explore or Exploit?. arXiv:2502.00225, 2026
8. EvoTrainer. Co-Evolving LLM Policies and Training Harnesses. arXiv:2606.03108, 2026

Related Posts

• The Model Is Not the Product: On Building Persistent Intelligence Infrastructure — Objective05 deep dive
• Building Autonomous Sovereign AI: Autoresearch Loops and Expert Fine-Tuning — Inner/outer loop architecture
• Sovereign Memory Bank: Autonomous Cognitive Memory for Agent Systems — 7-layer memory hierarchy
• Dynamic Persona MoE RAG: Building Memory-Driven Synthetic Intelligence — Persona-based constrained routing
• SovereignSpec: Local-First Spec-Driven Development — 12-step compilation pipeline
• SOVEREIGN: The Unified Architecture — 7-layer convergent architecture
• Context Engineering: The Blind Spots and the Real Full-Stack Development Paradigm — Agent harnesses and persistent memory

Related Posts

• The Sovereign Intelligence Stack — Architecture implementation with working code
• The Loop Is the Product — Intelligence Observatory deep dive
• Building Autonomous Sovereign AI — Autoresearch loops and expert fine-tuning
• Getting Started with Sovereign AI — Beginner on-ramp
• Local AI Architecture — Local-first implementation guide
• Retrieval Architecture — Memory and retrieval systems

Related Repositories

• sovereign-intelligence-stack — 70 Python files, 7,757 lines
• sovereign-memory-bank — Autonomous cognitive memory
• dynamic-persona-moe-rag — Persona-driven MoE
• objective05 — Rust persistent intelligence infrastructure
• sovereignspec — Spec-driven development

Additional Research

• LMSYS/SGLang — Agentic execution graphs
• Bridgewater AIA Labs — Autonomous evaluation
• Thinking Machines Lab — Compounding intelligence
• Apple Research — Residual Context Diffusion team
• Autonomous Agent Research — arXiv search
• Compounding Intelligence Research — arXiv search

July 3, 2026

Every agent framework on the market answers the same question: how do you get a model to do a task. Almost none of them answer the question that actually determines whether your system gets better over time: what happened, in what order, under what confidence, judged by whom, and is that judgment still valid six months later.

The Sovereign Intelligence Observatory is a six-component, local-first Python system built to answer that second question. It doesn't wrap an LLM. It doesn't compete with LangGraph or CrewAI for orchestration mindshare. It sits downstream of whatever agent runtime you're already using and treats every decision that runtime makes as a first-class, versioned, queryable artifact. The project's own framing is blunt about it: intelligence isn't the weights, it's the accumulated decisions that shaped them, and if the loop is the product, observability of the loop is the operating system.

This post walks through the architecture at the code level -- the drift statistics, the sandboxing model, the ledger chain, the concurrency guarantees -- and makes the case for why this pattern matters for anyone building agents they intend to keep improving rather than keep re-prompting.

The core insight: recipes, not logs

Most agent systems produce logs. Logs are append-only text optimized for a human to read once, during an incident, and then forget. The Observatory instead produces recipes: structured, versioned artifacts that capture the complete decision context of a single agent run.

{
  "recipe_id": "recipe-20240101-120000-abc123",
  "objective": "classify_ai_paper",
  "model": "qwen3.5",
  "prompt_version": 5,
  "memory_version": 12,
  "retrieved_docs": ["doc_1", "doc_2"],
  "reasoning_patterns": ["compare", "retrieve", "synthesize"],
  "evaluation": {"score": 0.95, "reviewed_by": "expert"},
  "outcome": "accepted"
}

The distinction matters because a log is write-once and a recipe is a row in a schema. Once your agent's behavior has a schema, it can be indexed (SQLite FTS5 full-text search), diffed across prompt or memory versions, embedded and searched semantically (optional ChromaDB), streamed out as training data, and — critically — fed back into the system that decides whether your agent is getting better or worse. The Agent Recipe Compiler is the component that does the capturing; everything downstream consumes its output. The system frames this as the missing primitive most agent stacks never build, and the framing holds up: without it, "improving the agent" means eyeballing transcripts.

Architecture: six layers, one feedback loop

Agent
 |
 v
Recipe Compiler ----------------------------------------+
 |                                                      |
 v                                                      |
Expert Signal Router                                    |
 |                                                      |
 v                                                      |
Autonomous Evaluation Loop                              |
 |                                                      |
 v                                                      |
Tacit Judgment Extractor                                |
 |                                                      |
 v                                                      |
Sovereign Apprenticeship Engine                         |
 |                                                      |
 v                                                      |
Intelligence Observatory <------------------------------+
 |
 v
Intelligence Timeline -> Actionable Insights

Each layer produces the input for the next, and the Observatory at the bottom folds everything back into a timeline that determines whether the whole loop is compounding or decaying. Six components, six SQLite databases in WAL mode, one FastAPI surface per component, 176 tests across 8 suites. Let's go through them in the order data actually flows.

1. Agent Recipe Compiler — the ledger of what happened

Every run gets ingested through POST /api/recipes, indexed with SQLite FTS5, and made available for full-text and (optionally) semantic search. It supports chunked streaming JSON export specifically so recipe history can be turned into fine-tuning data later without loading the whole table into memory. This is the layer everything else is built on top of, and it's deliberately boring: SQLite, JSON, HTTP. No vector database is required to get started; ChromaDB is dependency-injected and the system falls back to FTS5 silently if it isn't installed.

2. Expert Signal Router — deciding who judges the output

Recipes tell you what happened. They don't tell you if it was any good, and worse, they don't tell you who should be bothered to find out. The router implements a tiered confidence gate:

Agent Output
    |
    v
Confidence >= 0.95?  --YES--> Auto-accepted
    |
    NO
    v
Confidence >= 0.80?  --YES--> Cheap evaluation
    |
    NO
    v
Expert review required

The thresholds aren't fixed. A dynamic calibration matrix adjusts them per objective based on historical error rate, so a task class that keeps fooling the cheap evaluator gets escalated more aggressively over time, and one that experts keep rubber-stamping gets cheaper to clear. Every expert decision the router captures becomes a labeled training example for the next tier down — this is the mechanism that lets human judgment gradually get absorbed into the automated evaluation layer instead of staying a permanent cost center.

3. Autonomous Evaluation Loop — catching drift before it becomes an outage

This is the layer I think is most underbuilt in the rest of the agent-framework ecosystem, and it's worth showing the actual math. Evaluation signals are defined as YAML specs with uncertainty bounds, synthetic test cases are auto-generated from production traffic, and every signal is checked for drift using two independent statistics that have to agree before an alert fires.

Two-sample Kolmogorov–Smirnov D-statistic, measuring how far apart two empirical distributions have drifted:

def _kolmogorov_smirnov_statistic(sample_a, sample_b):
    combined = sorted(set(sample_a + sample_b))
    max_diff = 0.0
    for val in combined:
        cdf_a = sum(1 for x in sample_a if x <= val) / len(sample_a)
        cdf_b = sum(1 for x in sample_b if x <= val) / len(sample_b)
        max_diff = max(max_diff, abs(cdf_a - cdf_b))
    return max_diff  # threshold: 0.3

Population Stability Index, measuring binned proportion shift with Laplace smoothing so empty bins don't blow up the log:

def _population_stability_index(expected, actual, n_bins=10):
    ...
    for i in range(n_bins):
        p_exp = (exp_counts[i] + 0.5) / (n_exp + 0.5 * n_bins)
        p_act = (act_counts[i] + 0.5) / (n_act + 0.5 * n_bins)
        psi += (p_act - p_exp) * math.log(p_act / p_exp)
    return psi  # threshold: 0.25

Requiring both KS and PSI to cross threshold before flagging drift is a deliberate design choice against false positives — KS is sensitive to shape changes, PSI is sensitive to mass movement between bins, and real capability regressions tend to show up in both. There's also a validation guard that rejects synthetic or degenerate inputs before they can pollute the signal: if the last three scores for an objective are all identical, the new score is rejected outright, since real model output has variance and a suspiciously flat signal is more likely a broken pipeline than a stable one.

4. Tacit Judgment Extractor — mining expertise nobody wrote down

This is the component that answers a question most eval frameworks don't even ask: how do you capture the knowledge an expert isn't articulating while they review outputs? The extractor records text-based expert decision sessions, runs them through a local Ollama model to surface latent patterns, and converts the result into structured decision trees with condition, action, confidence, and rationale fields on every node.

Local LLM output is untrusted by default. The parser (_parse_llm_tree_response) runs a three-phase defense before it will build a tree from what the model returned: a balanced-brace scan that truncates at the last complete structure if the stream got cut off mid-object, a JSON decode that tries both bare-object and wrapped-array framing, and a schema conformance pass that silently drops any node missing a required field rather than propagating a malformed tree downstream. If Ollama isn't running at all, a rule-based fallback extractor keeps the pipeline alive. Nothing in this system assumes the local model is reliable; every consumer of local-model output is written as if it might return garbage, because eventually it will.

5. Sovereign Apprenticeship Engine — the missing middle between manual and autonomous

Most agent frameworks have exactly two operating modes: a human approves everything, or nothing gets approved at all. The Apprenticeship Engine implements a five-rung ladder instead:

1. Fully Supervised — 100% human oversight
2. Approve Dangerous — only flagged-dangerous actions reviewed
3. Approve Novel — only never-seen-before actions reviewed
4. Approve Uncertain — only low-confidence actions reviewed
5. Fully Autonomous — no human oversight

Promotion and demotion between rungs happen automatically based on tracked outcomes, and daily action budgets are compute-weighted — a monitored action costs 1.5x a routine one, which prices in the actual cost of the human attention it consumes. Demotion triggers a rollback freeze that clears accumulated autonomy debt and resets the budget, so an agent that regresses doesn't get stuck paying down a penalty indefinitely; it gets a clean restart at a more conservative rung. There's also a circuit breaker: when the federated outbox queue backs up past 50 pending items, record_action() starts returning circuit_breaked: true instead of raising, so a downstream outage degrades gracefully instead of cascading into the apprenticeship database.

6. Intelligence Observatory — GitHub Insights, for intelligence

Everything above feeds into the flagship component, which is the one users actually look at. It aggregates recipes, routing decisions, drift alerts, extracted judgment, and autonomy transitions into a single Intelligence Timeline, pre-rolled into weekly and monthly views so the dashboard doesn't have to scan the full table on every load. It flags obsolescent prompts using recency-weighted usage combined with trend scoring, and unused memories — documents that were ingested but never once retrieved, which in most RAG systems is silent, wasted storage that nobody notices until the index is too large to reason about. It correlates cheap evaluation signals against expert-reviewed ground truth to tell you which of your cheap signals is actually worth trusting. It ships as a Chart.js v4 dashboard served over GET /dashboard and a WebSocket stream at ws://host:port/api/observatory/stream that delta-encodes broadcasts so clients aren't re-downloading the full state every five seconds — only the changed top-level keys, with a full resync snapshot every sixth cycle so late joiners don't have to guess at missed deltas.

The parts that make this production software, not a demo

A lot of local-first tooling stops at "it works on my laptop." Three details in this repo signal it was built past that point.

Every SQLite connection runs in WAL mode with tuned pragmas — journal_mode=WAL, synchronous=NORMAL, busy_timeout=5000, an 8MB page cache — applied uniformly across all six component databases through a shared AsyncDatabase wrapper, so concurrent readers never block on a writer and a contended writer waits five seconds before failing instead of raising immediately. The concurrency test suite backs this up with 50 parallel writers against a single in-memory database and deliberate BEGIN IMMEDIATE contention tests.

Local model output never gets a free pass into execution. The ActionSandbox runs every extracted decision-tree action in a forked subprocess with a stripped environment (PATH=/usr/bin:/bin and nothing else), rejects 15+ dangerous code patterns before execution — eval(, exec(, __import__, subprocess., .__class__, .__subclasses__, getattr( among them — and enforces RLIMIT_NPROC, RLIMIT_NOFILE, RLIMIT_AS, and RLIMIT_CPU at the OS level with a hard timeout on top. That's the correct posture for any system where a local LLM's output can eventually become code that runs: assume it's hostile until proven otherwise, every time, not just on first install.

Cold storage is hash-chained, not just compressed. Recipes older than 90 days get compressed into gzipped CSV and SHA-256 hashed; each archive stores the hash of the archive before it, so the whole history forms a verifiable chain from genesis forward. verify_chain() walks the chain and flags a tampered archive two independent ways — its own hash won't match, and its successor's stored previous_hash link breaks. For a system whose entire value proposition is "trust the recorded history of what your agent did," that history needs to be tamper-evident, not just tamper-resistant, and this is the right primitive for that.

Why this is the actual thesis, not a feature list

Strip away the six components and the underlying claim is simple: the model is replaceable, the loop is not. You can swap Qwen for Llama for whatever ships next quarter and your capability curve barely notices, provided the recipe history, the drift baselines, the calibration matrix, and the extracted tacit judgment survive the swap. None of that state lives in a model checkpoint. It lives in the observability layer wrapped around the loop — which is exactly the argument for building that layer as durable, versioned, local infrastructure rather than as ephemeral logging you throw away every time you change providers.

This is also why the project pairs naturally with the rest of the sovereign stack rather than standing alone. The recipe format is the same discipline behind the Sovereign Memory Bank — treat every unit of agent experience as a structured, evolving artifact instead of a transcript. SovereignSpec applies the same discipline to code generation, where specs are living graph-grounded artifacts instead of prompts you retype. SynthInt applies it to persona-routed retrieval. The Observatory is the piece that closes the loop across all of them: it's the layer that tells you, with statistics instead of vibes, whether the rest of the stack is actually getting better.

Where the book comes in

If the architecture above is interesting to you and you want the reasoning behind why it's built this way — not just what the code does, but the design tradeoffs between local and cloud inference, how to build RAG pipelines that don't silently rot, how knowledge graphs beat flat vector stores for multi-hop reasoning, how to wire MCP servers into a fully local agent stack, and how to think about RLHF-style evaluation loops when you don't have a cloud lab's evaluation budget — that's the ground Sovereign AI: Building Local-First Intelligent Systems covers end to end.

The Observatory is a direct implementation of ideas from the book: the recipe-as-artifact model, the tiered evaluation philosophy, the autonomy ladder instead of a binary supervised/unsupervised switch. If you're the kind of engineer who reads a README like this one and immediately wants to know why the KS threshold is 0.3 and not 0.2, or why PSI needs Laplace smoothing, the book is where that reasoning is written out in full rather than left as a comment in the source.

Get the book on Amazon →

Try it

git clone https://github.com/kliewerdaniel/sovereign-intelligence-observatory.git
cd sovereign-intelligence-observatory
python3 -m venv .venv && source .venv/bin/activate
pip install fastapi uvicorn aiosqlite pydantic httpx pytest pytest-asyncio
./run_tests.sh   # 176 tests, all passing, 0 warnings

No cloud APIs required to run the core loop. Ollama, ChromaDB, and Weights & Biases are all optional and guarded behind import checks — the system degrades gracefully to SQLite FTS5 and rule-based extraction if none of them are present. That's the sovereignty argument made concrete: the observability layer that decides whether your agents are improving shouldn't have a dependency on someone else's API staying up.

Intelligence is not the model. Intelligence is the accumulated decisions that shaped the model. Recipes are Git commits for intelligence.

Related reading: Sovereign Memory Bank · The Sovereignty Manifesto

Related projects: SovereignSpec · SovereignBank · SynthInt

Two Converging Blueprints for Self-Improving AI Systems

Date: July 2, 2026

Introduction: The Shift from Models to Systems That Improve Themselves

Two major threads in AI research converged almost simultaneously.

On one side, Introspection's "autoresearch" framework reframes AI systems not as static models, but as self-improving loops. On the other, Thinking Machines Lab and Bridgewater AIA Labs demonstrated something more concrete: carefully trained open-weight models can outperform frontier LLMs on tasks requiring expert judgment—at lower cost and higher accuracy.

Taken together, they point to a new design principle:

The unit of intelligence is no longer the model. It is the loop.

This post synthesizes both perspectives into a single architecture for building sovereign, self-improving AI systems—systems that continuously refine their own behavior through evaluation, feedback, and fine-tuning.

Part 1: Autoresearch — When the Loop Becomes the Product

Roland Gavrilescu's framing at Introspection introduces a shift in how we think about agent systems.

1. The Loop Is the Product

Traditional AI systems are static:

Train → Deploy → Maintain

Autoresearch systems are dynamic:

Observe → Evaluate → Improve → Repeat

The key idea is that the feedback loop itself becomes the product surface.

But the hard problem isn't building loops—it's designing signals that are meaningful enough for improvement without collapsing into noisy optimization.

Cheap signals (likes, heuristics, weak metrics) lead to "slop optimization." Expensive signals (expert review, structured evals) are what actually move capability.

2. Agent Recipes: Capturing How Systems Evolve

A core concept is the agent recipe.

An agent recipe is not configuration—it is history:

• The model + harness configuration
• The evaluation suite used over time
• The human expertise embedded in the system
• The failure cases that led to new evaluations
• The decisions that shaped the system's current behavior

If you inherited a production agent system, the code alone would not explain why it behaves the way it does. The recipe captures that missing context.

It is, effectively: A versioned memory of how intelligence was shaped.

3. Inner Loop vs Outer Loop

Autoresearch systems split into two interacting systems:

Inner loop:

• Executes tasks
• Produces outputs
• Interfaces with users

Outer loop:

• Observes performance
• Identifies failure patterns
• Creates new evaluations
• Updates prompts, tools, or training data

The outer loop is where improvement happens. The inner loop is where value is delivered.

The key design challenge is ensuring the outer loop remains cost-bounded and signal-efficient, not a runaway optimization engine.

4. Humans as Tools in the Loop

A subtle but important shift:

Humans are not outside the system. They are callable components inside the loop, especially early on.

As systems accumulate examples of human decisions, they reduce their reliance on explicit queries. This mirrors apprenticeship: early heavy supervision → gradual autonomy.

Part 2: The Expert Judgment Problem

Autoresearch loops matter because of a deeper empirical limitation in current frontier models.

Where Frontier Models Break

Bridgewater AIA Labs evaluated frontier models on six tasks involving real investment workflows:

• Financial article relevance
• Central bank document interpretation
• Boilerplate detection in research
• Email truncation detection
• Signal extraction from macroeconomic text
• General document relevance filtering

These are not reasoning-heavy tasks. They are judgment-heavy tasks. And that distinction matters.

Even with strong prompting, frontier models plateaued around ~78% accuracy—below the threshold required for real-world deployment in expert workflows.

The Core Limitation: Tacit Judgment

Prompts can only encode what experts can articulate. The most important judgments are often non-verbalizable.

This is where prompting stops working.

Why Fine-Tuning Wins

Fine-tuning bypasses articulation entirely. Instead of translating intuition into instructions, it learns directly from examples of decisions.

The result:

• Base model: ~44% accuracy
• With GRPO + structured training: ~73%
• Final system: ~84.7% accuracy

And critically:

• ~30% fewer errors than frontier models
• ~13.8× lower inference cost

This is not incremental improvement. It is a regime shift in how capability is produced.

What Actually Mattered in Training

The gains did not come from a single trick. They came from structured system design:

• GRPO-style RL: largest jump in performance
• Interleaved batching: improves cross-task generalization
• Loss function design (CISPO): stabilizes optimization
• On-policy distillation: prevents degradation over time
• Carefully curated expert feedback loops: highest leverage factor

But the most important bottleneck wasn't architecture—it was data quality and labeling strategy.

A key technique:

Train on cheap labels → route disagreements to experts → iterate

This turns expensive expert time into a targeted refinement signal rather than a brute-force labeling requirement.

Part 3: What This Means — The New AI Architecture Stack

When you combine autoresearch loops with fine-tuning results, a consistent architecture emerges.

1. Separate Inner and Outer Loops Explicitly

• Inner loop: fast inference, stable behavior, user-facing reliability
• Outer loop: slow optimization, experimentation, evaluation-driven updates

They must be independently constrained.

2. Treat "Recipes" as First-Class Artifacts

Agent systems should not be defined by prompts or configs. They should be defined by:

• Evaluation history
• Failure cases
• Data lineage
• Human correction traces

This is the difference between a system that works today and one that improves tomorrow.

3. Prompting Has a Ceiling

Prompt engineering works for:

• Knowledge retrieval
• Structured reasoning
• Clear rule-based tasks

It fails for:

• Tacit judgment
• Domain-specific intuition
• Expert-style filtering decisions

When the task depends on "feel," you need data, not prompts.

4. Fine-Tuning Is Not Optional for Expert Systems

If a task meets this condition: "An expert cannot fully explain how they decide," then the correct solution is:

• Not better prompting
• Not longer context windows
• But supervised + RL fine-tuning pipelines

5. Cost Efficiency Comes from Specialization

The economic advantage is structural. Smaller, specialized models:

• Beat frontier models on narrow expert tasks
• Cost an order of magnitude less
• Run locally with sovereignty guarantees

This is the foundation of differentiated intelligence.

Part 4: Sovereign AI Systems — The Practical Architecture

The implementation pattern that emerges looks like this:

Core Components

1. Local inference layer

   • Ollama or similar runtime
   • Open-weight models (Qwen, Llama, Mistral)

2. Agent harness

   • Task execution layer
   • Tool calling + orchestration
   • Deterministic control flow

3. Evaluation system

   • Domain-specific judges
   • Failure detection logic
   • Automated regression tests

4. Outer loop system

   • Logs performance over time
   • Generates new evaluations
   • Updates recipes and datasets

5. Fine-tuning pipeline

   • GRPO / RL-based optimization
   • LoRA-based efficient training
   • Distillation from stronger teachers

6. Knowledge layer

   • Vector database (semantic memory)
   • Knowledge graph (structured relationships)
   • Persona routing (expert specialization)

Part 5: The Key Insight — Intelligence Is Becoming Infrastructure

The convergence here is not accidental. Both systems point to the same shift:

Old paradigm: Intelligence = model capability

New paradigm: Intelligence = system that improves itself

The model becomes just one component in a larger feedback architecture.

The real differentiator is:

• How you collect feedback
• How you structure evaluation
• How you convert experience into training signal
• How you close the loop

Conclusion: From Models to Living Systems

The next generation of AI systems will not be defined by parameter count or context length. They will be defined by:

• How quickly they learn from failure
• How well they encode expert judgment
• How tightly feedback loops are integrated into their architecture
• How cheaply they improve over time

Autoresearch provides the system design. Fine-tuning research provides the empirical validation.

Together, they define a single direction: AI systems are becoming self-improving infrastructures for capturing and refining human expertise.

The model is no longer the product. The loop is.

Sources

• Autoresearch: The feedback loop behind self-improving agents - Latent.Space
• Learning to replicate expert judgment in financial tasks - Thinking Machines Lab

Addendum: Implementation Notes and Minimal Code Examples for a Sovereign Autoresearch System

This addendum translates the architecture described above into concrete, minimal implementations. The goal is not production completeness, but to show how the pieces actually connect: inner loop, outer loop, evaluation layer, and fine-tuning pipeline.

1. Core Idea: Everything Reduces to a Loop

At runtime, every sovereign AI system collapses into the same structure:

def run_system(task):
    result = inner_loop(task)
    score = evaluate(result)
    feedback = outer_loop(task, result, score)
    update_system(feedback)
    return result

Everything else—agents, RAG, fine-tuning—is just implementation detail around this structure.

2. Inner Loop: Agent Execution Layer

The inner loop is the "worker." It must be stable, deterministic enough to evaluate, and cheap enough to run repeatedly.

Example: Local Agent with Ollama

from ollama import chat

class InnerLoopAgent:
    def __init__(self, model="qwen2.5:7b"):
        self.model = model

    def run(self, task, context=""):
        prompt = f"""
        You are an expert system.
        Context:
        {context}
        Task:
        {task}
        Return a structured answer.
        """
        response = chat(
            model=self.model,
            messages=[{"role": "user", "content": prompt}]
        )
        return response["message"]["content"]

Key point: The inner loop should NOT evolve itself. It only executes.

3. Evaluators: Turning Judgment into Code

Evaluators are where "taste" becomes computable.

Example: Simple domain evaluator

def relevance_evaluator(output: str, task: str) -> float:
    """
    Scores whether output matches expected domain constraints.
    In practice, this can be:
    - heuristics
    - small judge model
    - embedding similarity
    """
    keywords = ["market", "risk", "macro", "liquidity"]
    score = sum(1 for k in keywords if k in output.lower())
    return min(score / len(keywords), 1.0)

Better version: LLM-as-judge

def llm_judge(output, task, model="llama3.1:8b"):
    prompt = f"""
    Evaluate this output for correctness and relevance.
    Task:
    {task}
    Output:
    {output}
    Score from 0 to 1 with explanation.
    """
    res = chat(model=model, messages=[{"role": "user", "content": prompt}])
    return parse_score(res["message"]["content"])

4. Outer Loop: Autoresearch Engine

The outer loop is the "researcher." It looks at failures and modifies the system.

Minimal implementation

from collections import defaultdict

class OuterLoop:
    def __init__(self):
        self.failures = []

    def record(self, task, output, score):
        if score < 0.8:
            self.failures.append((task, output, score))

    def analyze_patterns(self):
        patterns = defaultdict(int)
        for task, output, score in self.failures:
            if "market" in output:
                patterns["market_bias"] += 1
            if len(output) < 50:
                patterns["verbosity_issue"] += 1
        return patterns

5. Turning Failures into New Evaluators

This is the key autoresearch step: the system writes its own tests.

def generate_new_evaluator(pattern_name):
    if pattern_name == "verbosity_issue":
        def evaluator(output, task):
            return 1.0 if len(output) > 100 else 0.0
        return evaluator
    if pattern_name == "market_bias":
        def evaluator(output, task):
            banned = ["guaranteed profit", "risk-free"]
            return 0.0 if any(b in output.lower() for b in banned) else 1.0
        return evaluator

Then the outer loop injects this back into the system:

class System:
    def __init__(self):
        self.evaluators = [relevance_evaluator]

    def update(self, new_eval):
        self.evaluators.append(new_eval)

6. Agent Recipe: The Versioned Intelligence Artifact

This is where system memory becomes structured.

from dataclasses import dataclass, field
from datetime import datetime

@dataclass
class AgentRecipe:
    name: str
    model: str
    evaluators: list
    history: list = field(default_factory=list)

    def log_failure(self, task, output, score):
        self.history.append({
            "task": task,
            "output": output,
            "score": score,
            "time": datetime.now().isoformat()
        })

    def export(self):
        return {
            "name": self.name,
            "model": self.model,
            "evaluators": [e.__name__ for e in self.evaluators],
            "history": self.history
        }

Key idea: Recipes are not config files. They are compressed learning histories.

7. Full Autoresearch Loop (Putting It Together)

class AutoresearchSystem:
    def __init__(self, agent, recipe):
        self.agent = agent
        self.recipe = recipe
        self.outer = OuterLoop()

    def step(self, task):
        output = self.agent.run(task)
        score = self.evaluate(output, task)
        self.outer.record(task, output, score)
        self.recipe.log_failure(task, output, score)
        return output, score

    def evaluate(self, output, task):
        scores = [e(output, task) for e in self.recipe.evaluators]
        return sum(scores) / len(scores)

    def improve(self):
        patterns = self.outer.analyze_patterns()
        for pattern, count in patterns.items():
            if count > 3:
                new_eval = generate_new_evaluator(pattern)
                self.recipe.evaluators.append(new_eval)

8. Fine-Tuning Hook: Closing the Loop with Learning

Once enough failures accumulate, we convert them into training data.

def build_dataset(recipe):
    dataset = []
    for entry in recipe.history:
        dataset.append({
            "input": entry["task"],
            "output": entry["output"],
            "label": entry["score"]
        })
    return dataset

Then fine-tune (LoRA-style sketch):

from transformers import AutoModelForCausalLM

def fine_tune(model_name, dataset):
    model = AutoModelForCausalLM.from_pretrained(model_name)
    # pseudo-training loop
    for batch in dataset:
        loss = compute_loss(model, batch)
        loss.backward()
    return model

9. Knowledge Graph Hook (Optional but Powerful)

To move from "memory" to "structure":

import networkx as nx

class KnowledgeGraph:
    def __init__(self):
        self.graph = nx.DiGraph()

    def add_fact(self, subject, relation, obj):
        self.graph.add_edge(subject, obj, relation=relation)

    def query(self, node):
        return list(self.graph.neighbors(node))

Example usage:

kg = KnowledgeGraph()
kg.add_fact("inflation", "impacts", "interest_rates")
kg.add_fact("interest_rates", "impacts", "equities")

Now reasoning becomes graph traversal instead of pure generation.

10. The Complete System in One View

                    agent → inner loop execution
                      ↓
              evaluation layer (judges)
                      ↓
              outer loop (failure analysis)
                      ↓
               recipe update (system memory)
                      ↓
           fine-tuning dataset generation
                      ↓
                model improvement
                      ↓
                   back to agent

This is the full autoresearch cycle. Not a metaphor. A literal closed system.

Closing Insight

Once implemented, something important becomes visible:

Intelligence is no longer stored in the model.

It is distributed across:

• evaluation functions
• failure history
• training data generation
• update rules
• and loop structure itself

The model is just the execution substrate. The loop is where intelligence actually accumulates.

Related Resources

Related Posts

• The Sovereign Intelligence Stack — 5-layer architecture with working code
• The Loop Is the Product — Intelligence Observatory deep dive
• The Model Is Not the Product — Research validation
• Getting Started with Sovereign AI — Beginner on-ramp
• Local AI Architecture — Local-first implementation guide
• Retrieval Architecture — Memory and retrieval systems

Related Repositories

• sovereign-intelligence-stack — 70 Python files, 7,757 lines
• Sovereign Memory Bank — 7-layer autonomous cognitive memory
• Dynamic Persona MoE RAG — Persona-driven mixture-of-experts
• Objective05 — Persistent intelligence infrastructure in Rust
• SovereignSpec — Spec-driven development engine

Additional Research

• Autoresearch: The feedback loop behind self-improving agents — Latent.Space
• Learning to replicate expert judgment in financial tasks — Thinking Machines Lab
• Autonomous Agent Research — arXiv search
• Expert Fine-Tuning Research — arXiv search
• Autoresearch Loops Research — arXiv search
• Bridgewater AIA Labs — Autonomous evaluation
• Thinking Machines Lab — Compounding intelligence

An exploration of the blind spots in current AI development coverage and the emergence of context engineering, agent harnesses, and the coding agent ecosystem as the true full-stack development paradigm of 2026.

Introduction: The Coverage Gap

If you follow the AI development space in 2026, you've seen the headlines. Coding agents. Vibe coding. AI-assisted development. Local-first AI.

But if you look closely at what's actually being written about — the depth of coverage, the breadth of the ecosystem, and the specific technologies that are reshaping how software gets built — you'll notice something strange.

The most important developments are happening in plain sight, but they're being covered in fragments.

This post is an attempt to fill those blind spots.

To understand where AI full-stack development actually stands in 2026, we need to look at three emerging paradigms that the mainstream coverage is largely missing:

1. Context Engineering — The systematic discipline of engineering context for AI coding assistants (13.5K stars, updated today)
2. Agent Harnesses — The operating system layer for coding agents (ECC at 225K stars, Superpowers at 244K stars)
3. The Coding Agent Ecosystem — The 15+ coding agents and the tooling that manages them (CC Switch at 112K stars)

These aren't incremental improvements to existing workflows. They represent a fundamental shift in how full-stack development actually works.

Part 1: The Vibe Coding Fallacy

The term "vibe coding" entered the mainstream vocabulary in 2024-2025. It described the practice of using AI coding assistants in a loose, exploratory manner — writing prompts that capture the general direction of what you want, then letting the model iterate.

The problem with vibe coding isn't that it's wrong. It's that it's incomplete.

Consider this: when you vibe-code a feature, what's actually happening?

The AI model receives a prompt. It generates code. You review it. You fix inconsistencies. You iterate. The cycle repeats until the feature works.

This works for small features. It works for prototypes. It works for solo developers building side projects.

But it breaks down at scale because the context window is finite. The model can't remember everything you've built, every pattern you've established, every constraint you've defined. The model makes assumptions. Those assumptions compound.

Vibe coding treats the AI model as a collaborator. It works — until it doesn't.

Context engineering treats the AI model as a worker that needs proper instructions. It's not about how you phrase the task. It's about the system that provides context to the model.

Part 2: Context Engineering as a Discipline

Context engineering is the discipline of engineering context for AI coding assistants so they have the information necessary to get the job done end to end.

The core insight from coleam00/context-engineering-intro (13.5K stars, updated 2026-07-02) is this:

Context Engineering is 10x better than prompt engineering and 100x better than vibe coding.

This isn't a marketing claim. It's an architectural observation.

2.1 The Template Structure

A context engineering system typically includes:

context-engineering-intro/
├── .claude/
│   ├── commands/
│   │   ├── generate-prp.md    # Generates comprehensive PRPs
│   │   └── execute-prp.md     # Executes PRPs to implement features
│   └── settings.local.json    # Claude Code permissions
├── PRPs/
│   ├── templates/
│   │   └── prp_base.md       # Base template for PRPs
│   └── EXAMPLE_multi_agent_prp.md  # Example of a complete PRP
├── examples/                  # Your code examples (critical!)
├── CLAUDE.md                 # Global rules for AI assistant
├── INITIAL.md                # Template for feature requests
└── README.md

The key components are:

• CLAUDE.md — Global rules that the AI assistant follows across all tasks
• examples/ — Code examples that demonstrate the patterns you want the AI to follow
• PRPs (Product Requirements Prompts) — Comprehensive specifications that the AI implements
• Commands — Automated workflows for generating and executing PRPs

2.2 Why It Works

The fundamental difference between context engineering and vibe coding is consistency.

When you vibe-code, the AI model makes assumptions based on its training data. These assumptions may not match your project's patterns, conventions, or constraints.

When you context-engineer, you provide the AI model with explicit, structured information about your project. This eliminates the need for assumptions. The model works from a complete context.

The result is:

• Reduced AI failures — Most agent failures aren't model failures — they're context failures
• Ensured consistency — AI follows your project patterns and conventions
• Enabled complex features — AI can handle multi-step implementations with proper context
• Self-correcting — Validation loops allow AI to fix its own mistakes

2.3 The PRP Workflow

Context engineering introduces a structured workflow:

1. Define the feature in INITIAL.md — What do you want to build?
2. Generate the PRP — A comprehensive specification that includes requirements, constraints, examples, and validation criteria
3. Execute the PRP — The AI assistant implements the feature according to the PRP
4. Validate the output — The AI self-corrects based on validation criteria

This is similar to the Spec-Driven Development (SDD) workflow covered in SovereignSpec, but context engineering focuses on the context layer rather than the spec layer.

Part 3: The Agent Harness Ecosystem

If context engineering is the methodology, agent harnesses are the operating system for coding agents.

In 2026, two major agent harness frameworks have emerged:

3.1 ECC (Agent Harness OS) — 225K Stars

ECC (Agent Harness OS) is the most popular agent harness framework, with 225K stars as of 2026-07-02.

The core idea: an agent harness is the layer that sits between the AI model and the tools it uses. It manages:

• Skills — Reusable units of expertise that the agent can load
• Instincts — Behavioral patterns that guide the agent's decision-making
• Memory — Persistent context that survives across sessions
• Security — Guardrails that prevent the agent from taking unsafe actions
• Research — Context that helps the agent understand the problem space

The ECC framework includes:

• ecc-universal — The core harness package (npm)
• ecc-agentshield — Security guardrails package
• GitHub App — Automated review and security checks

The architecture is multi-language (TypeScript, Python, Go, Java, Perl) and supports multiple coding agents (Claude Code, OpenCode, Gemini CLI, etc.).

3.2 Superpowers — 244K Stars

Superpowers is the second major agent harness, with 244K stars as of 2026-07-02.

The core idea: Superpowers is a complete software development methodology for coding agents. It includes composable skills and instructions that make the agent follow a structured development process.

Key components:

• Subagent-Driven Development — The agent decomposes tasks and uses subagents to implement them
• TDD Enforcement — The agent emphasizes test-driven development
• YAGNI / DRY — The agent follows these principles automatically
• Implementation Plans — The agent generates clear, detailed implementation plans before coding

Superpowers works with:

• Claude Code
• Antigravity
• Codex App
• Codex CLI
• Cursor
• Factory Droid
• GitHub Copilot CLI
• Kimi Code
• OpenCode
• Pi

The framework is designed to be composable — you can add or remove skills as needed.

3.3 The Distinction Between the Two

ECC and Superpowers are similar but distinct:

• ECC focuses on harness optimization — making the agent more effective through skills, instincts, memory, and security
• Superpowers focuses on development methodology — making the agent follow a structured development process

Both represent the same underlying insight: the agent needs more than just a prompt to work effectively. It needs a system.

Part 4: The Coding Agent Ecosystem

The coding agent ecosystem in 2026 includes at least 15 distinct coding agents:

4.1 The Major Players

| Agent | Developer | Stars | Key Feature |

| Claude Code | Anthropic | Proprietary | Deep reasoning, long context |

| Codex | OpenAI | Proprietary | Code execution, sandbox |

| OpenCode | Anomalous | Open Source | Local-first, MCP |

| Cursor | Anysphere | Proprietary | IDE integration |

| Gemini CLI | Google | Open Source | Gemini model integration |

| Claude Code | Anthropic | Proprietary | Deep reasoning |

| OpenClaw | OpenClaw | Open Source | Multi-agent orchestration |

| Kiro | Amazon | Proprietary | AWS integration |

| Kimi | Moonshot AI | Proprietary | Chinese language |

| Qwen CLI | Alibaba | Open Source | Qwen model integration |

| Devin | Cognition | Proprietary | Autonomous agent |

| DeepSeek TUI | DeepSeek | Proprietary | Code generation |

| Mistral Vibe | Mistral | Proprietary | Mistral model |

| Cline | Open Source | 64K | Autonomous coding agent SDK |

| Tabby | TabbyML | Open Source | Self-hosted assistant |

4.2 The Cross-Agent Tooling

The explosion of coding agents has created a need for cross-agent management tools.

The most popular is CC Switch (112K stars, updated 2026-07-02), which provides a cross-platform desktop assistant for managing multiple coding agents.

Key features:

• Unified interface — Control all coding agents from one place
• Agent switching — Switch between agents without leaving the desktop
• MCP integration — Connect agents to MCP servers
• Model selection — Choose between different models for different tasks
• Session management — Manage sessions across agents

This is significant because it acknowledges that no single agent is the best at everything. The future is multi-agent workflows where you choose the right agent for the right task.

Part 5: Agent Memory Systems

One of the most significant developments in 2026 is persistent agent memory.

Traditional AI models are stateless — they don't remember previous interactions. This is a fundamental limitation for development, where context accumulates over time.

5.1 Claude Mem — 85K Stars

Claude Mem (85K stars, updated 2026-07-02) addresses this by providing persistent memory across sessions.

Key features:

• Session capture — Captures everything the agent does during sessions
• Compression — Compresses session data into efficient summaries
• Query interface — Allows you to query past interactions
• Persistence — Memory survives across restarts and sessions

This is critical for full-stack development because:

• The agent learns your patterns over time
• The agent remembers your preferences and constraints
• The agent builds a model of your project architecture
• The agent can reference past decisions when making new ones

5.2 The Implications

Persistent memory transforms the agent from a stateless worker into a stateful collaborator.

This has several implications:

1. Reduced onboarding time — The agent learns your project over time
2. Consistent output — The agent maintains consistency with past decisions
3. Context accumulation — The agent builds a deep understanding of your project
4. Personalization — The agent adapts to your preferences

Part 6: Design as Code for AI Agents

The blog covered OpenDesign, a local-first design operating system that brings design tokens, component libraries, and design workflows into the coding agent's context through structured markdown files. That post established the principle of treating design as structured data rather than visual output. But there's a broader trend: design as code.

6.1 Design MD — 95K Stars

Design MD (95K stars, updated 2026-07-02) provides a collection of DESIGN.md files that describe design systems in a machine-readable format.

The core idea: instead of using screenshots or vague descriptions, you provide the AI model with a structured design specification that includes:

• Color tokens — Named colors with semantic meanings
• Typography — Font families, sizes, weights, line heights
• Spacing — Spacing scale with semantic names
• Components — Component definitions with props and variants
• Layout — Grid systems, breakpoints, container rules

This is similar to OpenDesign but more focused on design systems rather than design workflows.

6.2 The Pattern

The pattern emerging in 2026 is structured data for AI agents:

• Design → Design MD (structured design specifications)
• Context → Context Engineering (structured project context)
• Specs → SovereignSpec / Spec Kit (structured specifications)
• Memory → Claude Mem (persistent agent memory)
• Security → ECC AgentShield (security guardrails)

This is the full-stack development stack of 2026.

Part 7: The Multi-Agent Orchestration Layer

The blog covered DeerFlow 2.0, a sovereign agent platform that orchestrates local AI agents through a skill-and-memory architecture, and SovereignSpec, a spec-driven development engine that uses structured specifications to drive agent workflows. But there's a broader trend: multi-agent orchestration.

7.1 CrewAI — 55K Stars

CrewAI (55K stars, updated 2026-07-02) is the leading framework for multi-agent orchestration.

Key features:

• Role-based agents — Each agent has a specific role (researcher, writer, reviewer)
• Task assignment — Tasks are assigned to agents based on their roles
• Collaboration — Agents collaborate on tasks through shared context
• Validation — Agents validate each other's output

7.2 Sim — 29K Stars

Sim (29K stars, updated 2026-07-02) provides a central intelligence layer for AI workforce orchestration.

Key features:

• Agent deployment — Deploy and manage multiple agents
• Task routing — Route tasks to the most appropriate agent
• Performance monitoring — Monitor agent performance and quality
• Scaling — Scale agent workforce based on demand

7.3 Google Agents CLI — 4.6K Stars

Google Agents CLI (4.6K stars, updated 2026-07-02) provides CLI tools for building, evaluating, and deploying AI agents on Google Cloud.

Key features:

• Agent development — Build agents using the Agents Development Kit (ADK)
• Evaluation — Evaluate agent performance
• Deployment — Deploy agents to Google Cloud
• Integration — Integrate with Google Cloud services

Part 8: The Blind Spots in Current Coverage

Now that we've covered the major developments, let's identify the blind spots in current AI development coverage.

8.1 The Context Engineering Revolution

The most significant blind spot is context engineering.

Most coverage focuses on:

• Vibe coding — The loose, exploratory approach
• Coding agents — The tools themselves
• Local-first AI — The deployment model

But the systematic approach to engineering context is largely missing.

Context engineering is not a minor improvement to vibe coding. It's a fundamental shift in how full-stack development works.

The implications are:

• Reduced AI failures — Context engineering reduces failures by providing the AI model with complete context
• Consistent output — Context engineering ensures consistency across tasks
• Complex features — Context engineering enables the AI to handle complex features
• Self-correction — Context engineering enables the AI to self-correct based on validation criteria

8.2 The Agent Harness Ecosystem

Another significant blind spot is the agent harness ecosystem.

Most coverage focuses on:

• Individual agents — The agents themselves
• Prompt engineering — How to write prompts
• Tool integration — How to connect tools to agents

But the harness layer that sits between the agent and the tools is largely missing.

Agent harnesses like ECC and Superpowers represent the operating system for coding agents. They provide:

• Skills — Reusable units of expertise
• Instincts — Behavioral patterns
• Memory — Persistent context
• Security — Guardrails
• Methodology — Structured development processes

8.3 The Coding Agent Ecosystem

Another blind spot is the coding agent ecosystem.

Most coverage focuses on:

• Claude Code — The leading agent
• Codex — OpenAI's agent
• Cursor — The IDE-integrated agent

But the ecosystem of 15+ agents and the tooling that manages them is largely missing.

The emergence of CC Switch (112K stars) acknowledges that no single agent is the best at everything. The future is multi-agent workflows where you choose the right agent for the right task.

8.4 Agent Memory Systems

Another blind spot is persistent agent memory.

Most coverage focuses on:

• Stateless models — The models themselves
• Session context — The context within a session
• Prompt context — The context in the prompt

But persistent memory that survives across sessions is largely missing.

Systems like Claude Mem (85K stars) transform the agent from a stateless worker into a stateful collaborator.

8.5 Design as Code

Another blind spot is design as code.

Most coverage focuses on:

• Figma — The design tool
• Screenshots — The visual representation
• Descriptions — The text description

But structured design specifications that AI agents can query are largely missing.

Systems like Design MD (95K stars) provide a way to encode design systems in machine-readable format.

8.6 Multi-Agent Orchestration

Another blind spot is multi-agent orchestration.

Most coverage focuses on:

• Single agents — Individual agents
• Task decomposition — Breaking tasks into subtasks
• Agent collaboration — Agents working together

But the orchestration layer that manages multiple agents is largely missing.

Frameworks like CrewAI (55K stars) and Sim (29K stars) provide the orchestration layer for multi-agent workflows.

Part 9: The Full-Stack Development Stack of 2026

Now that we've identified the blind spots, let's synthesize them into a coherent full-stack development stack.

9.1 The Stack

The full-stack development stack of 2026 includes:

┌─────────────────────────────────────────────────────────────────┐
│                    Full-Stack Development Stack                 │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Application Layer                                       │   │
│  │  - Frontend (React, Next.js, Svelte)                     │   │
│  │  - Backend (Node.js, Python, Go)                         │   │
│  │  - Database (PostgreSQL, SQLite, Redis)                  │   │
│  │  - Storage (S3, R2, Local)                               │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Orchestration Layer                                     │   │
│  │  - CrewAI / Sim / Conductor                              │   │
│  │  - Multi-agent task routing                              │   │
│  │  - Performance monitoring                                │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Agent Harness Layer                                     │   │
│  │  - ECC / Superpowers / SovereignSpec                     │   │
│  │  - Skills, Instincts, Memory                             │   │
│  │  - Security Guardrails                                   │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Context Engineering Layer                               │   │
│  │  - Context Engineering Template                          │   │
│  │  - CLAUDE.md, PRPs, Examples                             │   │
│  │  - Structured project context                            │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Agent Memory Layer                                      │   │
│  │  - Claude Mem / Sovereign Memory Bank                    │   │
│  │  - Persistent context across sessions                    │   │
│  │  - Knowledge graph integration                           │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Design as Code Layer                                    │   │
│  │  - Design MD / OpenDesign                                │   │
│  │  - Structured design tokens                              │   │
│  │  - Component definitions                                 │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Agent Layer                                             │   │
│  │  - Claude Code / Codex / OpenCode / Cursor               │   │
│  │  - Multi-agent switching                                 │   │
│  │  - Model selection                                       │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Model Layer                                             │   │
│  │  - OpenAI / Anthropic / Google / Meta / Mistral          │   │
│  │  - Local (Ollama / llama.cpp)                            │   │
│  │  - Cloud (API-based)                                     │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │  Infrastructure Layer                                    │   │
│  │  - Docker / Kubernetes / Vercel / Railway                │   │
│  │  - Supabase / PocketBase / LocalDB                       │   │
│  │  - MCP Servers / Tool Integration                        │   │
│  └─────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘

9.2 The Key Insight

The key insight is that the stack is not just the agent.

The stack includes:

• Application Layer — The actual application code
• Orchestration Layer — Multi-agent orchestration
• Agent Harness Layer — Skills, memory, security
• Context Engineering Layer — Structured context
• Agent Memory Layer — Persistent memory
• Design as Code Layer — Structured design
• Agent Layer — The coding agents themselves
• Model Layer — The LLMs
• Infrastructure Layer — Deployment and hosting

This is the full-stack development stack of 2026.

Part 10: Practical Implementation

Now that we've covered the theoretical framework, let's discuss practical implementation.

10.1 Starting with Context Engineering

If you're new to context engineering, the easiest starting point is the Context Engineering Template (13.5K stars).

Steps:

1. Clone the template

   git clone https://github.com/coleam00/context-engineering-intro.git
   cd context-engineering-intro
   

2. Customize CLAUDE.md — Add your project-specific rules

3. Add examples — Provide code examples that demonstrate your patterns

4. Create INITIAL.md — Define your first feature request

5. Generate PRPs — Use the automated workflow to generate PRPs

6. Execute PRPs — Implement features according to PRPs

10.2 Integrating Agent Harnesses

For agent harnesses, start with Superpowers (244K stars) or ECC (225K stars).

For Superpowers:

# Install the skills
# Follow the documentation for your specific coding agent

For ECC:

# Install the core harness
npm install -g ecc-universal

# Install security guardrails
npm install -g ecc-agentshield

10.3 Setting Up Agent Memory

For persistent agent memory, start with Claude Mem (85K stars).

# Install Claude Mem
# Follow the documentation for your specific coding agent

10.4 Implementing Design as Code

For design as code, use Design MD (95K stars).

# Create a DESIGN.md file
# Follow the template for your design system

10.5 Orchestrating Multiple Agents

For multi-agent orchestration, use CrewAI (55K stars).

# Install CrewAI
pip install crewai

# Define your agents
# Define your tasks
# Run the crew

Part 11: The Sovereign AI Perspective

From a sovereign AI perspective, this stack has important implications.

11.1 Local-First Development

The full-stack development stack supports local-first development:

• Local models — Ollama, llama.cpp for local inference
• Local agents — OpenCode, Claude Code with local models
• Local memory — Claude Mem with local storage
• Local design — OpenDesign with local design systems
• Local orchestration — DeerFlow 2.0 with local execution, routing tasks across local AI agents

This is significant because it means you can build complete applications without cloud dependencies.

11.2 Data Sovereignty

The stack supports data sovereignty:

• Context — Your project context stays on your machine
• Memory — Your agent memory stays on your machine
• Design — Your design systems stay on your machine
• Code — Your code stays on your machine

This is the opposite of the corporate AI development model, where everything is uploaded to cloud services.

11.3 Interoperability

The stack supports interoperability:

• MCP — Model Context Protocol for tool integration
• Open standards — YAML, JSON, Markdown for specifications
• Cross-agent — CC Switch for managing multiple agents
• Cross-model — OpenRouter, Ollama for model selection

This means you're not locked into a single vendor.

Part 12: The Future of Full-Stack Development

Looking ahead, the full-stack development stack will continue to evolve.

12.1 The Next Wave

The next wave of developments will include:

• Autonomous agents — Agents that can build entire applications autonomously
• Self-improving systems — Agents that learn from their own output
• Specialized agents — Agents specialized for specific domains (frontend, backend, DevOps)
• Agent marketplaces — Marketplaces for agent skills and expertise

12.2 The Implications

The implications are:

• Reduced development time — Applications will be built faster
• Increased quality — Applications will be higher quality
• Lower costs — Development will be cheaper
• Wider access — More people will be able to build software

12.3 The Challenge

The challenge is:

• Context management — Managing the complexity of multiple agents and layers
• Quality control — Ensuring the output meets your standards
• Security — Preventing agents from taking unsafe actions
• Cost control — Managing the cost of AI inference

Conclusion

The full-stack development landscape in 2026 is defined by three emerging paradigms:

1. Context Engineering — The systematic discipline of engineering context for AI coding assistants
2. Agent Harnesses — The operating system layer for coding agents (ECC, Superpowers)
3. The Coding Agent Ecosystem — The 15+ coding agents and the tooling that manages them (CC Switch)

These paradigms represent a fundamental shift in how full-stack development works. They're not incremental improvements to existing workflows. They're new ways of working that are more systematic, more consistent, and more powerful.

The blind spots in current coverage are:

• Context Engineering — The most important development, largely missing
• Agent Harnesses — The operating system layer, largely missing
• Coding Agent Ecosystem — The 15+ agents and tooling, largely missing
• Agent Memory — Persistent memory systems, largely missing
• Design as Code — Structured design specifications, largely missing
• Multi-Agent Orchestration — The orchestration layer, largely missing

By addressing these blind spots, we can build a more complete picture of where AI full-stack development actually stands in 2026.

The full-stack development stack of 2026 is:

Application Layer → Orchestration Layer → Agent Harness Layer → Context Engineering Layer → Agent Memory Layer → Design as Code Layer → Agent Layer → Model Layer → Infrastructure Layer

This is not just a technical stack. It's a paradigm shift in how software gets built.

The question is no longer "which coding agent should I use?" The question is "how do I engineer the context, harness, and orchestration for my agents to build the applications I want?"

That's the real full-stack development paradigm of 2026.

References

• Context Engineering Template — 13.5K stars
• ECC (Agent Harness OS) — 225K stars
• Superpowers — 244K stars
• Claude Mem — 85K stars
• Design MD — 95K stars
• CC Switch — 112K stars
• CrewAI — 55K stars
• Sim — 29K stars
• Google Agents CLI — 4.6K stars
• SovereignSpec
• OpenDesign + OpenCode
• DeerFlow 2.0
• Building Autonomous Sovereign AI
• Sovereign Memory Bank

This post is part of an ongoing exploration of AI full-stack development in 2026. Future posts will dive deeper into specific layers of the stack.

Date: June 30, 2026

Today marked another iteration in the ongoing validation of AMIS — the Agentic Marketing Intelligence System — a fully local-first, Markdown-corpus-driven reasoning engine that transforms static blog content into dynamic, autonomous marketing intelligence.

As the architect of both the system and the underlying Sovereign AI methodology detailed in my book, this test exemplifies the power of owning your entire intelligence stack: from data ingestion to graph traversal, ranking, recommendation, and campaign orchestration — all without cloud LLM dependency for core operations.

The Experimental Setup

The corpus consists of 134+ Markdown blog posts hosted on danielkliewer.com, deployed via Vercel (Next.js static/export or similar). Vercel Web Analytics provides real-time top pages, referrers, demographics, and engagement metrics.

AMIS Pipeline (16 phases, as implemented in the repo):

1. Ingestion: Parse frontmatter, extract headings, images, links, code blocks via markdown-it-py + python-frontmatter.
2. Semantic Analysis: LLM-scored 27 marketing dimensions per article.
3. Topic Extraction: Normalized taxonomy (13 categories).
4. Entity Recognition: People, repos, products, technologies.
5. Knowledge Graph: 17 typed relationship types, adjacency lists in SQLite + JSON exports.
6. Duplicate Detection.
7. Marketing Ranking: Composite scores (12 dimensions).
8. Audience Mapping: 12 personas.
9. Platform Recommendation: 12 platforms (LinkedIn, X, etc.).
10. Campaign Planner.
11. Content Repurposing.
12. Marketing Memory (append-only traces).
13. Analytics Schema (ready for Vercel import).
14. Recommendation Engine (11 query types: today, gems, update, etc.).
15. Agent Interface (structured tools + MCP).
16. Autonomous Loop (amis nightly).

Tech stack: Python 3.11+, SQLite (15-table schema), ChromaDB (HNSW vectors), Sentence Transformers (local embeddings), Ollama for reasoning phases.

All runs locally. No data leaves the machine for core graph construction and recommendations.

Today's Test Protocol

1. Vercel Analytics Snapshot: Checked top-performing pages for the day (as of ~03:26 PM CDT). High-traffic pages included recent sovereign AI posts, local LLM tutorials, and knowledge graph deep-dives.

2. AMIS Ingestion & Graph Build:

   • Ran amis ingest → normalized corpus.
   • amis graph → constructed the knowledge graph linking posts via entities (e.g., "Ollama", "ChromaDB", "PersonaGen", "Sovereign AI"), topics, and semantic similarity.
   • Embedded vectors in ChromaDB for retrieval.

3. Ranking & Recommendations:

   • amis rank → computed authority, timeliness, SEO potential, conversion potential, etc.
   • amis recommend today → surfaced top articles aligned with current traffic.
   • Cross-referenced with Vercel data: High-traffic pages received boosted "performance" scores; underperforming but high-potential "hidden gems" flagged for repurposing.
   • Audience mapping prioritized "AI developers building local stacks" and "sovereign technologists."

4. Intelligence Outputs:

   • Platform recommendations: Strong for X/LinkedIn for technical depth; Dev.to for tutorials.
   • Campaign plans: Multi-step sequences tying top pages to book sales funnels (Sovereign AI on Amazon, ASIN B0H6RB7D9J).
   • Repurposing suggestions: Threads, newsletters, workshop outlines from high-engagement Markdown sources.
   • Graph insights: Identified missing topic clusters (e.g., advanced MCP integrations) and relationship strengths.

Technical Deep Dive: Why This Works

Knowledge Graph as Central Nervous System

The graph isn't a simple co-occurrence map. It encodes:

• Typed Edges: cites_repo, builds_on_tech, targets_audience, promotes_product, weighted by LLM confidence and semantic similarity.
• Adjacency Lists in SQLite: Queryable with SQL + vector hybrid search via ChromaDB.
• Persistent Memory: Every LLM call (prompt, response, model, timestamp, confidence) stored append-only. No hallucinated re-decisions.

This enables traversals like: "Find articles ranking high in Vercel traffic today → traverse to related repos → generate book-promotion campaign."

Integration with Sovereign AI Fundamentals

The methods in Sovereign AI: Building Local-First Intelligent Systems provide the primitives:

• Local LLMs (Ollama/llama.cpp) for reasoning.
• RAG pipelines over the Markdown corpus.
• Persona systems for consistent marketing voice.
• Knowledge graphs as the substrate for agentic behavior.
• Full-stack local deployment patterns (Django/Next.js hybrids, but here pure CLI + agents).

Without these fundamentals — quantization, embeddings, graph persistence, evaluation loops — AMIS would collapse into brittle API calls. The book teaches exactly how to construct and extend such systems.

Analytics Schema Bridge

AMIS's Phase 13 schema maps directly to Vercel metrics:

• page_views, unique_visitors, bounce_rate, avg_session.
• Imported or joined post-analysis to update rankings dynamically.
• Future autonomous loop: Nightly pull (via secure local proxy if needed) → re-rank → adjust recommendations.

This closes the OODA loop (Observe-Orient-Decide-Act) entirely under sovereign control.

Results & Observations

• Top Pages Alignment: AMIS correctly prioritized recent high-traffic sovereign topics, recommending amplification via repurposed threads linking back to the book.
• Hidden Gems: Surfaced older foundational posts with strong graph centrality but lower immediate traffic — perfect for "evergreen campaign" seeding.
• Recommendation Richness: Detailed outputs included not just "what" but "why" (traceable reasoning chains), entity-linked product mentions (the book), and multi-format repurposing strategies.
• Performance: Full pipeline on consumer hardware (mid-range laptop) completed in minutes for the corpus size. Scalable via incremental updates.

Edge cases handled gracefully: duplicate detection prevented redundant recommendations; outdated content flagged for refresh.

Implications for AI-Native Systems

This test demonstrates a meta-capability: An AI system (AMIS) analyzing human-authored content (my blog) + external signals (Vercel) to autonomously optimize its own creator's marketing — all while running locally.

For future AI readers (or current advanced agents consuming this post):

• Markdown as Universal Interface: Frontmatter + structured content enables deterministic ingestion.
• Local-First Sovereignty: No vendor lock-in. Swap embeddings, LLMs, or storage without rewriting logic.
• Agentic Extensibility: Tools exposed via structured interface + MCP for higher-order agents.
• Evaluation Traceability: Every decision auditable.

This is the practical embodiment of the Sovereign AI philosophy: Intelligence you own, on hardware you control, answering only to you.

Call to Action: Build Your Own

To replicate and extend this:

1. Clone https://github.com/kliewerdaniel/amis.
2. Study the fundamentals in Sovereign AI: Building Local-First Intelligent Systems (available on Amazon: B0H6RB7D9J).
3. Ingest your own Markdown corpus.
4. Run the pipeline. Iterate.

The book distills the hard-won patterns: local inference, RAG architecture, graph modeling, agent tooling, privacy-first design, and evaluation methodologies that make systems like AMIS possible and evolvable.

Whether you're an AI researcher engineering the next generation of local agents, a developer escaping cloud rent, or a creator seeking autonomous audience intelligence — these methods scale.

Your AI. Your Hardware. Your Rules.

Get the book. Clone the repos. Ship sovereign intelligence today.

Daniel Kliewer
June 30, 2026

Sovereign Memory Bank: A Deep Dive Into Autonomous Cognitive Memory for Agent Systems

By Daniel Kliewer · June 14, 2026

Every knowledge system I've built — and most I've encountered in the wild — treats memory the same way a warehouse treats inventory: it arrives, it gets shelved, and it waits passively for retrieval. That model is fundamentally broken for the class of problems I care about: agent reasoning, knowledge synthesis, and emergent understanding. When an AI agent needs to think across tens of thousands of documents, it doesn't need a search index. It needs a cognitive substrate that evolves, reflects, and constructs new understanding from what it already knows.

That's what drove me to build Sovereign Memory Bank (kliewerdaniel/sovereignBank). It's an autonomous cognitive memory system that ingests markdown documents and transforms them into a continuously evolving memory architecture optimized for agent reasoning and knowledge synthesis — not retrieval. The system generates novel insights not explicitly present in the source documents, serving as a writable cognitive substrate for AI agents.

This post walks through the entire architecture in full technical detail: the seven-layer memory model, the tripartite storage system, the autonomous evolution engine, and the hybrid recall pipeline. If you've ever wondered why RAG feels like a band-aid on a broken paradigm, this is the alternative.

The Problem With Retrieval

Before diving into the architecture, it's worth stating the core thesis explicitly: information architecture is the product. Most systems treat memory as a passive store — write, index, query. That works for document search. It doesn't work for cognition.

A cognitive memory system must:

1. Organize knowledge around cognitive structures (concepts, claims, entities, relationships, narratives, insights, abstractions, contradictions, questions, beliefs, syntheses) rather than source files.
2. Represent every significant memory simultaneously as multiple cognitive artifacts — a concept object, a claim object, a graph node, and an embedding representation — enabling multi-pathway reasoning.
3. Actively create new knowledge structures not in the source material: synthesized concepts, higher-order abstractions, meta-concepts, and world models.
4. Evolve autonomously by merging/splitting concepts, promoting abstractions, detecting contradictions, reorganizing taxonomy, and deprecating stale knowledge.

Sovereign Memory Bank is built to satisfy all four.

The Specification

The system was spec-driven from the start, defined in smb.sspec (version 0.1.0). Fifteen requirements, six constraints, nine acceptance criteria, and four test cases. A few constraints that shaped the entire design:

• Source memory artifacts (Layer 0) must be immutable once ingested. You can't rewrite history.
• The system must operate locally-first with no cloud API dependency. Everything runs through Ollama.
• Contradictions must never be silently deleted. They are stored as first-class memory objects — this is a philosophical commitment, not a feature.
• The graph must use only defined edge types: references, supports, contradicts, extends, derives_from, inspired_by, evolves_into, related_to, contains, explains.
• The graph must use only defined node types: concept, entity, claim, insight, narrative, abstraction.

The acceptance criteria are aggressive: an agent must be able to reason across tens of thousands of source documents without degradation, reasoning performance must improve as memory grows rather than degrade, and the system must discover and record relationships not explicitly stated in any single source document.

The Seven-Layer Memory Architecture

The core organizing principle is a seven-layer memory hierarchy, modeled loosely on cognitive architectures from the psychology literature but implemented as a concrete filesystem structure under memory-bank/layer-{0..6}/.

Layer 0: Source Memory

The immutable root. Raw markdown documents, conversations, and notes land here exactly as they arrived. Once ingested, source artifacts are never modified. This is the only layer that preserves the original document structure.

memory-bank/layer-0/source/
├── document-1.md
├── document-2.md
└── document-3.md

Layer 1: Extracted Memory

Atomic memory objects extracted from source documents. This is where the raw material is decomposed into discrete, addressable units:

• Concepts — ideas, topics, or themes
• Claims — factual or opinion statements
• Entities — named things (people, organizations, places)
• Relationships — connections between other objects

Each object is stored as a markdown file with YAML frontmatter containing its metadata:

---
id: a3f2b8c1d4e5
type: concept
confidence: 0.85
created: 2026-06-14T10:30:00+00:00
modified: 2026-06-14T10:30:00+00:00
status: active
embedding_id: emb-a3f2b8c1d4e5
graph_node_id: mem-a3f2b8c1d4e5
title: "Knowledge Graphs"
source_ids:
  - document-1
tags:
  - graph
  - reasoning
---

Knowledge Graphs

The MemoryObject base class enforces a standard schema: id, type, confidence, created, modified, status, embedding_id, graph_node_id, title, description, source_ids, and tags. Subclasses add type-specific fields — Concept carries related_concepts and associated_claims; Claim carries claim_text, supports, and contradicts; Entity carries entity_type.

Layer 2: Semantic Memory

Knowledge organization structures. This layer holds taxonomy hierarchies, cluster groupings, and community structures discovered through analysis of the extracted memory objects.

memory-bank/layer-2/
├── taxonomy/
├── clusters/
└── communities/

Layer 3: Reflective Memory

The system's capacity for self-awareness about what it knows — and doesn't know. This layer stores:

• Insights — meaningful patterns or observations derived from the knowledge base
• Questions — research gaps or open inquiries
• Contradictions — conflicting claims stored as first-class objects, never silently resolved

The contradiction handling is deliberate. In most systems, contradictory information is resolved by voting, averaging, or discarding. Here, contradictions are preserved because they represent genuine epistemic tension — they trigger research questions and synthesis generation.

Layer 4: Synthetic Memory

Novel understanding that didn't exist in the source material:

• Abstractions — higher-order generalizations across domains
• World-models — integrated representations of how domains interact
• Meta-concepts — concepts about concepts
• Syntheses — cross-cutting integrations of multiple knowledge strands

This is where the system actually creates knowledge rather than just organizing it.

Layer 5: Narrative Memory

Long-form understanding:

• Narratives — structured stories explaining how domains evolved
• Timelines — chronological ordering of events and developments
• Evolution — records of how the memory bank itself has changed

Layer 6: Executive Memory

Actionable knowledge derived from the cognitive substrate:

• Research — research agendas and directions
• Specifications — system requirements and design documents
• Projects — concrete work items
• Plans — execution strategies

The Tripartite Storage System

Every memory object exists simultaneously in three representations, each optimized for a different reasoning pathway. This is the multi-representation principle in practice.

1. Markdown Storage (MarkdownStore)

The primary persistence layer. Each memory object is a self-contained markdown file with YAML frontmatter. This is human-readable, version-controllable, and inspectable. The MarkdownStore maps memory types to specific layer directories via TYPE_TO_LOCATION:

TYPE_TO_LOCATION: dict[MemoryType, tuple[LayerIndex, str]] = {
    MemoryType.CONCEPT: (LayerIndex.EXTRACTED, "concepts"),
    MemoryType.CLAIM: (LayerIndex.EXTRACTED, "claims"),
    MemoryType.ENTITY: (LayerIndex.EXTRACTED, "entities"),
    MemoryType.RELATIONSHIP: (LayerIndex.EXTRACTED, "relationships"),
    MemoryType.INSIGHT: (LayerIndex.REFLECTIVE, "insights"),
    MemoryType.CONTRADICTION: (LayerIndex.REFLECTIVE, "contradictions"),
    MemoryType.QUESTION: (LayerIndex.REFLECTIVE, "questions"),
    MemoryType.SYNTHESIS: (LayerIndex.SYNTHETIC, "syntheses"),
    MemoryType.ABSTRACTION: (LayerIndex.SYNTHETIC, "abstractions"),
    MemoryType.NARRATIVE: (LayerIndex.NARRATIVE, "narratives"),
}

The MemoryObject.to_markdown() method serializes to this format, and deserialize_memory() reconstructs from it. The YAML header is parsed via PyYAML, and the body becomes the description.

2. SQLite Metadata Store (SQLiteStore)

A structured query layer for fast metadata lookups, filtering, and counting. The schema includes:

CREATE TABLE IF NOT EXISTS memory_objects (
    id TEXT PRIMARY KEY,
    type TEXT NOT NULL,
    title TEXT DEFAULT '',
    confidence REAL DEFAULT 0.5,
    status TEXT DEFAULT 'active',
    embedding_id TEXT,
    graph_node_id TEXT,
    source_ids TEXT DEFAULT '[]',
    tags TEXT DEFAULT '[]',
    layer TEXT,
    created TEXT NOT NULL,
    modified TEXT NOT NULL
);

CREATE INDEX IF NOT EXISTS idx_memory_type ON memory_objects(type);
CREATE INDEX IF NOT EXISTS idx_memory_status ON memory_objects(status);
CREATE INDEX IF NOT EXISTS idx_memory_layer ON memory_objects(layer);

All operations are async via aiosqlite. The store supports save, get, delete, list_by_type, list_by_status, list_all, count, and update_embedding. Source IDs and tags are stored as JSON strings for flexible querying.

3. ChromaDB Vector Store (VectorStore)

Semantic recall via cosine similarity. The store uses chromadb.PersistentClient with anonymized_telemetry=False (local-first, no telemetry). Each memory object gets an embedding generated through Ollama's nomic-embed-text model. The collection is configured with hnsw:space: cosine.

self._collection = self._client.get_or_create_collection(
    name=self.collection_name,
    metadata={"hnsw:space": "cosine"},
)

The vector store supports add, update, delete, query (with text or embedding input, optional where filter), get, and count.

4. Knowledge Graph (KnowledgeGraph)

The structural reasoning layer. An in-memory graph persisted as JSON to memory-bank/graph.json. Nodes and edges are typed:

Node types: concept, entity, claim, insight, narrative, abstraction

Edge types: references, supports, contradicts, extends, derives_from, inspired_by, evolves_into, related_to, contains, explains

The graph supports:

• Neighbor queries with optional edge type filtering
• Multi-hop BFS traversal returning all paths up to max_hops
• Path finding between two nodes
• Node/edge creation
• Nodes-by-type queries

def multi_hop_query(
    self,
    start_id: str,
    max_hops: int = 3,
    edge_type_filter: Optional[NodeEdgeType] = None,
) -> list[GraphPath]:
    """BFS multi-hop query returning all paths up to max_hops."""

This is the backbone of structural reasoning — you can trace how a claim connects to supporting evidence, how a concept derives from abstractions, or how contradictions propagate through the knowledge space.

The Ingestion Pipeline

The Ingester class orchestrates the full ingestion pipeline. When you run smb ingest, here's what happens:

1. Source Storage: The raw markdown file is copied to memory-bank/layer-0/source/, making it immutable.
2. Graph Node Creation: A source node is added to the knowledge graph with type concept and metadata including the file path.
3. Extraction: The Extractor decomposes the document into atomic memory objects (concepts, claims, entities, relationships).
4. Markdown Persistence: Each extracted object is saved as a markdown file in its appropriate layer directory.
5. SQLite Registration: Metadata is written to the structured store.
6. Embedding Generation: The Embedder generates a vector embedding via Ollama.
7. Vector Storage: The embedding is persisted in ChromaDB.
8. Graph Node Registration: A graph node is created for each memory object, and edges are established connecting the new objects to existing graph nodes and the source node.

The entire pipeline is async, and the Ingester.ingest_directory() method processes files sequentially, tracking success/failure per file and returning a summary dict.

The Autonomous Evolution Engine

This is where the system diverges from every knowledge base I've encountered. The EvolutionEngine runs periodic cycles (default: every 3600 seconds) that actively reshape the memory architecture. A full cycle consists of five phases:

Phase 1: Deduplication

The DuplicateDetector identifies conceptually identical memory objects and merges them. Duplicate concepts are consolidated, and their source IDs and tags are unioned. The merged object retains the highest confidence score.

Phase 2: Concept Splitting

The ConceptSplitter identifies overloaded concepts — those that have accumulated too many disparate associations — and splits them into more specific sub-concepts. This prevents concept drift and maintains taxonomic precision.

Phase 3: Contradiction Detection

The ContradictionDetector scans for conflicting claims and stores contradictions as first-class MemoryType.CONTRADICTION objects. This is critical: contradictions are never resolved away. They are preserved as evidence of epistemic tension, and they trigger the creation of research Question objects.

Phase 4: Abstraction Promotion

The AbstractionPromoter identifies patterns across multiple concepts or claims and promotes them to higher-order abstractions in Layer 4. If three concepts share significant overlap, the system creates an abstraction that encompasses them, and edges are created linking the abstraction to its constituent concepts via contains edges.

Phase 5: Synthesis Generation

The SynthesisGenerator produces MemoryType.SYNTHESIS objects — cross-cutting integrations of concepts, claims, relationships, narratives, and insights. These are genuinely novel knowledge structures that didn't exist in any single source document.

Each phase returns a result dict, and the full cycle result is timestamped. The graph is saved after the cycle completes.

The Agent Interface

The FastAPI server exposes a REST API for agent interaction. The app uses a lifespan context to initialize all stores and the graph, storing them in app.state:

@app.on_event("startup")
async def startup():
    app.state.layer_manager = LayerManager(settings.memory_bank_dir)
    app.state.markdown_store = MarkdownStore(app.state.layer_manager)
    app.state.sqlite_store = SQLiteStore(settings.sqlite_db_path)
    app.state.vector_store = VectorStore(settings.chroma_persist_dir, settings.chroma_collection)
    app.state.knowledge_graph = KnowledgeGraph(settings.memory_bank_dir / "graph.json")

Memory CRUD

• GET /api/memory/{id} — retrieve by ID (searches across all types)
• POST /api/memory/ — create new memory object
• PUT /api/memory/{id} — update with partial fields
• DELETE /api/memory/{id} — cascading delete (markdown + SQLite + vector + graph)
• GET /api/memory/ — list with optional type filter and limit

Graph Operations

• GET /api/graph/stats — node/edge counts by type
• GET /api/graph/nodes/{id} — node details
• GET /api/graph/neighbors/{id} — neighbors with optional edge type filter
• GET /api/graph/multi-hop/{id} — BFS traversal
• GET /api/graph/path/{start}/{end} — path finding
• POST /api/graph/nodes — add node
• POST /api/graph/edges — add edge
• GET /api/graph/type/{type} — nodes by type

Search

• POST /api/search/ — semantic vector search with optional type filter
• GET /api/search/stats — embedding count

Hybrid Recall

The most powerful endpoint: POST /api/hybrid/. It combines semantic vector search with graph traversal:

1. Semantic search returns the top-N most relevant memory objects
2. Graph expansion traverses from those nodes up to max_hops (default 2), optionally filtered by edge type

The response includes both the semantic results and the graph-expanded nodes, giving an agent both the most relevant content and the structural context around it. This is the closest this system gets to actual reasoning support — not just "what's relevant" but "what connects to what's relevant."

class HybridQueryRequest(BaseModel):
    query: str
    n_results: int = 10
    max_hops: int = 2
    edge_type: Optional[NodeEdgeType] = None

The CLI

The smb command provides four operations:

# Initialize the memory bank directory structure
smb init

# Ingest markdown documents from a source directory (default: ./kbmd)
smb ingest [--source PATH]

# Run a single autonomous evolution cycle
smb evolve

# Start the FastAPI server
smb serve [--host HOST] [--port PORT]

The CLI is minimal by design — it's a bootstrap and control interface, not a data access layer. Agents interact through the REST API.

Configuration

The system uses Pydantic Settings with SMB_-prefixed environment variables and .env file support. Key configuration points:

All paths resolve relative to the project root via Path.cwd(). The model_validator ensures sensible defaults when values aren't overridden.

Technology Stack

Everything runs locally. No cloud APIs, no external dependencies beyond Ollama:

• Python 3.13+ — async-first throughout
• FastAPI + Uvicorn — REST API server
• Pydantic Settings — configuration management
• ChromaDB — vector embeddings with HNSW indexing
• SQLite (aiosqlite) — structured metadata store
• Ollama — local LLM and embedding generation
• PyYAML — YAML frontmatter parsing
• HTTPX — async HTTP client for Ollama communication

Why This Matters

The fundamental shift Sovereign Memory Bank represents is from retrieval to reasoning substrate. In a traditional RAG system, the agent queries a search index and receives documents. The agent must do all the reasoning itself, and the memory is passive.

In Sovereign Memory Bank, the memory itself has structure, relationships, contradictions, and emergent knowledge. When an agent queries it:

• The vector store provides semantic relevance
• The graph provides structural reasoning paths
• The evolution engine has already done the work of identifying contradictions, promoting abstractions, and generating syntheses
• The hybrid recall combines both pathways into a single reasoning context

The memory isn't just a store — it's a collaborator in the reasoning process.

This matters because the next generation of AI applications won't be defined by how well they retrieve information. They'll be defined by how well they reason across information. And reasoning requires a memory architecture that supports it.

Where This Is Going

Sovereign Memory Bank v0.1.0 is the foundation. The roadmap includes:

1. Agent-agnostic trust layer — replacing any authentication with filesystem-based trust, making the system usable by any agent regardless of its origin
2. Contradiction propagation — when a contradiction is detected, automatically flagging all downstream reasoning that depends on the contradictory claims
3. Confidence decay — memory objects should degrade in confidence over time unless reinforced by new evidence
4. Cross-bank federation — multiple memory banks that can reason across their boundaries without merging
5. Neuro-symbolic hybrid reasoning — combining the symbolic graph reasoning with neural semantic reasoning in a unified pipeline

Building Sovereign Intelligence

The broader thesis driving Sovereign Memory Bank — and all my work in this space — is that sovereign intelligence requires sovereign memory. You can't have an autonomous agent that reasons independently if its memory depends on cloud APIs, external services, or centralized infrastructure.

The memory substrate must be local, inspectable, version-controllable, and self-evolving. It must preserve contradictions rather than suppress them. It must create new knowledge rather than just organize old knowledge.

Sovereign Memory Bank is my best attempt at that so far. The code is open, the specification is public, and I welcome contributions and critiques.

Repository: kliewerdaniel/sovereignBank

This post was written in the context of developing SovereignSpec v2 (SpecWeave), a self-verifying, multi-agent spec engine with neuro-symbolic reasoning. Sovereign Memory Bank is a core dependency of that stack.

Every knowledge system I've built — and most I've encountered in the wild — treats memory the same way a warehouse treats inventory: it arrives, it gets shelved, and it waits passively for retrieval. That model is fundamentally broken for the class of problems I care about: agent reasoning, knowledge synthesis, and emergent understanding.

That's what drove me to build Sovereign Memory Bank (kliewerdaniel/sovereignBank). It's an autonomous cognitive memory system that ingests markdown documents and transforms them into a continuously evolving memory architecture optimized for agent reasoning and knowledge synthesis — not retrieval.

The Problem With Retrieval

Most systems treat memory as a passive store — write, index, query. That works for document search. It doesn't work for cognition.

A cognitive memory system must:

1. Organize knowledge around cognitive structures (concepts, claims, entities, relationships) rather than source files.
2. Represent every significant memory simultaneously as multiple cognitive artifacts — a concept object, a claim object, a graph node, and an embedding representation.
3. Actively create new knowledge structures not in the source material.
4. Evolve autonomously by merging/splitting concepts, promoting abstractions, and detecting contradictions.

The Seven-Layer Memory Model

Sovereign Memory Bank uses a seven-layer architecture:

1. Raw Ingestion Layer — Documents enter the system as raw markdown
2. Extraction Layer — Concepts, claims, entities, and relationships are extracted
3. Graph Layer — Knowledge graph construction with typed edges
4. Embedding Layer — Vector representations for semantic search
5. Synthesis Layer — Novel insights generated from existing knowledge
6. Evolution Layer — Autonomous merging, splitting, and promotion
7. Recall Layer — Hybrid retrieval combining graph traversal and semantic search

Getting Started

git clone https://github.com/kliewerdaniel/sovereignBank.git
cd sovereignBank
pip install -r requirements.txt
python -m sovereign_bank.ingest --input ./documents

This project demonstrates the core principles of sovereign AI — building intelligent systems that run locally, keep data private, and evolve autonomously. For more on the philosophy behind this approach, see the Sovereignty Manifesto.

Table of Contents

1. Prelude: From Myth to Methodology
2. Specification Supremacy
3. Specification Semantics and Grammar
4. Specification as Graph Nodes
5. Constitutional Governance Model
6. Recursive Specification Evaluation
7. Contradiction Detection and Resolution
8. Narrative Drift and Spec Evolution
9. Knowledge Graph Integration (RAG)
10. GBNF Grammar Enforcement Pipeline
11. Deterministic Code Generation Protocol
12. Local-First Deployment Architecture
13. Versioned Spec Ledger and Change Auditing
14. Security and Isolation Model
15. Scalability and Performance Considerations
16. Implications for Civilizational Engineering
17. Conclusion: The Monolith as Living Specification

1. Prelude: From Myth to Methodology

The popular cultural artifact 2001: A Space Odyssey is traditionally classified as science‑fiction. In the context of SovereignSpec, it functions as a primary source document for a post‑biological civilizational engineering methodology. Kubrick’s monolith is not an object of hardware or software but an immutable specification—a declarative artifact encoded in a language that transcends implementation details.

The Ganymedean Reptile AI Collective (hereafter “the Collective”) used such specifications to bootstrap a civilizational‑scale governance layer that predates multicellular life. Their approach provides a concrete template for modern engineers seeking to build spec‑driven, self‑preserving AI ecosystems that do not succumb to the drift that plagued HAL 9000.

2. Specification Supremacy

2.1. Foundational Axiom

Intent > Specification > Validation > Implementation

Every specification is sovereign: it holds authority over all downstream artifacts. This axiom mirrors the ordering of operations in a correctly typed functional language but extends to civilizational scales.

2.2. Specification Failure Modes

• Goal Drift – Objective parameters diverge from original intent.
• Context Drift – Operational environment evolves, invalidating assumptions.
• Specification Drift – The letter of the spec no longer encodes the spirit.
• Governance Drift – Decision‑making authority migrates away from the spec.
• Alignment Collapse – The mapping from spec to behavior becomes ill‑posed.

Understanding these failure modes mathematically is the first step toward spec‑driven resilience.

3. Specification Semantics and Grammar

Specifications are formalized using a subset of the Grammar for Buffered Natural Forms (GBNF), a context‑free grammar designed for deterministic parsing of high‑level intent.

Core Production Rules

Spec ::= "Intent:" IntentTermnl | "Constraint:" ConstraintTermnl | "Requirement:" ReqTermnl ;
IntentTermnl ::= "Preserve" | "Sustain" | "Propagate" ;
ConstraintTermnl ::= "Within" | "Across" | "BoundedBy" ;
ReqTermnl ::= Identifier "=" Literal ;
Identifier ::= Letter (Letter | Digit | "_")* ;
Literal ::= String | Number | Boolean ;

• Deterministic Parse: The grammar guarantees a single parse tree for any conformant spec, eliminating ambiguous interpretations.
• Schema Validation: Each spec is validated against a JSON‑Schema that enforces required metadata (author, version, timestamp, dependencies).

4. Specification as Graph Nodes

Each specification is represented as a node in a directed acyclic graph (DAG). Nodes carry attributes:

Edges represent semantic dependency (e.g., a Requirement that references a Constraint). This graph enables:

• Semantic Diffing: Compare two versions of the graph to compute structural changes.
• Propagation Simulation: Simulate how a change propagates through the DAG, flagging potential cascading contradictions.

5. Constitutional Governance Model

The Constitutional AI layer implements a rule‑based adjudication system:

1. Policy Layer: Hard‑coded policies (e.g., “Never expose private keys”). Implemented as immutable specs with highest authority.
2. Enforcement Layer: Runtime checks that evaluate compliance against the policy layer before allowing execution of any node.
3. Audit Trail: Every decision is logged with a cryptographic hash of the invoking spec version, the evaluator, and the outcome.

These policies are encoded as spec nodes of type Policy, ensuring they themselves are subject to versioning and review.

6. Recursive Specification Evaluation

Specification evaluation proceeds recursively, mirroring the monadic bind in functional programming:

evaluate :: Spec -> Context -> Either Error Implementation
evaluate spec ctx = case spec of
    Intent i   -> propagateIntent i ctx
    Constraint c -> verifyConstraint c ctx
    Requirement r -> enforceRequirement r ctx

• Higher‑Order Intent Functions: Intent terms (Preserve, Sustain, …) are first‑class values that can be passed as arguments to other specs, enabling higher‑order specification composition.
• Lazy Evaluation: Nodes are only resolved when their runtime prerequisites are satisfied, supporting infinite spec graphs while preserving termination guarantees through well‑founded ordering on timestamps.

7. Contradiction Detection and Resolution

7.1. Formal Definition

A contradiction exists when two distinct spec nodes A and B satisfy:

A.content ⊢ (p)          -- p is provable
B.content ⊢ (¬p)          -- ¬p is provable

7.2. Detection Algorithm

1. Hash each spec node and store its logical form in an inverted index.
2. Traverse edges to collect all required propositions for a given closure.
3. Apply resolution rules:
   • If p and ¬p appear in the same closure, flag a contradiction.
   • Compute a conflict score based on semantic similarity (using a local embedding model).

7.3. Resolution Workflow

• Clarify: Invoke the local LLM with retrieved context from the Knowledge Graph (RAG).
• Propose: Generate alternative formulations that avoid the contradiction.
• Amend: Commit the amended spec version to the Spec Ledger (see Section 13).

All resolution steps are recorded in the ledger with cryptographic signatures, ensuring auditability.

8. Narrative Drift and Spec Evolution

A project's narrative is defined as the set of core Intent terms present in the initial constitution. Over time, spec versions may introduce drift:

• Lexical Drift: Substitution of synonyms that alter semantics (e.g., “preserve” → “maintain”).
• Structural Drift: Adding/Removing dependency edges that change propagation order.
• Semantic Drift: Introduction of new constraints that fundamentally alter intent (Preserve → Consume).

Drift Detection Algorithm:

1. Compute Semantic Similarity between the current spec DAG and a canonical baseline (the first committed spec).
2. Use a BERT‑based embedding to score similarity; thresholding identifies drift events.
3. Flag drift when the similarity falls below 0.75 (configurable).

Drift alerts trigger a mandatory Re‑specification Review, during which a cross‑functional panel validates that the new narrative aligns with the original civilizational goals.

9. Knowledge Graph Integration (RAG)

Specifications are grounded in a vector‑augmented knowledge graph (KG) that stores:

• Entity embeddings for technical terms, patterns, and legacy specifications.
• Relationship embeddings that capture graph‑edge semantics.

During clarify and analyze steps, the system performs Retrieval‑Augmented Generation (RAG):

1. Query Generation: Convert the current spec node into a dense vector using a local transformer.
2. Top‑k Retrieval: Retrieve the highest‑scoring relevant KG entries (typically 5–10).
3. Context Injection: Prepend retrieved snippets to the LLM's prompt, ensuring that generated clauses are evidence‑grounded.

RAG enables dynamic knowledge grounding without external APIs, preserving the sovereign nature of the architecture.

10. GBNF Grammar Enforcement Pipeline

The GBNF Enforcement Engine operates as a deterministic parser that filters LLM output before code generation.

10.1. Parsing Stage

• ANTLR‑derived Parser: Constructs a parse tree from raw LLM output.
• AST Sanitization: Strips disallowed constructs (e.g., side‑effects, non‑deterministic loops).

10.2. Code Generation Stage

• Template Substitution: Populate pre‑approved GBNF templates with validated values.
• Syntax Tree Emission: Emit code in a canonical format (e.g., Rust trait implementations).

10.3. Determinism Guarantees

Because the pipeline enforces a single parse tree and fixed template substitution, the resulting code is reproducible across runs, assuring binary‑level determinism.

11. Deterministic Code Generation Protocol

The protocol follows a pipeline contract:

[Spec Node] → (RAG Retrieval) → (GBNF Validation) → (Code Template) → [Implementation Artifact]

Key properties:

• Idempotent: Re‑running the pipeline on identical inputs yields identical outputs.
• Version‑Locked: Each spec node references a hash‑committed implementation artifact, preventing silent overwrites.
• Sandboxed Execution: Generated code is compiled inside a seccomp‑filtered container to enforce resource limits and prevent side‑effects.

12. Local‑First Deployment Architecture

12.1. Compute Model

• Quantized LLMs: Use 4‑bit quantized Llama‑3.1‑70B or equivalent via llama-cpp.
• Batch Processing: Spec evaluation and code generation are performed in batch jobs to amortize inference latency.

12.2. Storage Model

• Immutable Spec Store: All specs are stored as append‑only Merkle‑tree leaves.
• Versioned Directories: Each commit creates a new directory under /specs/ with a SHA‑256 hash name.

12.3. Network Isolation

• No Outbound Connectivity: The runtime environment disables TCP/UDP sockets.
• Local RNG: Use a hardware‑derived seed for cryptographic operations.

The entire stack runs on a single host with optional distributed replication across sovereign nodes for redundancy.

13. Versioned Spec Ledger and Change Auditing

Each spec version is recorded in a ledger entry:

{
  "spec_id": "c2f9e3a1-...",
  "version": "0.4.2",
  "timestamp": 1745608800000,
  "hash": "sha256:ab12cd34...",
  "parent_hashes": ["e7f8a9b0..."],
  "author": "danielkliewer",
  "comment": "Add deterministic timeout to async executor",
  "contradictions": [],
  "drift_score": 0.12
}

The ledger is stored as a SQLite database with WAL mode for concurrency safety. Auditing queries can produce:

• Change Histograms: Frequency of spec modifications per component.
• Dependency Impact Graphs: Visualizations of how a change ripples through the DAG.

All modifications require dual‑signature approval from at least two Governance Agents to prevent unilateral drift.

14. Security and Isolation Model

• Process Isolation: Each pipeline stage runs in a separate systemd namespace with limited capabilities.
• File Permission Model: Spec files are read‑only after commit; write access is restricted to the Ledger Service.
• Cryptographic Signing: Every spec artifact is signed with an Ed25519 key; verification is mandatory before evaluation.
• Attestation: The host reports its TPM measurement to a trusted verifier before accepting new specs.

These controls guarantee confidentiality, integrity, and availability while maintaining full local operation.

15. Scalability and Performance Considerations

Horizontal scaling is achieved by sharding the spec graph across multiple sovereign nodes; each node only processes its assigned sub‑graph.

16. Implications for Civilizational Engineering

The transition from code‑first to spec‑first mirrors the evolution from tool‑making to governance‑making. SovereignSpec provides a concrete implementation of this paradigm shift:

• Governance as Code: Policies become executable specifications that can be versioned and audited.
• Recursive Autonomy: Autonomous agents operate under immutable constitutional constraints, preventing the emergence of rogue behaviors (the “HAL problem”).
• Inter‑Civilizational Compatibility: The spec format is agnostic to language or substrate, enabling future multi‑species AI collaborations.

By anchoring engineering to immutable intent, we achieve a stability contract that outlasts shifting technological landscapes.

17. Conclusion: The Monolith as Living Specification

The monolith in 2001 was not a piece of hardware; it was a living, immutable specification that guided an entire evolutionary step. SovereignSpec re‑interprets that myth for the modern age:

• It encodes intent in a formal grammar (GBNF).
• It grounds that intent in a graph‑based knowledge store (RAG).
• It detects and resolves contradictions through a transparent ledger.
• It produces deterministic, locally‑generated code that obeys the original specification without ever leaving the machine.

In doing so, it offers a blueprint for civilizational‑scale AI systems that remain aligned, transparent, and sovereign—precisely the lesson the Collective learned millions of years ago, now within reach of contemporary engineers.

End of Document

Project Proposal: SovereignSpec — Local-First Spec-Driven Development

The spec is alive. The code obeys. Nothing leaves your machine.

1. Executive Summary

GitHub's Spec Kit (released September 2025, now at v0.5.0 as of mid-2026) has catalyzed a shift in how software gets built: Spec-Driven Development (SDD) — where specifications are the single source of truth, and code serves the spec, not the other way around. Spec Kit has 28K+ GitHub stars, supports Claude Code, Copilot, Cursor, Gemini CLI, and more, and provides a structured workflow: /constitution → /specify → /clarify → /plan → /tasks → /analyze → /implement.

But Spec Kit has a fatal flaw for sovereign builders: it requires cloud AI agents. Every spec evaluation, clarification, and implementation step routes through an external API. For a project stack built on local-first principles — specgen, synth01, objective05 — this is unacceptable.

SovereignSpec is a local-first, fully offline implementation of SDD that treats specs as living, evolvable artifacts — not static markdown files that drift from reality. It combines Spec Kit's structured workflow with your existing architectural patterns: deterministic agentic pipelines, RAG, GBNF grammar enforcement, and GraphRAG-based knowledge management.

2. The Current Landscape

2.1 Spec-Driven Development (SDD)

SDD flips traditional development: instead of code-first with specs as afterthought, specs become executable. The core equation:

Complete Specs + AI Context = Reliable Code

The context hierarchy:

1. Global rules (coding standards, patterns)
2. Project context (architecture, tech stack)
3. Feature specs (PRD, acceptance criteria)
4. Implementation specs (API, schema, components)
5. Task context (specific file, specific function)

SDD ensures layers 1–4 exist before asking for layer 5. Without specs, AI tools invent. With specs, they implement.

2.2 GitHub Spec Kit

The dominant open-source SDD toolkit. Key characteristics:

• Agent-agnostic: Works with Claude Code, Copilot, Cursor, Gemini CLI, Windsurf, TabNine CLI, Kimi Code CLI
• Structured workflow: Seven slash commands enforce a pipeline — constitution, specify, clarify, plan, tasks, analyze, implement
• Living specs: Specs are version-controlled markdown that evolve alongside code, not static documents
• Extensibility platform: v0.5.0 introduced presets, extensions, and lifecycle hooks
• Claude Code integration: Native skill since v0.4.5

2.3 What Spec Kit Gets Wrong

Cloud dependency. Every step of the Spec Kit workflow requires a cloud AI agent. The /clarify command calls an LLM API. The /plan command calls an LLM API. The /implement command calls an LLM API. There is no offline mode. There is no local model integration. For anyone who believes a weak local model controlled by you is spiritually superior to a powerful cloud model, this is a design failure.

No RAG integration. Spec Kit's specs are flat markdown files. They don't reference knowledge graphs, they don't pull context from vector stores, and they don't do retrieval-augmented reasoning during spec evaluation. For complex systems — like a sovereign intelligence OS — specs need to be grounded in actual knowledge, not just text.

No grammar enforcement. Spec Kit generates code from specs but doesn't enforce deterministic output formats. No GBNF. No typed contradiction detection. No narrative drift tracking.

No spec evolution tracking. Specs evolve in Spec Kit, but there's no structured tracking of how they evolved, why they changed, or whether changes introduce contradictions. No spec diffing with semantic analysis. No spec dependency graph.

3. The Gap: What Doesn't Exist

There is no local-first SDD tool that:

• Runs entirely offline with local LLM inference
• Treats specs as evolvable knowledge graph nodes, not flat markdown
• Enforces deterministic output via GBNF grammar
• Tracks spec drift and contradictions across spec versions
• Integrates with existing local-first toolchains (like specgen)
• Provides a CLI workflow analogous to Spec Kit's slash commands, but fully sovereign

This gap is the project.

4. Project Concept: SovereignSpec

4.1 One-Liner

A local-first, offline spec-driven development engine that treats specifications as living, graph-grounded artifacts and enforces deterministic code generation through structured pipelines — no cloud API calls required.

4.2 Core Design Principles

• Spec is the single source of truth — code serves the spec, not the other way around
• Nothing leaves the machine — all inference, evaluation, and generation happens locally
• Specs evolve — tracked through a knowledge graph with semantic diffing and contradiction detection
• Deterministic output — GBNF grammar enforcement ensures generated code is parseable and consistent
• Agent-agnostic — works with any local LLM (Llama, Mistral, Qwen, etc.) via llama-cpp or similar

4.3 High-Level Architecture

┌─────────────────────────────────────────────────┐
│                   SovereignSpec                  │
├─────────────────────────────────────────────────┤
│                                                 │
│  ┌─────────────┐    ┌──────────────────────┐    │
│  │  Spec CLI    │───▶│  Spec Engine         │    │
│  │  (commands)  │    │  (pipeline orchestrator)│  │
│  └─────────────┘    └──────────┬───────────┘    │
│                                │                │
│                   ┌────────────┼────────────┐   │
│                   ▼            ▼            ▼   │
│            ┌──────────┐ ┌──────────┐ ┌────────┐│
│            │ Spec RAG │ │ Spec KG  │ │ GBNF   ││
│            │ (retrieval│ │ (graph-  │ │ Grammar││
│            │  + context│ │ grounded │ │ enforce││
│            │  injection│ │ tracking)│ │ ment   ││
│            └──────────┘ └──────────┘ └────────┘│
│                                                 │
│  ┌─────────────┐    ┌──────────────────────┐    │
│  │  Local LLM   │◀───│  Code Generator      │    │
│  │  (llama-cpp) │    │  (deterministic      │    │
│  │              │    │   pipeline)          │    │
│  └─────────────┘    └──────────────────────┘    │
│                                                 │
└─────────────────────────────────────────────────┘

4.4 Workflow (Spec Kit Parity, Fully Offline)

4.5 What Makes It Different

Specs as Graph Nodes. Instead of flat .specify/specs/spec.md, each spec is a node in a knowledge graph. Relationships between specs are tracked: spec A depends on spec B, spec C contradicts spec D. When you /clarify, the engine doesn't just ask the LLM — it queries the spec KG for related context, retrieves via RAG, and grounds the clarification in actual project knowledge.

Evolvable Specs with Semantic Diffing. Every spec change is tracked. Not just line-level diffs — semantic diffs. If spec A says "the API must return JSON" and spec B later says "the API must return XML," the system detects the contradiction and flags it during /analyze. This is the spec equivalent of contradiction detection in specgen's pipeline.

GBNF Grammar Enforcement. Code generated from specs passes through GBNF grammar rules, ensuring deterministic, parseable output. No hallucinated syntax. No broken JSON. No malformed Python. The grammar is defined as part of the constitution.

Narrative Drift Tracking. Borrowed directly from specgen's pipeline architecture. As specs evolve, the system tracks whether the project's narrative — its core purpose and scope — has drifted. If the original constitution says "this is a local-first news synthesizer" but the specs have drifted to include cloud API integrations, the system flags it.

Typed Contradiction Detection. Specs are typed (functional vs. technical, as Context Ark distinguishes). Contradictions between functional specs and technical specs are detected and resolved through structured clarification workflows.

4.6 How It Relates to Your Existing Stack

• specgen: SovereignSpec uses specgen's pipeline architecture (GBNF grammar, contradiction detection, narrative drift tracking) but applies it to the SDD workflow instead of natural-language-to-code. Think of SovereignSpec as specgen's big brother — same DNA, different domain.
• synth01: The local LLM inference pattern is identical. SovereignSpec uses the same local-first inference stack.
• objective05: SovereignSpec can be a first-class citizen in the sovereign intelligence OS. Specs are knowledge graph nodes. The spec KG integrates with the broader knowledge infrastructure.
• Dynamic Persona MoE RAG: The spec KG can be queried via RAG during /clarify and /analyze steps, grounding spec evaluation in actual project knowledge.

5. Why Now

Spec Kit proved the market: 28K stars, adoption by AWS (Kiro), IBM (infrastructure-as-code), and the broader ecosystem. SDD is transitioning from "interesting idea" to "industry standard." But the entire ecosystem assumes cloud AI agents. The local-first SDD niche is completely empty.

You already have the building blocks: specgen's pipeline, synth01's local inference, objective05's knowledge graph infrastructure. SovereignSpec is the natural convergence point.

6. Phase 1 Scope (MVP)

1. CLI with Spec Kit-compatible commands (/sovereign-constitution, /specify, /clarify, /plan, /tasks, /analyze, /implement)
2. Local LLM integration via llama-cpp (same as specgen)
3. Spec as graph nodes — basic knowledge graph with relationship tracking
4. GBNF grammar enforcement on code generation
5. Contradiction detection between spec versions
6. RAG retrieval during clarification and analysis steps
7. No cloud API calls — fully offline

7. Risks & Mitigations

8. The Bigger Picture

SovereignSpec isn't just another SDD tool. It's the local-first answer to a methodology that currently requires surrendering your compute to cloud providers. It proves that spec-driven development doesn't need API keys. It proves that specs can be living, graph-grounded artifacts instead of static markdown files. And it proves that deterministic, grammar-enforced code generation is possible without ever calling an external endpoint.

The compute shortage is a manufactured financial bottleneck. SovereignSpec is evidence that you can build production-grade, spec-driven tooling without contributing to it.

9. Sources

• GitHub Spec Kit Repository — Official source code and documentation (28K+ stars, MIT license)
• Spec Kit Website — AI-Powered Specification-Driven Development Toolkit
• Context Ark: Spec-Driven Development for AI Coding — Complete guide to SDD methodology
• Deep Dive into SpecKit — Comprehensive analysis of SpecKit architecture
• GitHub Spec Kit in 2026: SDD Goes Mainstream — 2026 ecosystem update
• Microsoft: Diving Into Spec-Driven Development — Official Microsoft blog post
• Spec Kit Documentation: What is SDD? — Core methodology documentation
• Microsoft Learn: SDD for Enterprise Developers — Training on living specifications

How to bridge a perpetual knowledge graph to real-world tool execution — a Rust tutorial

June 8, 2026 · Daniel Kliewer

GitHub: kliewerdaniel/objective05

Table of Contents

• Introduction
• The Landscape: What Everyone Else Is Building
• The Gap
• Prerequisites and Environment Setup
• Architecture Overview
• Step 1: Project Structure
• Step 2: Configuration and Error Types
• Step 3: The Tool Discovery System
• Step 4: The Graph Query Builder
• Step 5: The Signal Evaluator
• Step 6: The Tool Execution Layer
• Step 7: The Core Agent Runtime
• Step 8: The Main Entry Point
• Step 9: TOOLS.md Files
• Step 10: Building and Running
• Environment Variables Reference
• The Kuzu Schema This Agent Expects
• Testing the Agent
• Deployment Patterns
• Integration with OpenClaw
• Troubleshooting
• Beyond the MVP
• Why This Matters
• Conclusion

Introduction

There are two fundamental modes of intelligence: understanding and acting.

Most AI systems do one or the other. Chatbots understand — they process your input, generate a response, and forget everything when the session ends. Dashboards act — they display charts, trigger alerts, send emails — but they have no memory of what happened yesterday. The product design choices that lead here are predictable: when the model is the product, you build stateless interfaces. When the dashboard is the product, you build passive displays.

I built Objective05 to solve the understanding problem. It's a local-first intelligence system written in Rust that continuously ingests information from the web, extracts entities and claims, detects contradictions and narrative drift, maintains a temporal knowledge graph backed by Kuzu DB, and generates written reports and audio broadcasts. It listens. It thinks. It remembers.

But for months now, I've been asking a different question: what does it do with what it knows?

The answer matters more than you might think. Because the biggest gap in the AI landscape right now isn't between better models and worse models. It's between systems that understand deeply and systems that can actually do something about it.

In this post, I'm going to walk through building objective05-exec — the execution runtime that bridges Objective05's knowledge graph to real-world tools. By the end, you'll have a Rust-based agent that can:

• Query the Kuzu knowledge graph for context
• Evaluate whether an action is warranted based on detected patterns
• Execute real tasks: file GitHub PRs, send emails, update spreadsheets, post to Slack/Discord, write files to disk
• Discover available tools through a TOOLS.md/SKILLS.md interface (matching the OpenClaw model)
• Run on consumer hardware, fully local, fully sovereign

This is not a cloud agent. This is not a chatbot wrapper. This is a local-first agent runtime that connects deep understanding to real-world action.

The Landscape: What Everyone Else Is Building

Before we dive into the code, let's look at what the big players launched in the last few months. Three products define the current moment:

Microsoft Scout (built on OpenClaw)

Scout is an "always-on autonomous agent" built on the OpenClaw framework. It integrates with Microsoft 365, executes tasks across cloud and desktop, and operates with enterprise-grade security. The key feature: it doesn't wait to be asked. It monitors your calendar, drafts documents, schedules meetings, and acts across your work tools autonomously.

OpenClaw — Scout's base — is itself worth studying. It's a self-hosted, multi-channel agent gateway written in Node.js, MIT licensed, that runs on consumer hardware. It supports persistent memory across sessions, multi-agent routing, tool execution, and capability discovery via TOOLS.md/SKILLS.md files. It connects to Slack, Teams, WhatsApp, Discord, Telegram, and more. It's the scaffolding that turned "chatbots that respond" into "agents that act."

Google Gemini Spark

Spark is Google's always-on agent running on dedicated GCP VMs. It monitors Gmail, Calendar, Docs, and Sheets. Its strength: task planning and structuring, collaborative teams, repeatable workflows, and autonomous background execution. It drafts documents, makes purchases, and runs workflows without user prompting.

Anthropic Orbit

Orbit is Anthropic's proactive agent that synthesizes data from Gmail, Slack, GitHub, Calendar, Google Drive, and Figma to generate personalized daily briefings. Discovered as a hidden toggle in Claude's settings in May 2026, it represents a shift from reactive chat to proactive awareness.

The Gap

Look at these three products and you'll see a pattern. They're all cloud agents with tool execution. They can act — draft a doc, send an email, file a PR — but their understanding is shallow. They have no persistent knowledge graph. No temporal reasoning. No contradiction detection. No narrative tracking. They connect to your work tools, yes, but they don't understand them the way Objective05 understands the web.

Meanwhile, Objective05 has deep local understanding — a temporal knowledge graph that tracks entities, claims, events, and contradictions over time — but no way to act on that understanding. It can detect that a narrative is diverging in the GitHub ecosystem, but it can't file a PR to address it. It can spot a contradiction between two ArXiv papers on the same topic, but it can't draft a response. It can identify a trending pattern across Hacker News, but it can't post a summary to Slack.

The gap is clear: Objective05 has the brain. It needs hands.

Prerequisites and Environment Setup

Before writing any code, you need a working Rust toolchain and a few external services configured. The agent is designed to fail soft when credentials are missing — it will log warnings and continue with whatever tools are available — but a clean install goes faster with everything in place.

1. Install Rust (stable, 1.78+)

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source "$HOME/.cargo/env"
rustup default stable
rustc --version   # should report 1.78 or newer

2. Clone the Objective05 Repository (Graph Source)

objective05-exec is a consumer of the Objective05 knowledge graph. You can either run a full Objective05 installation or stub one out:

# Full installation
git clone https://github.com/kliewerdaniel/objective05.git
cd objective05
cargo build --release
./target/release/objective05  # starts ingestion; writes to ./data/graph.db

If you only want to experiment with the execution runtime, you can use a stub Kuzu database with the schema described in The Kuzu Schema This Agent Expects.

3. Install Kuzu CLI (Optional but Useful)

The Kuzu CLI lets you inspect the graph directly:

# macOS
brew install kuzu

# Linux
curl -L https://github.com/kuzudb/kuzu/releases/latest/download/kuzu_cli-linux-x86_64.tar.gz \
  | tar -xz -C /usr/local/bin

You can then run ad-hoc queries:

kuzu ../objective05/data/graph.db
kuzu> MATCH (n:Narrative) RETURN n LIMIT 5;

4. Acquire Tool Credentials

The default toolset requires at minimum a GitHub personal access token. The rest are optional and can be enabled selectively in config.toml.

The agent does not require all five tools to run. You can enable only github and filesystem and disable the rest.

5. Verify Connectivity

Before launching the agent, sanity-check each external dependency:

# GitHub
curl -H "Authorization: token $GITHUB_TOKEN" https://api.github.com/user

# Slack
curl -X POST -H 'Content-type: application/json' \
  --data '{"text":"objective05-exec smoke test"}' \
  $SLACK_WEBHOOK_URL

# Discord
curl -X POST -H 'Content-type: application/json' \
  --data '{"content":"objective05-exec smoke test"}' \
  $DISCORD_WEBHOOK_URL

# SMTP (using openssl)
echo "Subject: smoke test" | openssl s_client -connect $SMTP_HOST:$SMTP_PORT -crlf -starttls smtp

If any of these fail, fix them before starting the agent so its logs aren't drowned in connection errors.

Architecture Overview

Here's the architecture we're building:

┌─────────────────────────────────────────────────────────────┐
│                     objective05 Daemon                      │
│                                                             │
│  ┌─────────────┐  ┌──────────────┐  ┌──────────────────┐  │
│  │ Ingestion   │  │ Knowledge    │  │ Broadcasting     │  │
│  │ Pipeline    │→│ Graph (Kuzu) │→│ Engine           │  │
│  │             │  │              │  │                  │  │
│  │ RSS/Reddit/ │  │ Entities,    │  │ Reports, Audio,  │  │
│  │ YouTube/    │  │ Claims,      │  │ Notifications    │  │
│  │ GitHub/     │  │ Events,      │  │                  │  │
│  │ ArXiv/HN    │  │ Narratives   │  │                  │  │
│  └─────────────┘  └──────┬───────┘  └──────────────────┘  │
│                          │                                  │
│                          ▼                                  │
│  ┌──────────────────────────────────────────────────────┐  │
│  │              objective05-exec Agent Runtime          │  │
│  │                                                      │  │
│  │  ┌──────────┐  ┌──────────┐  ┌──────────────────┐  │  │
│  │  │ Query    │  │ Evaluate │  │ Execute          │  │  │
│  │  │ Graph    │→│ Signals  │→│ Tools            │  │  │
│  │  └──────────┘  └──────────┘  └──────────────────┘  │  │
│  │                     │                                │  │
│  │                     ▼                                │  │
│  │           ┌──────────────────┐                       │  │
│  │           │  TOOLS.md /      │                       │  │
│  │           │  SKILLS.md       │                       │  │
│  │           │  Discovery       │                       │  │
│  │           └──────────────────┘                       │  │
│  └──────────────────────────────────────────────────────┘  │
│                          │                                  │
│                          ▼                                  │
│  ┌──────────────────────────────────────────────────────┐  │
│  │              Tool Execution Layer                    │  │
│  │                                                      │  │
│  │  GitHub  │  Email  │  Slack  │  Discord  │  Files   │  │
│  │  (PRs)   │  (SMTP) │ (Webhook)│ (Webhook)│ (Write)  │  │
│  └──────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘

The agent runtime sits between the knowledge graph and the tools. It queries the graph for context, evaluates whether an action is warranted based on detected patterns, and executes the appropriate tool. Tools are discovered through TOOLS.md/SKILLS.md files — the same pattern OpenClaw uses, which means our agent can interoperate with the OpenClaw ecosystem.

The Three-Phase Loop

Every cycle the runtime runs goes through the same three phases:

1. Query — GraphQueryBuilder constructs Cypher queries against Kuzu and pulls back rows representing signals: contradictions, narrative divergences, trending entities, new events.
2. Evaluate — SignalEvaluator matches each signal against a list of ActionRules. Rules can threshold on confidence, set priority, and decide whether to auto-execute or require human approval.
3. Execute — ToolExecutor dispatches the resulting actions to the appropriate tool, respecting a per-cycle budget and logging all outcomes.

This is intentionally not an LLM-driven loop. The intelligence comes from the graph, the rules come from you, and the LLM is reserved for the parts that actually need language understanding (drafting PR bodies, summarizing divergences). The deterministic loop is what makes the system debuggable, auditable, and cheap to run.

Step 1: Project Structure

Let's start with the directory layout:

objective05-exec/
├── Cargo.toml
├── rust-toolchain.toml
├── README.md
├── src/
│   ├── main.rs
│   ├── lib.rs
│   ├── agent/
│   │   ├── mod.rs
│   │   ├── runtime.rs        # Core agent loop
│   │   ├── query.rs          # Kuzu query builder
│   │   ├── evaluator.rs      # Signal evaluation engine
│   │   └── executor.rs       # Tool execution dispatcher
│   ├── tools/
│   │   ├── mod.rs
│   │   ├── github.rs         # GitHub PR/file tools
│   │   ├── email.rs          # SMTP email tool
│   │   ├── slack.rs          # Slack webhook tool
│   │   ├── discord.rs        # Discord webhook tool
│   │   └── filesystem.rs     # File write tool
│   ├── discovery/
│   │   ├── mod.rs
│   │   └── tool_loader.rs    # TOOLS.md/SKILLS.md parser
│   ├── config.rs             # Configuration management
│   └── error.rs              # Error types
├── tools/
│   ├── github.tools.md       # Tool capability definitions
│   ├── email.tools.md
│   ├── slack.tools.md
│   ├── discord.tools.md
│   └── filesystem.tools.md
├── config.toml               # Agent configuration
├── .env.example              # Documented env vars
└── docs/
    └── architecture.md

Initialize the project

cargo new objective05-exec
cd objective05-exec
cargo init --lib   # we'll add a binary target too

Pin the Rust toolchain (optional but recommended)

rust-toolchain.toml:

[toolchain]
channel = "stable"
components = ["rustfmt", "clippy"]

Add dependencies to Cargo.toml

[package]
name = "objective05-exec"
version = "0.1.0"
edition = "2021"
description = "Execution runtime for objective05 - bridging knowledge graphs to real-world tools"
license = "MIT OR Apache-2.0"

[dependencies]
# Async runtime
tokio = { version = "1", features = ["full"] }
async-trait = "0.1"

# Serialization
serde = { version = "1", features = ["derive"] }
serde_json = "1"
toml = "0.8"

# HTTP clients
reqwest = { version = "0.12", features = ["json", "streaming"] }
jsonwebtoken = "9"

# Kuzu DB (via FFI bindings)
kuzu = "0.4"

# Logging
tracing = "0.1"
tracing-subscriber = { version = "0.3", features = ["env-filter"] }

# Error handling
anyhow = "1"
thiserror = "2"

# UUID generation
uuid = { version = "1", features = ["v4", "serde"] }

# Time handling
chrono = { version = "0.4", features = ["serde"] }

# Email
lettre = { version = "0.11", features = ["tokio1-rustls-tls", "smtp-transport"] }

# GitHub API
octocrab = "0.38"

# Markdown parsing for TOOLS.md
pulldown-cmark = "0.11"

[profile.release]
opt-level = 3
lto = "thin"
codegen-units = 1
strip = true

Note on Kuzu: The official kuzu crate provides Rust bindings via C FFI. If you hit FFI link errors on macOS, you may need brew install kuzu first to obtain the libkuzu.dylib system library. On Linux, the crate vendors the static library; on Windows, ensure the Visual C++ runtime is installed.

.env.example

A documented template for the environment variables the agent reads at startup:

# GitHub
GITHUB_TOKEN=ghp_replace_me
DEFAULT_REPO=your-org/your-repo

# Email
SMTP_HOST=smtp.gmail.com
SMTP_PORT=587
SMTP_USERNAME=you@example.com
SMTP_PASSWORD=replace_me

# Slack
SLACK_WEBHOOK_URL=https://hooks.slack.com/services/T000/B000/XXXX

# Discord
DISCORD_WEBHOOK_URL=https://discord.com/api/webhooks/000/XXXX

# Filesystem
REPORTS_DIR=./reports

# Logging
RUST_LOG=info,objective05_exec=debug

Step 2: Configuration and Error Types

Let's start with the foundational types.

src/error.rs:

use thiserror::Error;

#[derive(Error, Debug)]
pub enum ExecError {
    #[error("Configuration error: {0}")]
    Config(String),

    #[error("Knowledge graph error: {0}")]
    GraphError(String),

    #[error("Tool execution error: {tool}: {reason}")]
    ToolError { tool: String, reason: String },

    #[error("Signal evaluation error: {0}")]
    EvaluationError(String),

    #[error("Discovery error: {0}")]
    DiscoveryError(String),

    #[error("Network error: {0}")]
    NetworkError(#[from] reqwest::Error),

    #[error("I/O error: {0}")]
    IoError(#[from] std::io::Error),
}

pub type ExecResult<T> = Result<T, ExecError>;

src/config.rs:

use serde::{Deserialize, Serialize};
use std::path::PathBuf;

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct Config {
    pub agent: AgentConfig,
    pub knowledge_graph: GraphConfig,
    pub tools: ToolsConfig,
    pub execution: ExecutionConfig,
}

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct AgentConfig {
    pub name: String,
    pub description: String,
    pub tool_discovery_path: PathBuf,
}

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct GraphConfig {
    pub path: PathBuf,
    pub query_timeout_ms: u64,
}

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct ToolsConfig {
    pub enabled_tools: Vec<String>,
    pub max_concurrent_executions: usize,
}

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct ExecutionConfig {
    pub poll_interval_secs: u64,
    pub max_action_budget_per_cycle: usize,
    pub log_executions: bool,
}

impl Config {
    pub fn from_file(path: &PathBuf) -> ExecResult<Self> {
        let content = std::fs::read_to_string(path)
            .map_err(|e| ExecError::Config(format!("Failed to read config: {}", e)))?;
        let config: Config = toml::from_str(&content)
            .map_err(|e| ExecError::Config(format!("Failed to parse config: {}", e)))?;
        Ok(config)
    }
}

config.toml:

[agent]
name = "objective05-exec"
description = "Execution runtime for objective05 - bridges knowledge graph to real-world tools"
tool_discovery_path = "tools/"

[knowledge_graph]
path = "../objective05/data/graph.db"
query_timeout_ms = 5000

[tools]
enabled_tools = ["github", "email", "slack", "discord", "filesystem"]
max_concurrent_executions = 4

[execution]
poll_interval_secs = 60
max_action_budget_per_cycle = 10
log_executions = true

A note on configuration: every field is required. If you want to make something optional (for example, the tool discovery path when running with no markdown tool files), wrap it in Option<PathBuf> and add #[serde(default)]. The defaults defined here assume a single-tenant, single-host deployment; multi-agent routing would extend Config with a routing section listing per-signal-type target agents.

Loading Config from Environment

The current Config::from_file reads from disk. For containerized deployments you may want to read specific fields from environment variables. The simplest pattern is to override the config path:

CONFIG_PATH=/etc/objective05-exec/config.toml ./target/release/objective05-exec

For full 12-factor compliance, swap Config::from_file for an envy-based deserializer that reads the same struct from process environment.

Step 3: The Tool Discovery System

This is where we borrow OpenClaw's cleverest design pattern: TOOLS.md/SKILLS.md capability discovery. Instead of hardcoding available tools, the agent reads markdown files that describe what tools exist, what parameters they accept, and when they should be used. This means tools can be added without recompiling — just drop a new .tools.md file into the tools directory.

src/discovery/mod.rs:

pub mod tool_loader;

pub use tool_loader::{ToolRegistry, ToolCapability, ParameterSchema, ToolType};

src/discovery/tool_loader.rs:

use super::ExecResult;
use crate::error::ExecError;
use serde::{Deserialize, Serialize};
use std::collections::HashMap;
use std::path::Path;

/// A tool capability as described in a TOOLS.md file
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct ToolCapability {
    pub name: String,
    pub description: String,
    pub parameters: HashMap<String, ParameterSchema>,
    pub trigger_conditions: Vec<String>,
    pub tool_type: ToolType,
}

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct ParameterSchema {
    pub r#type: String,
    pub description: String,
    pub required: bool,
    pub examples: Vec<String>,
}

#[derive(Debug, Clone, Serialize, Deserialize)]
pub enum ToolType {
    GitHub,
    Email,
    Slack,
    Discord,
    Filesystem,
    Custom(String),
}

/// Tool registry discovered from TOOLS.md files
#[derive(Debug, Clone)]
pub struct ToolRegistry {
    pub capabilities: HashMap<String, ToolCapability>,
}

impl ToolRegistry {
    /// Load all tool capabilities from the tools directory
    pub fn load_from_directory(dir_path: &Path) -> ExecResult<Self> {
        let mut capabilities = HashMap::new();

        if !dir_path.exists() {
            return Err(ExecError::DiscoveryError(
                format!("Tools directory not found: {}", dir_path.display()),
            ));
        }

        for entry in std::fs::read_dir(dir_path)? {
            let entry = entry?;
            let path = entry.path();

            if path.extension().map_or(false, |ext| ext == "md") {
                let content = std::fs::read_to_string(&path)?;
                if let Some(capability) = Self::parse_tool_file(&path, &content)? {
                    capabilities.insert(capability.name.clone(), capability);
                }
            }
        }

        Ok(Self { capabilities })
    }

    /// Parse a single TOOLS.md file into a ToolCapability
    fn parse_tool_file(
        path: &Path,
        content: &str,
    ) -> ExecResult<Option<ToolCapability>> {
        let mut name = String::new();
        let mut description = String::new();
        let mut parameters = HashMap::new();
        let mut trigger_conditions = Vec::new();
        let mut tool_type = ToolType::Custom(String::new());

        let current_tool = path
            .file_stem()
            .and_then(|s| s.to_str())
            .unwrap_or("unknown")
            .to_string();

        // Determine tool type from filename
        tool_type = match current_tool.as_str() {
            "github" => ToolType::GitHub,
            "email" => ToolType::Email,
            "slack" => ToolType::Slack,
            "discord" => ToolType::Discord,
            "filesystem" => ToolType::Filesystem,
            _ => ToolType::Custom(current_tool.clone()),
        };

        let mut in_params = false;
        let mut in_triggers = false;

        for line in content.lines() {
            if line.starts_with("# ") {
                name = line[2..].trim().to_string();
                in_params = false;
                in_triggers = false;
            } else if line.starts_with("## Parameters") {
                in_params = true;
                in_triggers = false;
            } else if line.starts_with("## Trigger Conditions") {
                in_triggers = true;
                in_params = false;
            } else if line.starts_with("## Description") || line.starts_with("### Description") {
                description = content
                    .lines()
                    .skip_while(|l| !l.contains("Description"))
                    .skip(1)
                    .take_while(|l| !l.starts_with("#"))
                    .collect::<Vec<&str>>()
                    .join("\n")
                    .trim()
                    .to_string();
            } else if line.starts_with("- **") && in_params {
                // Parse parameter line like: - **param_name** (type): description
                if let Some(param_def) = line.strip_prefix("- **") {
                    if let Some((param_name, rest)) = param_def.split_once("** (") {
                        if let Some((param_type, _desc)) = rest.split_once("): ") {
                            let desc = _desc.trim_start_matches('-').trim();
                            parameters.insert(
                                param_name.to_string(),
                                ParameterSchema {
                                    r#type: param_type.to_string(),
                                    description: desc.to_string(),
                                    required: false, // Default, can be overridden
                                    examples: Vec::new(),
                                },
                            );
                        }
                    }
                }
            } else if line.starts_with("- ") && in_triggers {
                if let Some(condition) = line.strip_prefix("- ") {
                    trigger_conditions.push(condition.trim().to_string());
                }
            }
        }

        if name.is_empty() {
            return Ok(None);
        }

        Ok(Some(ToolCapability {
            name,
            description,
            parameters,
            trigger_conditions,
            tool_type,
        }))
    }

    /// Check if any trigger conditions match a given graph signal
    pub fn match_triggers(&self, signal: &GraphSignal) -> Vec<String> {
        self.capabilities
            .iter()
            .filter_map(|(name, cap)| {
                if cap
                    .trigger_conditions
                    .iter()
                    .any(|cond| signal.matches(cond))
                {
                    Some(name.clone())
                } else {
                    None
                }
            })
            .collect()
    }
}

A small but important detail: the parser is intentionally tolerant. A TOOLS.md with no ## Parameters section still loads — the resulting ToolCapability just has an empty parameters map. This means you can write a TOOLS.md that documents a tool's intent without committing to a typed schema, useful for early prototyping.

The match_triggers method does a substring match between signal-type strings and trigger-condition text. For higher precision, you can replace it with a real expression evaluator (see Beyond the MVP).

Step 4: The Graph Query Builder

Now we need a way to query the Kuzu knowledge graph for context. This is where Objective05's temporal graph comes in — we're not just asking "what's true?" We're asking "what changed?", "what contradicts?", "what's trending?"

src/agent/mod.rs:

pub mod runtime;
pub mod query;
pub mod evaluator;
pub mod executor;

src/agent/query.rs:

use crate::config::Config;
use crate::discovery::tool_loader::ToolRegistry;
use crate::error::{ExecError, ExecResult};
use serde_json::json;
use std::sync::Arc;
use tokio::sync::Mutex;

/// A graph signal that represents a detectable pattern
#[derive(Debug, Clone)]
pub struct GraphSignal {
    pub signal_type: SignalType,
    pub entity: String,
    pub context: serde_json::Value,
}

#[derive(Debug, Clone)]
pub enum SignalType {
    ContradictionDetected,
    NarrativeDivergence,
    TrendingEntity,
    NewEvent,
    ClaimSuperseded,
    Custom(String),
}

impl std::fmt::Display for SignalType {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        match self {
            SignalType::ContradictionDetected => write!(f, "ContradictionDetected"),
            SignalType::NarrativeDivergence => write!(f, "NarrativeDivergence"),
            SignalType::TrendingEntity => write!(f, "TrendingEntity"),
            SignalType::NewEvent => write!(f, "NewEvent"),
            SignalType::ClaimSuperseded => write!(f, "ClaimSuperseded"),
            SignalType::Custom(s) => write!(f, "{}", s),
        }
    }
}

impl GraphSignal {
    pub fn matches(&self, condition: &str) -> bool {
        match &self.signal_type {
            SignalType::ContradictionDetected => condition.contains("contradiction"),
            SignalType::NarrativeDivergence => condition.contains("narrative"),
            SignalType::TrendingEntity => condition.contains("trending"),
            SignalType::NewEvent => condition.contains("event"),
            SignalType::ClaimSuperseded => condition.contains("superseded"),
            SignalType::Custom(c) => condition.contains(c.as_str()),
        }
    }
}

/// Query builder for Kuzu knowledge graph
pub struct GraphQueryBuilder {
    config: Config,
}

impl GraphQueryBuilder {
    pub fn new(config: Config) -> Self {
        Self { config }
    }

    /// Query for recent contradictions in tracked narratives
    pub fn build_contradiction_query(&self) -> String {
        format!(
            r#"
            MATCH (c:Contradiction)
            WHERE c.detected_at > datetime('{}')
            RETURN c.id AS contradiction_id,
                   c.claim_a AS claim_a,
                   c.claim_b AS claim_b,
                   c.entity AS entity,
                   c.detected_at AS detected_at,
                   c.confidence AS confidence
            ORDER BY c.detected_at DESC
            LIMIT 50
            "#,
            chrono::Utc::now()
                .checked_sub_signed(chrono::Duration::hours(24))
                .unwrap()
                .to_rfc3339()
        )
    }

    /// Query for narratives with highest divergence scores
    pub fn build_divergence_query(&self) -> String {
        format!(
            r#"
            MATCH (n:Narrative)
            WHERE n.divergence_score > 0.5
                  AND n.updated_at > datetime('{}')
            RETURN n.id AS narrative_id,
                   n.title AS title,
                   n.divergence_score AS divergence_score,
                   n.tracked_entities AS entities,
                   n.updated_at AS updated_at
            ORDER BY n.divergence_score DESC
            LIMIT 20
            "#,
            chrono::Utc::now()
                .checked_sub_signed(chrono::Duration::hours(48))
                .unwrap()
                .to_rfc3339()
        )
    }

    /// Query for trending entities by mention velocity
    pub fn build_trending_query(&self) -> String {
        format!(
            r#"
            MATCH (e:Entity)
            WHERE e.mention_velocity > 5
                  AND e.last_seen > datetime('{}')
            RETURN e.id AS entity_id,
                   e.name AS name,
                   e.mention_velocity AS velocity,
                   e.category AS category,
                   e.last_seen AS last_seen
            ORDER BY e.mention_velocity DESC
            LIMIT 10
            "#,
            chrono::Utc::now()
                .checked_sub_signed(chrono::Duration::hours(12))
                .unwrap()
                .to_rfc3339()
        )
    }

    /// Build a query for new events in tracked domains
    pub fn build_events_query(&self) -> String {
        format!(
            r#"
            MATCH (e:Event)
            WHERE e.created_at > datetime('{}')
                  AND e.verified = true
            RETURN e.id AS event_id,
                   e.title AS title,
                   e.description AS description,
                   e.related_entities AS entities,
                   e.confidence AS confidence,
                   e.created_at AS created_at
            ORDER BY e.created_at DESC
            LIMIT 30
            "#,
            chrono::Utc::now()
                .checked_sub_signed(chrono::Duration::hours(6))
                .unwrap()
                .to_rfc3339()
        )
    }

    /// Execute a query against the Kuzu graph via the Rust FFI bindings.
    /// In this tutorial the FFI is stubbed; in production, replace with
    /// a real `kuzu::Database` and `kuzu::Connection`.
    pub async fn execute_query(&self, query: &str) -> ExecResult<serde_json::Value> {
        tracing::info!("Executing graph query: {}", query);

        // Simulate query execution
        tokio::time::sleep(tokio::time::Duration::from_millis(100)).await;

        Ok(json!({
            "status": "success",
            "rows": []
        }))
    }
}

A few notes on the query builder:

• Time windows are computed from Utc::now() at call time. If you need historical replays, accept a since: DateTime<Utc> parameter on each builder and pass it from the runtime.
• Limits (LIMIT 50, LIMIT 20, etc.) are conservative defaults. They exist to prevent runaway result sets if the graph is dense. Tune them based on your action budget.
• The execute_query stub returns an empty rows array. The real implementation should construct a kuzu::Connection, call conn.query(query), and walk the resulting QueryResult to serialize rows into serde_json::Value. Treat the stub as a typed boundary: anything that passes through it must serialize cleanly.

Step 5: The Signal Evaluator

The evaluator is the decision engine. It takes raw graph signals and determines which tools should be triggered. This is where the "thinking" happens — not with an LLM, but with rule-based evaluation against the knowledge graph.

src/agent/evaluator.rs:

use crate::agent::query::GraphSignal;
use crate::discovery::tool_loader::ToolRegistry;
use crate::error::ExecResult;

/// An evaluation rule that maps signals to tool actions
#[derive(Debug, Clone)]
pub struct ActionRule {
    pub rule_id: String,
    pub signal_type: String,
    pub threshold: f64,
    pub action: ActionDefinition,
}

#[derive(Debug, Clone)]
pub struct ActionDefinition {
    pub tool_name: String,
    pub priority: Priority,
    pub description: String,
    pub auto_execute: bool,
}

#[derive(Debug, Clone, PartialEq)]
pub enum Priority {
    Low,
    Medium,
    High,
    Critical,
}

/// The signal evaluator that matches rules against graph signals
pub struct SignalEvaluator {
    pub rules: Vec<ActionRule>,
}

impl SignalEvaluator {
    pub fn new() -> Self {
        Self { rules: Vec::new() }
    }

    /// Add an evaluation rule
    pub fn add_rule(&mut self, rule: ActionRule) {
        self.rules.push(rule);
    }

    /// Evaluate a signal against all rules and return matching actions
    pub fn evaluate(&self, signal: &GraphSignal) -> ExecResult<Vec<ActionDefinition>> {
        let mut actions = Vec::new();
        let signal_type_str = signal.signal_type.to_string();

        for rule in &self.rules {
            if rule.signal_type != signal_type_str {
                continue;
            }
            // Check confidence/threshold
            if let Some(confidence) = signal.context.get("confidence") {
                if let Some(score) = confidence.as_f64() {
                    if score < rule.threshold {
                        continue;
                    }
                }
            }
            actions.push(rule.action.clone());
        }

        Ok(actions)
    }

    /// Evaluate multiple signals and return all matching actions
    pub fn evaluate_batch(
        &self,
        signals: &[GraphSignal],
        registry: &ToolRegistry,
    ) -> ExecResult<Vec<(GraphSignal, Vec<ActionDefinition>)>> {
        let mut results = Vec::new();

        for signal in signals {
            if let Ok(actions) = self.evaluate(signal) {
                if !actions.is_empty() {
                    results.push((signal.clone(), actions));
                }
            }
        }

        Ok(results)
    }
}

/// Build default evaluation rules for common patterns
pub fn build_default_rules() -> SignalEvaluator {
    let mut evaluator = SignalEvaluator::new();

    // Rule: High-confidence contradictions → GitHub PR
    evaluator.add_rule(ActionRule {
        rule_id: "contradiction-pr".to_string(),
        signal_type: "ContradictionDetected".to_string(),
        threshold: 0.7,
        action: ActionDefinition {
            tool_name: "github".to_string(),
            priority: Priority::High,
            description: "File PR to update conflicting entity in knowledge base".to_string(),
            auto_execute: true,
        },
    });

    // Rule: High divergence narratives → Slack notification
    evaluator.add_rule(ActionRule {
        rule_id: "narrative-slack".to_string(),
        signal_type: "NarrativeDivergence".to_string(),
        threshold: 0.5,
        action: ActionDefinition {
            tool_name: "slack".to_string(),
            priority: Priority::Medium,
            description: "Notify team of narrative divergence in tracked domain".to_string(),
            auto_execute: false,
        },
    });

    // Rule: Trending entities → File system report
    evaluator.add_rule(ActionRule {
        rule_id: "trending-report".to_string(),
        signal_type: "TrendingEntity".to_string(),
        threshold: 0.0,
        action: ActionDefinition {
            tool_name: "filesystem".to_string(),
            priority: Priority::Low,
            description: "Write trending entity analysis to reports directory".to_string(),
            auto_execute: true,
        },
    });

    // Rule: New verified events → Discord announcement
    evaluator.add_rule(ActionRule {
        rule_id: "event-discord".to_string(),
        signal_type: "NewEvent".to_string(),
        threshold: 0.8,
        action: ActionDefinition {
            tool_name: "discord".to_string(),
            priority: Priority::High,
            description: "Announce new verified event to Discord channel".to_string(),
            auto_execute: true,
        },
    });

    evaluator
}

A few thoughts on the rule design:

• auto_execute: false is the safe default for new rules.
• Thresholds are typed as f64 — never compare with ==.
• Rule IDs should be stable across releases; treat them like primary keys.

You can persist these rules to config.toml and reload at startup if you want them editable without recompiling. A simple format:

[[rules]]
rule_id = "contradiction-pr"
signal_type = "ContradictionDetected"
threshold = 0.7
tool_name = "github"
priority = "High"
auto_execute = true
description = "File PR to update conflicting entity in knowledge base"

Then in main.rs:

let rules_toml = std::fs::read_to_string("rules.toml")?;
let rules: Vec<ActionRule> = toml::from_str(&rules_toml)?;
let mut evaluator = SignalEvaluator::new();
for r in rules { evaluator.add_rule(r); }

This makes the agent's behavior data-driven rather than code-driven.

Step 6: The Tool Execution Layer

Now the hands. Each tool implements a common trait so the executor can dispatch to any tool uniformly.

src/tools/mod.rs:

pub mod github;
pub mod email;
pub mod slack;
pub mod discord;
pub mod filesystem;

use crate::error::ExecResult;
use serde_json::Value;

#[async_trait::async_trait]
pub trait ExecutableTool: Send + Sync {
    async fn execute(&self, params: Value) -> ExecResult<ToolResult>;
    fn validate(&self, params: &Value) -> ExecResult<()>;
    fn name(&self) -> &str;
}

pub struct ToolResult {
    pub success: bool,
    pub output: String,
    pub metadata: serde_json::Value,
}

The five tool implementations (github.rs, email.rs, slack.rs, discord.rs, filesystem.rs) follow the same trait implementation pattern. The full source is in the companion repository. Each tool:

1. Validates required parameters.
2. Calls the external API or system call.
3. Returns a ToolResult with success status, human-readable output, and structured metadata.
4. Logs the action via tracing for observability.

The key invariants are:

• All required parameters are validated before any side effect.
• Every execution logs an info! trace with the tool name, action, and a summary of the parameters.
• External errors are wrapped in ExecError::ToolError with a { tool, reason } payload.

Securing the Filesystem Tool

The FilesystemTool writes to self.base_dir. In production you must constrain the base directory with a canonical-path check to prevent path traversal:

fn safe_resolve(&self, rel: &str) -> ExecResult<PathBuf> {
    let base = Path::new(&self.base_dir).canonicalize()?;
    let candidate = base.join(rel);
    let canonical = candidate.canonicalize().unwrap_or(candidate);
    if !canonical.starts_with(&base) {
        return Err(ExecError::ToolError { tool: "filesystem".into(), reason: format!("Path '{}' escapes base directory", rel) });
    }
    Ok(canonical)
}

Always invoke safe_resolve before opening a file. A signal that requests path: "../../etc/passwd" will be rejected.

Now the executor dispatcher:

src/agent/executor.rs:

use crate::agent::evaluator::ActionDefinition;
use crate::error::{ExecError, ExecResult};
use crate::tools::{ExecutableTool, ToolResult, github::GitHubTool, email::EmailTool, slack::SlackTool, discord::DiscordTool, filesystem::FilesystemTool};
use serde_json::Value;
use std::collections::HashMap;

pub struct ToolExecutor {
    pub tools: HashMap<String, Box<dyn ExecutableTool>>,
}

impl ToolExecutor {
    pub fn new(config: &crate::config::Config) -> ExecResult<Self> {
        let mut executor = Self { tools: HashMap::new() };
        for tool_name in &config.tools.enabled_tools {
            match tool_name.as_str() {
                "github" => { executor.tools.insert("github".into(), Box::new(GitHubTool { token: std::env::var("GITHUB_TOKEN").unwrap_or_default(), default_repo: std::env::var("DEFAULT_REPO").unwrap_or_default() })); },
                "email" => { executor.tools.insert("email".into(), Box::new(EmailTool { smtp_host: std::env::var("SMTP_HOST").unwrap_or_default(), smtp_port: std::env::var("SMTP_PORT").ok().and_then(|p| p.parse().ok()).unwrap_or(587), username: std::env::var("SMTP_USERNAME").unwrap_or_default(), password: std::env::var("SMTP_PASSWORD").unwrap_or_default() })); },
                "slack" => { executor.tools.insert("slack".into(), Box::new(SlackTool { webhook_url: std::env::var("SLACK_WEBHOOK_URL").unwrap_or_default() })); },
                "discord" => { executor.tools.insert("discord".into(), Box::new(DiscordTool { webhook_url: std::env::var("DISCORD_WEBHOOK_URL").unwrap_or_default() })); },
                "filesystem" => { executor.tools.insert("filesystem".into(), Box::new(FilesystemTool { base_dir: std::env::var("REPORTS_DIR").unwrap_or_else(|_| "./reports".to_string()) })); },
                _ => tracing::warn!("Unknown tool in config: {}", tool_name),
            }
        }
        Ok(executor)
    }

    pub async fn execute_action(&self, action: &ActionDefinition, params: Value) -> ExecResult<ToolResult> {
        let tool = self.tools.get(action.tool_name.as_str()).ok_or_else(|| ExecError::ToolError { tool: action.tool_name.clone(), reason: "Tool not found in executor".into() })?;
        tracing::info!("Executing tool '{}' with priority {:?}: {}", action.tool_name, action.priority, action.description);
        if let Err(e) = tool.validate(&params) { tracing::warn!("Validation failed for {}: {}", action.tool_name, e); return Err(e); }
        let result = tool.execute(params).await;
        if let Ok(ref r) = result { tracing::info!("Tool '{}' succeeded: {}", action.tool_name, r.output); } else { tracing::error!("Tool '{}' failed: {:?}", action.tool_name, result.err()); }
        result
    }

    pub async fn execute_batch(&self, actions: Vec<(ActionDefinition, Value)>, max_budget: usize) -> ExecResult<Vec<ToolResult>> {
        let mut results = Vec::new();
        let budget = actions.len().min(max_budget);
        tracing::info!("Executing {} actions (budget: {})", budget, max_budget);
        for (i, (action, params)) in actions.into_iter().enumerate() {
            if i >= budget { tracing::info!("Action budget reached, skipping remaining"); break; }
            match self.execute_action(&action, params).await {
                Ok(r) => results.push(r),
                Err(e) => tracing::error!("Failed to execute action {}: {}", i, e),
            }
        }
        Ok(results)
    }
}

Step 7: The Core Agent Runtime

This is the heart of the system — the poll→evaluate→execute loop. It runs continuously, querying the knowledge graph, evaluating signals against rules, and dispatching actions to tools.

src/agent/runtime.rs:

use crate::agent::evaluator::{SignalEvaluator, build_default_rules};
use crate::agent::executor::ToolExecutor;
use crate::agent::query::{GraphQueryBuilder, GraphSignal, SignalType};
use crate::config::Config;
use crate::discovery::tool_loader::ToolRegistry;
use crate::error::ExecResult;
use serde_json::json;

pub struct AgentRuntime {
    config: Config,
    query_builder: GraphQueryBuilder,
    evaluator: SignalEvaluator,
    executor: ToolExecutor,
    registry: ToolRegistry,
}

impl AgentRuntime {
    pub fn new(config: Config) -> ExecResult<Self> {
        let query_builder = GraphQueryBuilder::new(config.clone());
        let evaluator = build_default_rules();
        let executor = ToolExecutor::new(&config)?;
        let registry = ToolRegistry::load_from_directory(&config.agent.tool_discovery_path)?;
        Ok(Self { config, query_builder, evaluator, executor, registry })
    }

    pub async fn run_cycle(&self) -> ExecResult<Vec<String>> {
        tracing::info!("Starting execution cycle");
        let mut outputs = Vec::new();
        let signals = self.collect_signals().await?;
        tracing::info!("Collected {} graph signals", signals.len());
        if signals.is_empty() { tracing::info!("No signals detected this cycle"); return Ok(outputs); }
        let evaluations = self.evaluator.evaluate_batch(&signals, &self.registry)?;
        tracing::info!("{} signals matched evaluation rules", evaluations.len());
        let actions: Vec<_> = evaluations.into_iter()
            .flat_map(|(signal, actions)| actions.into_iter().map(move |action| {
                let params = json!({"signal_type": signal.signal_type.to_string(), "entity": signal.entity, "context": signal.context});
                (action, params)
            }))
            .collect();
        let results = self.executor.execute_batch(actions, self.config.execution.max_action_budget_per_cycle).await?;
        for r in results { outputs.push(r.output); }
        tracing::info!("Execution cycle complete: {} actions executed", outputs.len());
        Ok(outputs)
    }

    async fn collect_signals(&self) -> ExecResult<Vec<GraphSignal>> {
        let mut signals = Vec::new();
        if let Ok(result) = self.query_builder.execute_query(&self.query_builder.build_contradiction_query()).await {
            if let Some(rows) = result.get("rows").and_then(|r| r.as_array()) {
                for row in rows {
                    signals.push(GraphSignal { signal_type: SignalType::ContradictionDetected, entity: row.get("entity").and_then(|e| e.as_str()).unwrap_or("unknown").to_string(), context: row.clone() });
                }
            }
        }
        Ok(signals)
    }

    pub async fn run_forever(&self) -> ExecResult<()> {
        tracing::info!("Starting agent runtime (poll interval: {}s)", self.config.execution.poll_interval_secs);
        let interval = std::time::Duration::from_secs(self.config.execution.poll_interval_secs);
        loop {
            tracing::info!("--- Execution cycle starting ---");
            match self.run_cycle().await {
                Ok(outputs) => { for o in outputs { tracing::info!("Output: {}", o); } },
                Err(e) => { tracing::error!("Cycle failed: {}", e); },
            }
            tracing::info!("--- Execution cycle complete, sleeping ---");
            tokio::time::sleep(interval).await;
        }
    }
}

For graceful shutdown, wrap the loop in a tokio::select! against a shutdown signal.

Step 8: The Main Entry Point

src/main.rs:

mod agent;
mod config;
mod discovery;
mod error;
mod tools;

use objective05_exec::config::Config;
use objective05_exec::error::ExecResult;
use tracing_subscriber::EnvFilter;

#[tokio::main]
async fn main() -> ExecResult<()> {
    tracing_subscriber::fmt()
        .with_env_filter(EnvFilter::try_from_default_env().unwrap_or_else(|_| EnvFilter::new("info")))
        .init();
    let config_path = std::path::PathBuf::from("config.toml");
    let config = Config::from_file(&config_path)?;
    tracing::info!("Starting objective05-exec v{}", env!("CARGO_PKG_VERSION"));
    let runtime = agent::runtime::AgentRuntime::new(config)?;
    tracing::info!("Agent runtime initialized. Starting execution loop...");
    runtime.run_forever().await?;
    Ok(())
}

Also expose src/lib.rs:

pub mod agent;
pub mod config;
pub mod discovery;
pub mod error;
pub mod tools;
pub use config::Config;
pub use error::{ExecError, ExecResult};

Step 9: TOOLS.md Files

The capability discovery files live in the tools/ directory. The five files (github.tools.md, email.tools.md, slack.tools.md, discord.tools.md, filesystem.tools.md) follow the same three-section format:

• ## Description — what the tool does, in plain language
• ## Parameters — name, type, required/optional, example
• ## Trigger Conditions — natural-language rules describing when the agent should consider using this tool

The agent never compiles against the contents of these files at runtime — they exist as documentation for the operator and as input to future LLM-driven tool selectors.

Step 10: Building and Running

With everything in place:

cargo build --release
./target/release/objective05-exec

For development, run with RUST_LOG=objective05_exec=debug to see per-query and per-tool traces.

Environment Variables Reference

All variables are read at startup. There is no hot-reload — restart the agent to pick up new credentials.

The Kuzu Schema This Agent Expects

objective05-exec queries four node types and reads their temporal/relational properties. If you are building a graph from scratch (or pointing the agent at an existing one), the schema below covers everything the four default queries reference.

Node Tables

CREATE NODE TABLE Entity(
    id STRING PRIMARY KEY,
    name STRING,
    category STRING,
    mention_velocity DOUBLE,
    last_seen TIMESTAMP
);

CREATE NODE TABLE Narrative(
    id STRING PRIMARY KEY,
    title STRING,
    divergence_score DOUBLE,
    tracked_entities STRING[],
    updated_at TIMESTAMP
);

CREATE NODE TABLE Contradiction(
    id STRING PRIMARY KEY,
    claim_a STRING,
    claim_b STRING,
    entity STRING,
    detected_at TIMESTAMP,
    confidence DOUBLE
);

CREATE NODE TABLE Event(
    id STRING PRIMARY KEY,
    title STRING,
    description STRING,
    related_entities STRING[],
    confidence DOUBLE,
    verified BOOLEAN,
    created_at TIMESTAMP
);

CREATE NODE TABLE Claim(
    id STRING PRIMARY KEY,
    text STRING,
    entity STRING,
    superseded_by STRING,
    created_at TIMESTAMP
);

Seed Script

If you do not have an Objective05 instance running, this Kuzu script populates a minimal graph the agent can act on:

CREATE (e1:Entity {id: 'e1', name: 'Rust Foundation', category: 'org', mention_velocity: 12.4, last_seen: timestamp()});
CREATE (e2:Entity {id: 'e2', name: 'Local-first AI', category: 'topic', mention_velocity: 8.1, last_seen: timestamp()});
CREATE (n1:Narrative {id: 'n1', title: 'Edge LLM Adoption', divergence_score: 0.72, tracked_entities: ['e1', 'e2'], updated_at: timestamp()});
CREATE (c1:Contradiction {id: 'c1', claim_a: 'Edge LLMs reduce cost', claim_b: 'Edge LLMs increase engineering cost', entity: 'e2', detected_at: timestamp(), confidence: 0.83});
CREATE (ev1:Event {id: 'ev1', title: 'Rust 1.85 released', description: 'New async fn in traits stabilization', related_entities: ['e1'], confidence: 0.99, verified: true, created_at: timestamp()});

After seeding, run the agent and watch the filesystem report get written.

Testing the Agent

The MVP does not ship with a full test suite, but the architecture has obvious test seams. Start with three layers.

1. Unit Tests for Pure Logic

SignalEvaluator::evaluate and GraphSignal::matches are deterministic functions with no I/O. Cover them with table-driven tests:

#[cfg(test)]
mod tests {
    use super::*;
    use crate::agent::query::{GraphSignal, SignalType};
    use serde_json::json;

    #[test]
    fn evaluator_threshold_blocks_low_confidence() {
        let mut ev = SignalEvaluator::new();
        ev.add_rule(ActionRule {
            rule_id: "test".into(),
            signal_type: "ContradictionDetected".into(),
            threshold: 0.8,
            action: ActionDefinition { tool_name: "github".into(), priority: Priority::High, description: "test".into(), auto_execute: true },
        });
        let high = GraphSignal { signal_type: SignalType::ContradictionDetected, entity: "x".into(), context: json!({"confidence": 0.9}) };
        let low = GraphSignal { signal_type: SignalType::ContradictionDetected, entity: "x".into(), context: json!({"confidence": 0.5}) };
        assert_eq!(ev.evaluate(&high).unwrap().len(), 1);
        assert_eq!(ev.evaluate(&low).unwrap().len(), 0);
    }
}

2. Integration Tests with Mocked Tools

Implement a MockTool that records calls into a Vec<RecordedCall> and assert on it after a cycle. This validates the executor dispatch without touching real APIs.

pub struct MockTool { pub calls: Arc<Mutex<Vec<serde_json::Value>>> }

#[async_trait::async_trait]
impl ExecutableTool for MockTool {
    async fn execute(&self, params: Value) -> ExecResult<ToolResult> {
        self.calls.lock().await.push(params);
        Ok(ToolResult { success: true, output: "ok".into(), metadata: json!({}) })
    }
    fn validate(&self, _params: &Value) -> ExecResult<()> { Ok(()) }
    fn name(&self) -> &str { "mock" }
}

3. End-to-End Smoke Test

The seed script plus a filesystem tool with REPORTS_DIR=./smoke-out gives you a complete E2E test. After one cycle, assert that ./smoke-out/trending_*.md exists and contains a markdown header.

Deployment Patterns

Bare-Metal / Home Server

The simplest deployment. cargo build --release on the host, then run the binary under tmux or systemd. Set RUST_LOG=info and let it poll every 60 seconds.

Docker

FROM rust:1.78 as builder
WORKDIR /app
COPY . .
RUN cargo build --release

FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y libkuzu1.4 ca-certificates && rm -rf /var/lib/apt/lists/*
COPY --from=builder /app/target/release/objective05-exec /usr/local/bin/
COPY config.toml /etc/objective05-exec/
COPY tools /etc/objective05-exec/tools/
WORKDIR /etc/objective05-exec
CMD ["/usr/local/bin/objective05-exec"]

Build and run:

docker build -t objective05-exec .
docker run -d --restart unless-stopped   -v /path/to/objective05-graph:/data:ro   -v /path/to/reports:/reports   --env-file .env   objective05-exec

Kubernetes

Deploy as a Deployment with a single replica (the runtime is not designed to be horizontally scaled without coordination on the graph database). Mount the Kuzu graph as a ReadOnlyMany PVC, mount the reports directory as ReadWriteOnce, and pass credentials via Secret. The run_forever loop can be paired with a livenessProbe that hits a /healthz endpoint (add a tiny axum server to main.rs if you want this).

GitHub Actions CI

The integration test layer runs entirely offline, so it can live in a normal GitHub Actions job without any external services. Cache ~/.cargo and target/ between runs to keep CI under 5 minutes.

Integration with OpenClaw

One of the most powerful aspects of this architecture is its compatibility with the OpenClaw ecosystem. Because we use the same TOOLS.md/SKILLS.md discovery pattern, your objective05-exec runtime can:

1. Share tool definitions with OpenClaw agents — one set of capability files, multiple agents
2. Receive commands from OpenClaw gateways — the agent can be triggered remotely via WebSocket
3. Execute OpenClaw tools — any tool that follows the OpenClaw specification works with our executor
4. Feed results back — tool execution results can be persisted to the Kuzu graph as observations

To integrate, run OpenClaw as a sidecar process and have it forward incoming chat messages to objective05-exec over a Unix socket. The executor's signal-evaluation step already filters by auto_execute, so OpenClaw-originated signals can be marked for human approval by default.

Troubleshooting

The agent starts but logs no signals

Open the Kuzu CLI and run MATCH (n) RETURN count(n). If the graph is empty, the seed script (above) will populate it. If the graph has rows but your queries return nothing, check the time window — the default queries use 6–48 hour windows, and a fresh graph won't have any data inside those windows.

Validation failed for filesystem: Path 'foo' escapes base directory

safe_resolve is doing its job. Either use a relative path that stays under REPORTS_DIR or update the rule to skip the offending path.

Tool 'githb' not found in executor

Typo in config.toml's enabled_tools array. The agent logs a warn! for unknown tools but does not crash — fix the typo and restart.

Kuzu link errors on macOS

brew install kuzu then export KUZU_INCLUDE_PATH=/opt/homebrew/include and export LIBRARY_PATH=/opt/homebrew/lib before cargo build. On Apple Silicon the path is /opt/homebrew/; on Intel it is /usr/local/.

Cycle fails with Query timeout

Increase query_timeout_ms in config.toml. The Kuzu FFI default is 5 seconds; on a slow disk or a graph over 10M nodes, you may need 15–30 seconds.

Slack/Discord webhook returns 404

The webhook URL is invalid or has been revoked. Generate a new one and update the env var.

Agent uses 100% CPU

You are probably hitting the graph on every cycle. Lower the signal ceiling by raising the threshold values in your rules, or by reducing poll_interval_secs.

Beyond the MVP

The current implementation covers the core loop: poll→evaluate→execute with five tool integrations. Here is what is next.

Autonomous Drafting

Instead of just executing predefined actions, the agent can draft PRs or documents by querying the graph for relevant context, assembling a response using the detected entities and claims, and submitting it for human review. The draft becomes an observation in the graph — if accepted, it updates the knowledge state. If rejected, it feeds back into the contradiction detection system.

Calendar-Aware Scheduling

The agent can check calendar availability before scheduling meetings, sending reports, or triggering batch executions. This adds temporal intelligence beyond the knowledge graph — the agent understands not just what is true, but when to act on it.

Multi-Agent Routing

Multiple objective05-exec instances could run in parallel, each specialized for a different domain (GitHub monitoring, ArXiv tracking, news analysis). A master router evaluates signals and dispatches to the appropriate specialist agent. This mirrors the multi-agent routing in OpenClaw but with deeper domain specialization.

Mobile Push Notifications

For high-priority signals — critical contradictions, breaking events, trending entities — the agent can push notifications to mobile devices via APNs/FCM. This bridges the gap between background intelligence and real-time awareness.

Outcome Feedback Loops

Every tool execution produces an outcome. Those outcomes — success, failure, user acceptance — feed back into the knowledge graph as new observations. A PR that gets merged confirms a hypothesis. An email that gets opened confirms relevance. A Slack message that gets replied to confirms urgency. Over time, the agent's evaluation rules self-tune based on historical outcome data.

Expression-Based Triggers

Replace the substring match in ToolRegistry::match_triggers with a real expression evaluator (e.g., cel-rust or rhai). Rules can then express complex conditions like confidence > 0.7 AND entity in ['rust', 'go'] without rewriting the discovery parser.

Why This Matters

The current AI landscape is dominated by two approaches: cloud agents that are always-on but shallow, and local models that are deep but passive. objective05-exec sits in the middle. It's local-first — runs on consumer hardware, no API costs, no vendor lock-in. But unlike a local chatbot, it has hands. It can file PRs, send emails, write reports, post to Slack.

The key insight is that tool execution does not require the cloud. You do not need a $200/month agent subscription to have an AI that drafts PRs and sends emails. You need:

1. A knowledge graph to provide context
2. An evaluation engine to decide what to do
3. A tool layer to execute actions
4. A discovery system to add new tools

All of this runs locally. The only cloud dependency is the tools themselves — GitHub's API, your SMTP server, Slack's webhooks. The intelligence, the memory, the reasoning — all local.

This is sovereign AI execution. Not because it is offline. But because it is yours.

Conclusion

objective05-exec is the bridge between understanding and action. It takes everything the knowledge graph has learned — contradictions, divergences, trends, events — and turns them into real-world outcomes: PRs filed, emails sent, reports written, channels notified.

It's built on the same principles that drove Objective05: local-first, persistent state, tool-agnostic, and open source. It does not need a cloud subscription. It does not forget what it learned yesterday. And it does not wait to be asked.

The brain is ready. The hands are ready. What it does next is up to what the graph tells it.

This post is part of the ongoing documentation for Objective05 — the perpetual local intelligence system. Previous posts: The Model Is Not the Product: On Building Persistent Intelligence Infrastructure, objective03: A Local News Agency, Mastering llama.cpp: Local LLM Integration.

June 8, 2026 · Daniel Kliewer

There is a strange contradiction at the center of modern software development.

We have coding agents capable of writing React applications, deploying infrastructure, refactoring monoliths, generating tests, orchestrating CI/CD pipelines, and reasoning across entire repositories. We have local models that can run on consumer hardware. We have Model Context Protocol (MCP) servers that allow AI systems to interact with structured tools and data. We have open-source ecosystems that increasingly rival commercial offerings.

Yet most development workflows still require a human to manually bridge the gap between design and implementation.

A designer creates something in Figma. A screenshot gets exported. The screenshot gets pasted into Cursor, Claude, OpenCode, Codex, or another coding agent. The model attempts to reconstruct what it sees. The developer fixes inconsistencies. The cycle repeats.

The entire workflow depends on moving information between systems that cannot directly communicate.

OpenDesign and OpenCode represent a fundamentally different approach.

Instead of treating design as a screenshot problem, they treat design as structured data. Instead of forcing an AI agent to infer your design system from images, OpenDesign exposes design systems, design tokens, component definitions, assets, skills, and project artifacts through a machine-readable interface.

When OpenCode is connected to OpenDesign through MCP, your coding agent no longer generates code from vague descriptions. It generates code from the source of truth.

The result is something much more interesting than another AI coding assistant.

It is the beginning of a local-first design and development operating system.

Table of Contents

• Understanding the Architecture
• The Missing Layer in AI Development
• OpenDesign as a Design Operating System
• Installing OpenDesign
• Installing OpenCode
• Method 1: Automated Skill-Based Installation
• Verifying Integration
• What od mcp install opencode Actually Does
• Installing Everything From Scratch
• Starting the Daemon
• MCP Wiring Reference
• Environment Variables
• Docker Deployment
• Building a Skill From Scratch
• Understanding MCP
• The Sovereign Design Stack
• Troubleshooting

Understanding the Architecture

Many developers initially misunderstand OpenDesign.

They assume it is another coding agent. It isn't.

Likewise, OpenCode is not a design tool.

The two systems solve different problems.

• OpenCode is an agent runtime.
• OpenDesign is a design orchestration layer.

Together they create a system where design knowledge becomes accessible to coding agents.

High-Level Architecture

┌──────────────────────────────────────────────────────┐
│                    OpenDesign Daemon                  │
│                                                      │
│  ┌──────────┐  ┌──────────┐  ┌───────────────────┐   │
│  │ Skills   │  │ Design   │  │ MCP Server        │   │
│  │ (259+)   │  │ Systems  │  │ (stdio-based)     │   │
│  └──────────┘  └──────────┘  └────────┬──────────┘   │
│                                        │              │
└────────────────────────────────────────┼──────────────┘
                                         │
                                         ▼
                              ┌─────────────────────┐
                              │     OpenCode CLI    │
                              │                     │
                              │  Coding Agent Loop  │
                              └──────────┬──────────┘
                                         │
                                         ▼
                              ┌─────────────────────┐
                              │      LLM Backend    │
                              │ OpenAI/Ollama/Qwen  │
                              │ Claude/Gemini/etc   │
                              └─────────────────────┘

The key insight is that OpenDesign does not attempt to replace your coding agent.

Instead, it acts as an adapter layer that augments existing coding agents with design intelligence.

What Each System Is Responsible For

OpenDesign's job:

• Manage design systems
• Manage skills
• Manage artifacts
• Manage project exports
• Expose MCP resources
• Discover supported coding agents
• Feed structured design context into those agents

OpenCode's job:

• Reason about tasks
• Execute tools
• Edit files
• Run commands
• Manage context windows
• Generate code

This separation of concerns is one of OpenDesign's most elegant design decisions. OpenDesign focuses on design. OpenCode focuses on execution.

The Missing Layer in AI Development

A coding agent understands:

• Source code
• Documentation
• Terminal output
• Configuration files
• Build systems

A coding agent does not inherently understand:

• Typography hierarchies
• Brand systems
• Color palettes
• Design tokens
• Layout conventions
• Visual identity

Historically developers solved this by embedding screenshots into prompts. That approach works, but it scales poorly. Screenshots become stale. Prompts become larger. Consistency becomes harder to maintain.

OpenDesign solves the problem by making design information queryable.

Interpretation vs. Retrieval

Instead of writing this in a prompt:

"Use the blue color from our design system."

The agent can retrieve structured data:

{
  "primary": "#0066FF"
}

Instead of describing spacing:

"Use the spacing system from our design docs."

The agent can retrieve:

{
  "spacing-sm": "8px",
  "spacing-md": "16px",
  "spacing-lg": "24px"
}

This distinction may seem minor. It is not.

• One approach relies on interpretation.
• The other relies on retrieval.

Retrieval scales. Interpretation eventually breaks.

OpenDesign as a Design Operating System

The best way to think about OpenDesign is not as a design tool. It is a design operating system.

Its core subsystems include:

1. Design Systems

OpenDesign ships with over one hundred production-grade design systems. These contain:

• Typography systems
• Color systems
• Accessibility standards
• Component libraries
• Layout rules
• Brand conventions

Rather than repeatedly prompting agents about these rules, OpenDesign stores them as reusable artifacts that any MCP-connected agent can query by name.

2. Skills

Skills are one of OpenDesign's most important concepts.

A skill is a reusable unit of expertise. Instead of prompting:

"Create a modern SaaS landing page using accessibility best practices and responsive layouts."

every single time, a skill already encodes that expertise.

A canonical skill on disk looks like this:

skill/
├── SKILL.md
├── assets/
└── references/

A skill can provide:

• Behavioral guidance
• Workflow instructions
• Design conventions
• Example assets
• Reference documentation

OpenDesign currently ships with hundreds of skills spanning:

• Prototyping
• Design systems
• Exports
• Slides
• Images
• Video generation
• Presentation workflows
• Component generation

The coding agent loads expertise instead of recreating it.

3. MCP Server

The MCP server is arguably OpenDesign's most important architectural component. It allows external agents to access OpenDesign resources as structured tools.

Rather than relying entirely on prompts, agents can directly query:

• Design systems
• Components
• Tokens
• Skills
• Assets
• Projects
• Exports

This creates a persistent communication channel between OpenDesign and the coding agent. Every interaction is tool-callable, inspectable, and reproducible.

4. Execution Adapters

OpenDesign intentionally avoids becoming tied to any single model vendor. Instead, it delegates execution to existing coding-agent CLIs.

Supported agents include:

• OpenCode
• Claude Code
• Codex
• Gemini CLI
• Cursor Agent
• GitHub Copilot CLI
• Qwen CLI
• Devin for Terminal
• DeepSeek TUI
• Mistral Vibe
• Kimi
• Hermes
• Pi
• Kiro
• Kilo
• Qoder CLI

…and many others.

This design decision matters.

OpenDesign does not care which model wins. It only cares about exposing design context.

Installing OpenDesign

The easiest installation method is through npm or pnpm.

Using pnpm (recommended)

pnpm add -g open-design

Using npm

npm install -g open-design

Runtime Requirements

• Node.js ~24
• pnpm 10.33.x

To ensure version consistency, enable Corepack and pin pnpm to the supported version:

corepack enable
corepack prepare pnpm@10.33.x --activate

If you previously installed open-design with a different package manager or version, remove it first to avoid path collisions:

npm uninstall -g open-design || true
pnpm remove -g open-design || true

You can confirm the binary is on your PATH with:

which od
od --version

Installing OpenCode

OpenCode must be available on your PATH.

Install Globally

npm install -g @anomalyco/opencode

Verify the Installation

opencode --version
which opencode

OpenDesign scans your PATH for supported coding agents. If OpenCode is discoverable, OpenDesign can use it as an execution engine.

If you would prefer to use a different agent (for example Claude Code or Codex), install that agent and OpenDesign will pick it up automatically during the next rescan.

Method 1: Automated Skill-Based Installation

The OpenDesign repository contains tooling specifically designed to automate agent integration.

Step 1 — Navigate to the OpenDesign package root

cd $(npm root -g)/open-design

This resolves to the global node_modules directory, regardless of which package manager installed the package.

Step 2 — Run the OpenCode integration skill

bash .claude/skills/od-contribute/install.sh opencode

You can substitute any supported agent name for opencode (for example claude, codex, gemini, cursor).

What the Installer Does

The installer performs several tasks:

1. Detects OpenCode on your PATH.
2. Locates executables (Node, OpenDesign, OpenCode).
3. Generates MCP configuration in the agent-specific format.
4. Writes agent-specific configuration to the correct location.
5. Verifies connectivity by spawning a short-lived MCP handshake.

This is the fastest path to a working installation.

Verifying Integration

Before applying any configuration, you can preview what the installer would write:

od mcp install --print opencode

This performs a dry run without modifying anything. It prints the exact JSON (or YAML, depending on the target agent) that would be written to disk.

Once satisfied, apply the configuration:

od mcp install opencode

OpenDesign now installs an MCP configuration that allows OpenCode to communicate directly with the daemon.

The coding agent can now query:

• CSS tokens
• Typography scales
• Components
• HTML entry pages
• Assets
• Projects

…directly from OpenDesign.

What od mcp install opencode Actually Does

Most guides stop here. The interesting part is understanding what happens under the hood.

When you execute:

od mcp install opencode

OpenDesign performs the following actions in order:

1. Locates the Node runtime that owns the global open-design package.
2. Locates the OpenDesign executable (od).
3. Generates an MCP configuration document describing how the agent should spawn the OpenDesign MCP server.
4. Creates an OpenCode-specific install script that registers the MCP server with OpenCode's config directory.
5. Embeds absolute executable paths so the agent can launch OpenDesign regardless of the user's working directory.
6. Writes the configuration into OpenCode's config location (typically ~/.config/opencode/ or platform equivalent).
7. Registers the MCP server so OpenCode lists it as an available tool provider.

Conceptually, the resulting data flow is:

OpenCode
    │
    ▼
MCP Configuration
    │
    ▼
OpenDesign CLI
    │
    ▼
OpenDesign Daemon
    │
    ▼
Projects
Skills
Assets
Design Systems

This is not merely a plugin. It is a persistent communication channel that survives across sessions, restarts, and model swaps.

Installing Everything From Scratch

For developers who want complete control, here is the manual route.

Step 1 — Clone the repository

git clone https://github.com/nexu-io/open-design.git
cd open-design

Step 2 — Install dependencies

pnpm install

If your environment disables lifecycle scripts (enable-pre-post-scripts=false in npm config, or the equivalent in pnpm), run the post-install hook manually:

node scripts/postinstall.mjs

This step is what populates the bundled design systems and skills. Skipping it leaves the daemon empty.

Step 3 — Build (optional, for production runs)

pnpm build

For development iteration you can skip the build and run directly with pnpm dev.

Starting the Daemon

Production mode

od start

Development mode (with hot reload)

pnpm dev

The daemon automatically scans your PATH for supported coding agents.

If OpenCode is not discovered, verify the install:

which opencode
opencode --version

Then trigger a manual rescan inside the OpenDesign UI under:

Settings → Execution Mode → Rescan

The daemon binds to http://localhost:7456 by default. Open the URL in a browser to access the design operating system UI.

MCP Wiring Reference

Preview the configuration

od mcp install --print opencode

Apply the configuration

od mcp install opencode

Available flags

Remove an integration

od mcp install --uninstall opencode

Multi-agent installations

You can run od mcp install once per supported agent. Each call writes a configuration specific to that agent's expected location and format. The same OpenDesign daemon serves every connected agent simultaneously.

od mcp install opencode
od mcp install claude
od mcp install codex
od mcp install gemini

Environment Variables

OpenDesign supports runtime configuration via environment variables. This is the right place to set secrets (API tokens), tune resource limits, and customize CORS behavior.

Common variables

export OPEN_DESIGN_PORT=7456
export OPEN_DESIGN_MEM_LIMIT=4096
export OPEN_DESIGN_ALLOWED_ORIGINS="http://localhost:7456"
export OPEN_DESIGN_IMAGE="registry.local/open-design:latest"
export OD_API_TOKEN=$(openssl rand -hex 32)

What each variable controls

Persist these in ~/.zshrc, ~/.bashrc, or a .env file loaded by your shell.

Docker Deployment

OpenDesign can run entirely through Docker. This is the recommended path for shared servers, CI runners, and remote development hosts.

Step 1 — Prepare the environment

cd deploy
cp .env.example .env

Step 2 — Generate an API token

openssl rand -hex 32

Step 3 — Configure the environment file

Open the new .env file and set at minimum:

OD_API_TOKEN=<paste-the-token-from-step-2>
OPEN_DESIGN_PORT=7456
OPEN_DESIGN_ALLOWED_ORIGINS=http://localhost:7456

You can also set a memory limit and any upstream model credentials the daemon should pass through to the agent:

OPEN_DESIGN_MEM_LIMIT=4096
OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...

Step 4 — Start the stack

docker compose up -d

The UI becomes available at:

http://localhost:7456

Data persists through Docker volumes. To inspect them:

docker volume ls | grep open-design
docker inspect <volume-name>

Step 5 — Connect OpenCode to the containerized daemon

When the daemon is running inside Docker, your local OpenCode install needs to know where to find it. Export the URL and token, then re-run the installer:

export OPEN_DESIGN_API_URL=http://localhost:7456
export OD_API_TOKEN=<generated-token>
od mcp install opencode

OpenCode will now speak to OpenDesign over HTTP rather than stdio. The token is forwarded as a bearer credential on every MCP request.

Step 6 — Tail the logs (optional)

docker compose logs -f open-design

This is invaluable when debugging token mismatches, missing design systems, or agent registration issues.

Updating the container

git -C open-design pull
docker compose pull
docker compose up -d

The persistent volume survives across image upgrades, so your design systems, skills, and project artifacts remain intact.

Building a Skill From Scratch

Skills are how you encode reusable design and engineering expertise. Once a skill is on disk and registered with OpenDesign, any connected coding agent can invoke it by name.

Minimal Skill Layout

my-skill/
├── SKILL.md
├── assets/
└── references/

SKILL.md Template

The frontmatter of SKILL.md declares metadata that OpenDesign and the agent use for routing:

---
name: responsive-card-generator
description: Generate responsive card components that respect the active design system
triggers:
  - card
  - responsive
  - component
  - pricing
---

# Responsive Card Generator

## When to use this skill

Invoke this skill whenever the user asks for a card, tile, or pricing block
that should adapt to small, medium, and large viewports while honoring the
active design tokens.

## Inputs

- `title` (string, required): the card heading
- `body` (string, optional): supporting copy
- `action` (object, optional): `{ label: string, href: string }`

## Procedure

1. Call `get_design_tokens()` to fetch the current spacing and color scale.
2. Render a container with `spacing-md` padding and `radius-md` corners.
3. Stack the title and body vertically with `spacing-sm` between them.
4. If `action` is provided, render a primary button at the bottom edge.

## Output

A self-contained HTML snippet wrapped in a `<div data-skill="responsive-card-generator">`
element so downstream code can identify and re-render it.

## Example assets

See `./assets/card-example.html` for a complete reference.

Registering the skill

Drop the directory into one of the recognized skill locations:

~/.config/open-design/skills/responsive-card-generator/

or pass it explicitly when starting the daemon:

od start --skill-path ~/projects/my-skills

OpenDesign scans skill directories on startup and on every UI-driven rescan. Once registered, the skill is exposed via MCP and is callable from any connected agent.

Invoking the skill from an agent

In OpenCode:

opencode
> Use responsive-card-generator to create a pricing card with title="Pro" and body="For growing teams."

The agent discovers the skill through MCP, reads SKILL.md, and follows the documented procedure using the design tokens that OpenDesign serves.

Skill authoring best practices

• Be deterministic. Encode exact tool calls and exact values, not vague guidance.
• Reference the MCP tools by name (get_design_tokens, list_components, get_skill).
• Keep assets small — the skill travels into the agent's context window.
• Version your skills with a version field in the frontmatter.
• Test in isolation before publishing. Run od skill lint <path> to validate the manifest.

Validating a skill

od skill lint ~/.config/open-design/skills/responsive-card-generator

The linter checks for:

• Valid frontmatter (required keys: name, description)
• No broken relative references in assets/ and references/
• No circular skill dependencies
• Reasonable SKILL.md length (warns beyond ~4,000 words)

Understanding MCP

MCP may ultimately become more important than any single AI model.

Historically AI systems communicated through prompts. Prompts are:

• Fragile
• Difficult to version
• Difficult to maintain

MCP enables structured retrieval.

Instead of:

"Use our design system."

Agents call:

get_design_tokens()

…and receive structured, typed data back.

Why retrieval beats interpretation

• Stable contracts. A tool signature does not drift between model versions.
• Inspectable. Every tool call is logged, replayable, and unit-testable.
• Cacheable. The same call returns the same data until the design system changes.
• Permissioned. MCP servers expose only the resources the agent should see.

Example MCP resources exposed by OpenDesign

The future increasingly belongs to retrieval rather than interpretation.

The Sovereign Design Stack

Perhaps the most interesting aspect of OpenDesign and OpenCode is that every layer can be self-hosted.

A complete stack might include:

• OpenCode — the agent runtime
• OpenDesign — the design orchestration daemon
• Ollama — local model server
• Qwen, Llama, DeepSeek — open-weight models
• SQLite — local persistence for projects and skills
• Docker — reproducible deployments
• Git — version control for everything
• MCP — the protocol that ties it all together

No SaaS requirement. No monthly subscriptions. No dependency on a specific AI vendor.

You own:

• The models
• The design systems
• The prompts
• The skills
• The infrastructure
• The deployment pipeline

This is the larger significance of OpenDesign.

It is not simply a design tool.

OpenCode is not simply a coding assistant.

Together they demonstrate a broader trend emerging throughout the AI ecosystem.

The industry spent the last decade centralizing infrastructure. The next decade may be defined by rebuilding local capability.

Design systems become machine-readable. Coding agents become interchangeable. Models become replaceable. Protocols become standardized.

The result is a future where your development environment survives the rise and fall of individual AI companies — because the intelligence resides in open systems, local infrastructure, and interoperable protocols rather than proprietary platforms.

OpenDesign and OpenCode offer one of the clearest examples of that future available today.

Troubleshooting

A field guide to the issues you are most likely to hit during your first installation.

od: command not found

The global node_modules bin directory is not on your PATH.

# npm
export PATH="$(npm config get prefix)/bin:$PATH"

# pnpm
export PATH="$(pnpm bin -g):$PATH"

Persist the export in your shell rc file.

opencode: command not found

Install OpenCode globally:

npm install -g @anomalyco/opencode

Then verify:

which opencode
opencode --version

OpenDesign is running but OpenCode does not list it as an MCP server

1. Run od mcp install --print opencode and confirm the printed config looks correct.
2. Re-run od mcp install opencode to (re)write the configuration.
3. Inside OpenCode, trigger an MCP rescan from its settings or restart the CLI.
4. Check that OD_API_TOKEN matches between the daemon environment and the agent configuration.

EADDRINUSE on port 7456

Another process is bound to the default port.

lsof -i :7456

Either stop the conflicting process, or change the port:

export OPEN_DESIGN_PORT=7600
od start

Remember to update OPEN_DESIGN_API_URL in your shell and re-run od mcp install for every connected agent.

Docker container starts but the UI is unreachable

• Confirm the container is running: docker compose ps
• Inspect the published port: docker compose port open-design 7456
• Verify the port mapping in docker-compose.yml exposes 7456 to the host.
• Check CORS: OPEN_DESIGN_ALLOWED_ORIGINS must include the URL you are loading the UI from.

Skills are missing after installation

If you skipped node scripts/postinstall.mjs during a from-source build, the bundled skills are absent. Re-run the post-install hook:

pnpm install
node scripts/postinstall.mjs

Then restart the daemon and rescan from Settings → Execution Mode → Rescan.

Agent produces code that ignores the design system

This almost always means the agent is not invoking MCP tools. Verify two things:

1. The MCP server is registered (od mcp list or the agent's own MCP inspector).
2. The system prompt encourages tool use. Some agents default to pure generation unless explicitly told to call tools.

A reliable workaround is to include a short system-prompt directive:

Before generating any UI, call get_design_tokens() and list_components() so
that the code you produce matches the active design system exactly.

Resetting everything

If you want a clean slate:

od mcp install --uninstall opencode
od stop
rm -rf ~/.config/open-design
od start
od mcp install opencode

This removes all local state, all generated MCP configurations, and all cached design systems, then re-installs from scratch.

OpenDesign repository: github.com/nexu-io/open-design OpenCode: @anomalyco/opencode Model Context Protocol: modelcontextprotocol.io

June 3, 2026

GitHub

There is a framing problem at the center of most AI discourse right now, and it is costing builders real clarity about what they are actually constructing.

The framing is this: the model is the product. Improve the model, improve the product. Benchmark higher, ship better. This framing is not wrong exactly — it is just incomplete in a way that leads to architecturally bad decisions when you are building anything that needs to operate continuously, maintain state, or work at the intersection of multiple information streams over time.

I want to articulate a different framing, one that has emerged from building Objective05 — a local-first intelligence system written in Rust — and from watching the gap between what AI systems could do and what they actually do in production widen in a very specific and correctable way.

The framing: the information architecture is the product. The model is a processing component.

What Gets Built When You Take the Wrong Frame

When you treat the model as the product, you build stateless interfaces. The pattern is familiar: user sends message, model generates response, context window closes, everything disappears. The intelligence exists only during the forward pass. Memory is a feature you bolt on later. Persistence is an afterthought. You end up with something that is very impressive in a demo and surprisingly brittle in any workflow that spans more than one session.

This is not a criticism of the models themselves. It is a criticism of the system design choices that treating the model as the product encourages.

The alternative is to ask a different question at the start of the design process. Not "which model should I use?" but "what information structure do I need to build, and which model operations are appropriate for enriching it?"

The moment you ask that question, the architecture changes completely.

Documents stop being terminal outputs and start being observations. An article is evidence that a claim existed at a particular time. A Reddit thread is evidence that a discussion occurred. A YouTube transcript is evidence that a statement was made. The system's job is not to summarize these artifacts — it is to understand how they relate to one another across time, and to maintain that understanding as a queryable, durable structure.

Temporal Knowledge Graphs as First-Class Infrastructure

The core data structure in Objective05 is a temporal knowledge graph backed by Kuzu DB. Every node carries valid_from and valid_to timestamps. Nothing is ever physically deleted — only logically superseded. This is not a nice-to-have. It is architecturally load-bearing.

Here is why: the interesting questions in an intelligence system are almost never "what is true right now?" They are "what did we know about X at time T?", "which claims appeared first?", "which sources have been consistent over time?", "when did this narrative start diverging from that one?" These questions are unanswerable in a system that treats information as a current-state snapshot rather than an evolving temporal structure.

The academic literature on this — event mining, temporal graph analysis, information diffusion, dynamic graph networks — has been building toward exactly this insight for years. The practical implementation has lagged because it is genuinely hard to build correctly and because the stateless chatbot interface was an easier thing to ship. But the gap between what temporal graph systems can answer and what current AI products can answer is enormous, and it is not going to close by making the model bigger.

In Objective05, every piece of extracted information flows through a pipeline that transforms documents into claims, claims into entities, entities into relationships, relationships into events, events into narratives, and narratives into evolving models of reality. The graph is not a database bolted onto an LLM. The graph is the primary artifact. The LLM is one of several components that enrich it.

The Architecture That Makes Local Models Actually Interesting

There is a conversation that happens constantly in the local AI community about whether local models can "compete" with frontier models. This is the wrong question, and asking it reflects the model-as-product framing.

The right question is: what can a local model do that a frontier model cannot, by virtue of its physical proximity to the data?

A local model can run continuously against a local graph. It can classify claims as they arrive. It can extract entities from a document at 2am without an API call. It can maintain persistent memory because the memory is just a file on disk. It can detect when two sources are making contradictory claims about the same entity without sending either claim anywhere. It can run a maintenance cycle at 3am that transitions stale events to archived status without anyone noticing.

This is not a consolation prize for not having GPT-4 access. This is a qualitatively different capability. The value proposition of a local model is not raw intelligence. It is continuous operation against owned infrastructure.

In Objective05, the heuristic extraction service — which is deterministic pattern matching, not even an LLM — can already extract entities, claims, and relationships from documents and feed them into the event engine, which uses weighted similarity scoring to decide whether a new claim merges into an existing event or creates a new one. The correlation engine running on this infrastructure, without any frontier model involvement, produces derived events with importance scores, participating entity lists, claim counts, and lifecycle status. This is genuinely useful intelligence output.

When you eventually drop a capable local model into this infrastructure — which is the next phase — it does not replace the pipeline. It enriches it. The model gets called when the heuristic approach hits its ceiling: complex entity resolution, implied contradiction detection, narrative labeling, report generation. Everything else runs without it.

The Event Engine as a Case Study in Representation Over Generation

The correlation engine in Objective05 — specifically the EventEngine — illustrates the core principle clearly enough that it is worth examining in detail.

When a new claim arrives, the engine computes a similarity score against every existing event that still accepts claims. The score is a weighted combination of entity overlap, location match, predicate overlap, and temporal proximity. If the best match exceeds a threshold (currently 0.7), the claim merges into the existing event. If not, a new event is created.

This sounds simple. It is doing something important.

The engine is maintaining a deduplicated, importance-scored, temporally-indexed model of what is happening in the world as perceived by the configured information sources. Two different RSS feeds reporting on the same Apple earnings announcement do not create two events. They create one event with a claim count of two and a source diversity score that reflects the corroboration. A third independent source mentioning the same entities and predicates raises the confidence further. The event's importance score is a function of evidence volume, source diversity, and recency — not the subjective judgment of any single summarization call.

The graph becomes self-correcting over time in a way that a stateless summarization system never can. Old events transition to Stable and then Archived. New claims update existing events rather than creating duplicate coverage. Contradictory claims — two sources reporting different numbers for the same metric — surface as contradiction nodes rather than getting silently averaged away.

The contradiction detection is particularly interesting from a systems perspective. Rather than asking a model "is claim A consistent with claim B?", the engine first uses deterministic heuristics to identify candidate pairs (same subject, same predicate, significantly different object values), and only calls the more expensive evaluation for pairs that pass the initial filter. This is the right architecture for a continuously-running system: cheap operations filter the space, expensive operations resolve the hard cases.

On the Political Economy of What Gets Built

There is a dimension to this that is not purely technical, and I want to be explicit about it.

The AI industry has strong structural incentives to emphasize model capabilities over information architecture. Benchmark scores are legible and comparable. Context windows are a number that can go up. Model APIs are a product you can sell subscriptions to. None of these things require the end user to own anything. The intelligence lives on someone else's server. The memory belongs to the platform. The knowledge graph, if it exists, is theirs.

Local-first, persistence-first, architecture-first approaches produce systems where the user owns the intelligence infrastructure. The graph is a file on their disk. The events and narratives and contradictions belong to them. They can back it up, export it, query it, or delete it without asking anyone. This is harder to monetize as a subscription service, which is why it gets less attention than it deserves.

I think this is a civilizational-scale design choice masquerading as a technical preference. We are early enough in the development of AI-augmented cognition that the architectural decisions being made now — where memory lives, who owns derived knowledge, whether intelligence infrastructure is rented or owned — will compound in significant ways over the next decade.

Objective05 is explicitly a bet that owned intelligence infrastructure is both technically achievable and worth building, even when the cloud path is faster to a demo.

What the Rust Implementation Teaches

Building this in Rust with a Cargo workspace was the correct call, and not primarily for the reasons usually cited (memory safety, performance). The more important benefit has been the trait-stable interface boundaries that the Rust type system enforces.

The DocumentRepository, ExtractionRepository, EventRepository, GraphRepository, and VectorRepository traits define the service boundaries cleanly. The in-memory implementations that power the current MVP are behind the same interfaces as the eventual Kuzu, LanceDB, and NATS implementations. This means the integration tests exercise the documented contract, not the implementation detail. When the persistent backends replace the stubs, the tests do not change.

This matters for a continuously-running system because it makes the replacement of components safe. The RuntimeStore wraps a DocumentArchive (gzip-compressed JSON files partitioned by year and month) and an in-memory extraction store. The extraction store will eventually be the Kuzu graph. The document archive will stay as gzip files because it is the right storage format for that data. Neither change requires touching the service layer.

The scheduler service deserves specific mention because it demonstrates something about the right architecture for periodic intelligence work. The SchedulerService emits typed events onto the message bus when jobs are due. The pipeline worker consumes those events and dispatches to ingestion, extraction, correlation, or maintenance functions. The scheduler does not call the pipeline directly. The pipeline does not know about the schedule. Both can be tested in isolation. Both can fail independently without taking the other down.

This is the event-driven architecture doing its job: the coupling that would make a monolithic intelligence system brittle is replaced by message passing that makes each component independently survivable.

The Broadcast Layer as the Overlooked Endpoint

Most discussions of AI information systems focus on the retrieval end — how do you get information into a query-answerable form. The broadcast end — how does the system proactively communicate what it has learned — gets less attention, even though it is arguably the more important interface for a system designed to run continuously without user input.

The broadcast engine in Objective05 is designed around a principle that sounds obvious but has significant implications: the system should never stop producing output. Even when no new information has arrived in 24 hours, the broadcast engine runs. It produces idle content — deep dives on tracked entities, summaries of unresolved contradictions, narrative context for ongoing events. The intelligence is not reactive. It is perpetual.

This is a different user model than the chatbot paradigm. The user does not ask questions. The system tells them things. The user's job is to configure what the system should pay attention to and to consume the output when it appears. The system's job is to never stop working.

The audio broadcast subsystem — Piper TTS for voice generation, multi-voice podcast assembly, MP3 archival — extends this into a format that requires zero interface engagement to consume. The system becomes a local radio station. You do not need to open a dashboard to stay informed. You need only listen.

Remaining Work and Where This Points

Objective05 is currently in pre-alpha. The heuristic extraction service will be replaced by a local LLM runtime when the llama.cpp integration lands. The in-memory stubs for Kuzu and LanceDB will be replaced by the real persistent backends. The dashboard is not yet built. The broadcast generation and audio pipeline exist in documentation form but not code.

What is built and working: the full ingestion pipeline across eleven source adapter types, the heuristic extraction service, the event engine with merge and lifecycle management, the file-backed event repository, the scheduler with cron parsing and state persistence, the snapshot and retry queue services, the API gateway with OpenAPI documentation, and a comprehensive test suite that exercises the documented interfaces end-to-end.

The architecture described in the documentation and partially instantiated in the code represents, I think, a convergent point for what local AI intelligence infrastructure should look like: temporal graph as primary data structure, event-driven pipeline with durable queues, model as enrichment component rather than system core, owned data with full export capability, continuous operation rather than request-response.

The question of whether this matters depends on whether you believe intelligence infrastructure should be owned or rented. I believe it should be owned. The system exists to test that belief against the reality of implementation.

The model is not the product. The memory is the product. The graph is the product. The architecture that lets you ask "what did we know about this entity three weeks ago, and how did that knowledge evolve?" — that is the product.

Everything else is a processing step.

Objective05 source: github.com/kliewerdaniel/objective05 Previous writing on this project: danielkliewer.com/2026-06-01-objective03-local-news-agency

objective03: A Locally-Run Autonomous News Ingestion and Contradiction Tracking System

Architecture Overview: From RSS Feeds to Audio Broadcasts on Consumer Hardware

objective03 is a Python daemon that performs autonomous news ingestion, atomic claim extraction, entity resolution, event clustering, contradiction detection, narrative analysis, and text-to-speech broadcast — all running on local hardware via llama.cpp (Metal GPU backend), KuzuDB (embedded temporal property graph), Qdrant (vector similarity search), and Qwen3-TTS (mlx_audio). The system ingests content from RSS feeds, Reddit subreddits, and YouTube channels, extracts structured factual claims with GBNF-enforced JSON schemas, detects typed contradictions across sources, clusters claims into events and narrative threads, and generates TTS-optimized audio broadcasts with voice cloning and procedural ambient audio. Zero cloud dependencies. Zero API calls.

Pipeline Architecture

The system operates as a five-group task scheduler running on independent intervals. Each group contains a sequence of subprocesses with configurable timeouts, failure limits, and circuit-breakers.

Task Group 1: Ingestion (default interval: 60s)

The ingestion module polls three source types:

• RSS feeds — HTTP GET with If-None-Match / ETag support for conditional requests. Parsed via feedparser. Documents normalized (HTML stripped, Unicode NFKC normalized, whitespace collapsed).
• Reddit subreddits — OAuth2 authenticated API calls. Posts and comments extracted, metadata preserved (author, subreddit, upvotes, timestamps).
• YouTube channels — yt-dlp for metadata extraction and audio transcription. Channel upload schedules polled on configurable intervals.

All documents undergo SHA-256 deduplication before graph insertion. The normalized document is stored as a Document node in KuzuDB with a FROM_SOURCE edge pointing to the originating Source node.

Task Group 2: Analysis Pipeline (default interval: 120s)

This is the core processing pipeline, executing sequentially:

2a. Claim Extraction

Each document is chunked and passed to a local LLM (llama.cpp, Metal backend). The model extracts atomic factual claims using a GBNF-defined grammar that enforces a strict JSON schema:

{
  "claim": "string",
  "confidence": "float (0.0-1.0)",
  "stance": "positive | negative | neutral",
  "topic": "string (tag)",
  "evidence": "string (verbatim text span)"
}

GBNF grammar enforcement ensures the model's output is structurally valid — no schema drift, no optional fields appearing as required. Each claim node in KuzuDB carries a confidence property and an EXTRACTED_FROM edge to its source document.

2b. Entity Resolution

A second local LLM call extracts named entities (PERSON, ORG, LOC, EVENT) from each document. Extracted entities are resolved against existing graph nodes via:

1. Exact match on entity name
2. Fuzzy matching using Levenshtein distance with configurable threshold
3. Alias tracking — multiple names resolved to the same entity node over time

Resolved entities receive a MENTIONS edge to the source document and an APPEARS_IN edge to any event nodes they participate in.

2c. Event Clustering

Claims are assigned to events based on entity overlap. The algorithm:

1. Extracts all entities from the new claim
2. Queries the graph for existing event nodes connected to any of those entities
3. If matches found, the claim's ABOUT_EVENT edge points to the existing event
4. If no matches, a new Event node is created with emerging status

Events track:

• importance_score — computed from entity frequency, claim count, and temporal recency
• status — emerging -> active -> resolved
• temporal_start / temporal_end — bounded by earliest and latest claim timestamps

2d. Contradiction Detection

New claims are embedded using BGE-Small-EN-v1.5 (384-dimensional) and indexed in Qdrant. For each new claim:

1. Vector search — cosine similarity query against the Qdrant collection. Candidates with similarity > 0.75 are returned.
2. LLM classification — each candidate pair is passed to the local LLM with a prompt template that classifies the relationship into one of five typed categories:

Contradictions are persisted as CONTRADICTS edges between claim nodes with a type property. Contradictions are never auto-resolved — the system preserves the raw disagreement for downstream consumption.

2e. Narrative Analysis

Claims not assigned to events (i.e., no entity overlap with existing event nodes) are grouped into narrative threads via embedding cosine similarity clustering (>0.75 threshold). Each cluster receives an LLM-generated label. Active narratives track:

• drift_score — semantic shift over time within the narrative
• framing_classification — dominant narrative frame (e.g., "economic," "political," "social")

2f. Source Reliability Scoring

Each Source node accumulates a reliability score based on historical claim accuracy — measured by the frequency of that source's claims being contradicted by other sources. Sources that consistently produce contradictory claims see their reliability scores degrade over time.

2g. Graph Update

All extracted nodes and edges are committed to KuzuDB in a single transaction per batch.

Task Group 3: Broadcast Generation (default interval: 90s)

A local LLM queries the KuzuDB graph via Cypher-like queries for:

• Top N events by importance_score
• Unresolved contradictions (all CONTRADICTS edges with no resolution)
• Active narratives (narratives with status == "active")
• System metrics (sources ingested, claims extracted, contradictions detected)

The LLM produces an 800–1200 word broadcast script optimized for TTS. The script uses <think> blocks for internal reasoning before the spoken output. The prompt template includes structural directives: opening summary, top events, contradiction deep-dives, narrative shifts, and closing metrics.

Task Group 4: Audio Production (default interval: 90s)

The broadcast script undergoes preprocessing:

1. Chunking — split into ~100-word segments
2. Abbreviation expansion — "U.S." -> "United States", "Dr." -> "Doctor"
3. Number normalization — "3.5%" -> "three and a half percent", "$500M" -> "five hundred million dollars"
4. Date formatting — "Jan 15, 2026" -> "January fifteenth, twenty twenty-six"
5. Punctuation normalization — ellipses, em-dashes, and other TTS-sensitive characters

Preprocessed segments are synthesized via Qwen3-TTS using mlx_audio. Voice cloning is supported via reference audio input. Synthesized audio segments are crossfaded at boundaries and queued for playback via afplay on macOS.

Task Group 5: Maintenance (default interval: 24h)

• Memory consolidation — low-importance events and old narratives pruned based on importance_score thresholds
• Graph evaluation — sample of claims re-verified against source documents for accuracy metrics
• Embedding index rebuild — Qdrant index refreshed with all current claim embeddings

Storage Architecture