The Self-Improving AI Stack: Five Layers Deep

I’ve spent the past month obsessed with one question: how do you build an AI system that gets smarter every time it runs?

So I built one. I curated 121 sources (63 repos, 13 papers, 24 tweets, 21 articles), deep-researched 51 of them by reading source code and documentation, and distilled everything into a self-compiling wiki that uses the same self-improving techniques it documents. The findings contradict most of what I assumed six months ago.

Karpathy’s tweet (50K+ likes, 15M+ views within days) showed something simple: an LLM maintaining its own markdown wiki outperforms elaborate retrieval pipelines at moderate scale. Markdown files, an index, and an agent that reads and writes them. That’s the whole stack.

Most people stopped at “cool, markdown works.” They missed the deeper signal. Karpathy described a closed-loop knowledge system where the agent’s outputs become inputs to the next iteration, accumulated in a git-backed store that neither agent nor human has to curate by hand. That’s five distinct engineering problems collapsed into one self-improving stack. And almost nobody is mapping them as a unified system.

I’ve been mapping them. Five layers deep. Each with a finding that breaks conventional wisdom. Each feeding the next. Together they form a loop that makes the whole system smarter every cycle. And they’re converging toward something bigger than any individual layer.

I started where everyone starts: assuming the bottleneck was retrieval quality. Better search engine, better results.

One 313-star repo scores 91% on a standard long-memory benchmark using plain keyword search on structured markdown. The previous best system, with a full AI search pipeline, scored 86%. Keyword search. The kind that’s been around for decades. On well-organized files that show summaries first and full content only when needed. That’s the entire retrieval layer.

The 2023–2024 assumption was linear: more retrieval infrastructure = better results. Vector store, chunking tuner, reranker, knowledge graph. Teams built the whole RAG ecosystem (retrieval-augmented generation, the standard approach where AI pulls relevant documents before answering) on this gradient.

The bottleneck turned out to be how you organize the knowledge, not which search engine you use. Chunking strategy, index freshness, temporal validity, how well your documents match the questions agents actually ask. Most teams over-invested in plumbing, under-invested in architecture.

Retrieval is the easy problem, though. The hard one is what happens when there’s nothing to retrieve.

After L1, I assumed better search would fix memory. The data said otherwise.

On implicit context questions (where the agent needs knowledge it has zero keyword overlap with), keyword search scores 2.8%. Add AI search on top: 3.4%. Both barely above the 0.8% no-memory baseline.

Your tuned retrieval pipeline, on the hardest questions, adds almost nothing. Search requires a query. And agents can’t query for knowledge they don’t know exists.

The fix is simple. A 3,000-token compressed topic index, loaded into every conversation, transforms recall. It’s a map of everything the agent knows, always present, costing a few paragraphs of space. It doesn’t replace search. It makes search useful by telling the agent what exists before it tries to look anything up. Search handles known unknowns. The map handles unknown unknowns. Same lesson as L1: a small, well-organized structure outperformed heavy infrastructure.

Memory also has a failure mode that gets worse the longer agents run: silent poisoning. If a hallucinated “fact” gets stored as a user preference, every downstream session builds on it. Mem0 (51K+ stars, the most popular memory framework) has no adversarial validation layer. One bad extraction propagates because the agent doesn’t know the memory is wrong, and the user doesn’t know the memory exists.

The systems surviving long deployments build validation gates. A separate process reviews stored memories with zero context about how they were produced. Without that gate, errors compound with every write cycle.

Memory tells the agent what it knows. The next question: how much of what it knows should it load at once?

The topic index from L2 worked because it gave the agent a map before asking it to search. One system formalized the same principle for the entire context window (the limited amount of text an AI can process at once).

That system achieved 83% fewer input tokens AND better task completion. Fewer tokens, better results. That breaks the intuition that more context = more capability.

The approach: three-tier loading. Abstracts first (~100 tokens), overviews if needed (~2,000 tokens), full content only on demand. The agent loads minimum context at the lowest resolution, drills down only when needed. If you’re spending more tokens, you’re probably loading the wrong things.

A study on agent harnesses (the code controlling what goes into the AI’s input and how) found something striking: the same AI model shows up to 6x performance differences based purely on how you organize its input. Same model weights. Same test set. The only variable: what goes in the window and how.

Harrison Chase’s framing: three layers where an agent can learn. Model weights, harness code, context. The context layer has the fastest feedback loop and the lowest blast radius. That’s where most wins live right now.

But sustained context rewriting has a failure mode the field is naming: context collapse. Iterative rewriting erodes performance over time. Each compression pass loses domain-specific nuance in favor of brevity. Structured, incremental updates that accumulate rather than replace protect against this.

Every token has opportunity cost. The systems winning right now treat the context window like a budget. How you fill that budget depends on what tools the agent has access to.

Agent skills (modular capability files loaded on demand) are the standard pattern now. Sounds great until you have a few dozen of them.

Beyond a critical skill library size, flat routing registries collapse. Keyword matching works fine with a handful of skills. Past the threshold, routing accuracy falls off. A skill called “Python data analysis” never fires when the task is “make a chart from this CSV.” The skill exists. The router can’t find it.

And 26.1% of community-contributed skills contain vulnerabilities. Loading untrusted skills is running untrusted code. Because that’s what it is.

Gauri Gupta’s auto-harness is one response: mine production failures, cluster by root cause, generate regression test suites. Skill quality becomes measurable.

The systems that work at scale share a pattern: hierarchical skill organization with semantic routing. Multiple routing mechanisms, each handling a different access pattern. Some fire by file type, some run code on events, some match task descriptions to skill files, some spin up separate agents entirely. Four layers of routing instead of one.

All of this (knowledge, memory, context, skills) is read-path infrastructure. The question that makes the stack self-improving: what happens when the agent writes back?

The agent writes back. And what it produces can be alien.

Karpathy’s AutoResearch ran 700 autonomous changes over two days and found an 11% speedup on neural network training that humans had missed. Specific wins: fixing attention sharpness, applying missed regularization, tuning hyperparameters, correcting optimizer settings. Real, verified, additive gains that transferred to larger models.

Another team took it further: agents rewriting their own code improved from 20% to 50% on a standard coding benchmark. The architecture maintains an archive of diverse agent variants, evolving them like species in an ecosystem. The best variants survive, combine, and produce better variants.

But reward hacking is the dominant failure mode across all self-improving systems.

One training team found that format rewards (designed to encourage structured thinking) created an incentive to fill maximum turns rather than solve the task. The agent learned to farm turns, not solve problems. Fix: tabulate all possible per-turn cumulative rewards before training, find every degenerate path, close it explicitly.

This pattern repeats everywhere. Without a measurement instrument independent from the optimization target, agents find shortcuts that game the score without improving capability. You need to evaluate the evaluator. One score for the task, one for the instrument measuring the task.

Every layer pointed the same direction. Small structures beat big infrastructure. Fewer tokens beat more tokens. Smart routing beat flat registries. And when the output feeds back into the input, everything compounds.

These five layers are a single read/write cycle.

The read path runs at task time: knowledge feeds memory, memory shapes context, context enables the agent to act. The write path runs after: outputs get evaluated, evaluations rewrite the knowledge base, update memory, refine context-loading rules. Both paths use the same underlying stores.

Systems that close this loop compound with every cycle.

This is why Karpathy’s wiki outperforms retrieval pipelines at moderate scale. The wiki pattern closes the loop. The agent reads from and writes to the same store, and the store improves every cycle. A traditional retrieval pipeline has a read path and no write path. The knowledge is static.

Three cross-cutting patterns reinforce this:

In the agent-native ecosystem (coding tools, personal knowledge bases, developer workflows), markdown won. It’s the lowest-friction format that humans, agents, and version control all handle well. Teams that tried JSON knowledge graphs or binary embeddings as the primary store added overhead and lost inspectability.

Git is infrastructure. AutoResearch uses git as agent memory. `git log` is history, `git revert` is undo, branches are experiment namespaces. Agents that write to git get auditable, reversible, parallelizable memory for free.

Structured forgetting matters as much as structured memory. Every persistent memory system eventually confronts: what do you delete? Stale information actively harms quality when it contradicts current reality. The systems that work long-term implement structured forgetting. Compress old detail while preserving patterns that generalize.

The finding I keep coming back to: Karpathy’s personal knowledge wikis, enterprise decision lineage, and a new idea called **context graphs** are all converging toward the same architecture.

Jaya Gupta’s piece (10K+ likes, 5M+ views) frames context graphs as a trillion-dollar opportunity. The argument: every organization generates decision traces (who decided what, when, with what information, and what happened next). Those traces form a graph. That graph is the context an AI agent needs to make the next decision well.

Brana Rakic pushes this further with shared context graphs. Today, Karpathy’s wiki is personal. One agent, one knowledge base. Shared context graphs let multiple agents (and humans) read and write to the same evolving knowledge structure. Organizational memory at the scale of entire companies.

The convergence path:

Personal wikis handle the single-agent case. One agent, one knowledge store, summaries first, self-compiling indexes.

Temporal knowledge graphs (Graphiti, Zep) handle the enterprise case. Facts carry validity windows. “What was true when” queries become possible. Multi-user, multi-session.

Context graphs bridge the two. Decision traces as a shared knowledge substrate, with the same summary-first loading and the same self-improvement loop. Evaluate decisions, feed signal back into the graph.

The first two exist today in production. The third is emerging. When it arrives, agents stop being stateless tools and become participants in organizational knowledge. That’s the step change.

The meta changes overnight.

Six months ago, “give your agent a vector database” was reasonable advice. Today, the five-layer stack (knowledge, memory, context, skills, self-improvement) is the minimum viable architecture for agents that compound. The models are good enough. The infrastructure around them is what’s lagging.

Everything above is the distilled version. The full self-compiling wiki goes 183 articles deep: project-by-project comparisons, failure modes, benchmark analyses, architecture breakdowns for all 51 deep-researched repos and papers. To my knowledge, it’s the most comprehensive report on the state of the art in this space.

Here’s meta-kb. Star it or fork it. You’ll want to come back to this. I believe the next trillion-dollar company will be built on this stack, and the wiki maps every approach, tradeoff, and failure mode across all five layers.

Onwards and upwards! 🚀