Stop Waiting for the Next Model: The Real AI Gains Are in Memory and Skills

You are getting excited about every new foundational model release. You shouldn’t be. The biggest gains in enterprise AI aren’t coming from the next GPT, Claude, or Gemini. They are sitting right in front of you, waiting to be unlocked through the LLM Wiki, the Router, and recursive self-improvement.

The tech industry is addicted to the model release cycle. Every few months, a new foundational model drops, promising a few percentage points of improvement on benchmark tests. Executives and product teams scramble to integrate it, convinced that this is the release that will finally deliver the promised super-intelligence to their organisation.

It won’t.

If you are waiting for the model to solve your enterprise AI problems, you are fundamentally misunderstanding how AI creates value in a business context. The model is just an engine. An engine is useless without fuel (data), a transmission (skills), and a steering wheel (context).

The harsh reality of enterprise AI transformation in 2026 is this: the model is almost irrelevant if your organisational brain is broken.

The companies that are actually achieving massive productivity gains with enterprise AI agents — the ones building true organisational intelligence — aren’t doing it by swapping APIs every time OpenAI or Anthropic makes an announcement. They are doing it by building robust, opinionated AI agent infrastructure. They are focusing on the unsexy, high-impact work of denormalisation, hybrid re-ranking, the Router, and skill registries.

Here is why you need to stop obsessing over the model and start building the Brain.

The Illusion of the “Smart” Model

A foundational model, out of the box, is a very smart amnesiac. It has read the entire internet, but it knows absolutely nothing about your business. It doesn’t know your customers, your financial workflows, your product architecture, or your internal jargon.

When an employee asks a base model a question, the model is forced to guess, hallucinate, or provide generic advice. This is the “copilot” era of AI, and it is a dead end for enterprise transformation. It creates a ceiling on productivity because the human is still required to provide all the context, every single time.

The unlock is not a smarter amnesiac. The unlock is giving the amnesiac an AI agent memory system and a set of tools.

The Infrastructure of Organisational Intelligence

If you want to build AI agents for business that actually work, you have to build the infrastructure that surrounds the model. This infrastructure consists of several non-negotiable layers, and across the industry, standard naming conventions are already emerging to define them.

1. The Brain: Karpathy’s LLM Wiki and Denormalisation

Your organisation’s data is likely scattered across dozens of SaaS applications: CRMs, ERPs, ticketing systems, and wikis. To an AI agent, this is a nightmare.

The first step in building the Brain is denormalisation. You must extract your data from its silos and place it into a unified format optimised for agent retrieval.

This concept was best articulated by Andrej Karpathy as the LLM Wiki. Most people use AI by uploading raw documents and asking the AI to retrieve chunks at query time (basic RAG). Karpathy argues this is flawed because the AI has to rediscover knowledge from scratch every time.

Instead, the AI should incrementally build and maintain a persistent wiki — a structured, interlinked collection of markdown files. When new data arrives, the AI doesn’t just index it; it reads it, extracts the facts, updates entity pages, and flags contradictions. The knowledge is compiled once and kept current. This is the modern equivalent of Google’s Bigtable moment — creating a massive, flattened data structure designed not for human readability, but for machine parsing.

When your agent has access to a properly indexed, denormalised, and re-ranked AI agent memory layer, it stops guessing. It starts answering.

2. The Global Context Layer: AGENTS.md and CLAUDE.md

Once you have the data, you need to provide the agent with standing orders — the permanent context that dictates how it should behave in your specific environment. This discipline is what the industry is starting to call context engineering: it goes well beyond writing a clever one-off prompt, because it’s about the standing infrastructure that shapes every future prompt, automatically.

Across different agent harnesses, this global context layer takes specific file formats:

AGENTS.md: The emerging universal standard maintained by the Agentic AI Foundation. Supported by Claude Code, Cursor, GitHub Copilot, Windsurf, and others, this file lives in your project root and contains the universal instructions, build steps, and conventions that any agent needs to know.
CLAUDE.md: Claude Code’s specific memory file. It reads this at the start of every session. It supports @imports to recursively pull in other documentation files without bloating the main context window.
.cursorrules / .cursor/rules/: Cursor’s native format for providing granular, sometimes auto-attached context to the coding agent.
GEMINI.md: The equivalent context file for the Gemini CLI.

Without these files, you suffer from “context rot.” You are forced to re-explain your project structure and coding conventions in every single session. With them, the agent behaves like a veteran employee from day one.

3. The End of Deterministic Software Wrapping AI

For the last few years, the standard approach to building AI applications has been “deterministic software wrapping AI.” Engineers write half a million lines of rigid Ruby on Rails code, and somewhere deep inside that monolith, they make an API call to an LLM.

This is entirely backward.

The future is AI agents wrapping deterministic tools.

Instead of writing a massive, rigid application, you write small, deterministic tools (like a script that queries a database or hits a Stripe API). You then give those tools to an AI agent. The agent handles the logic and the user intent. This leads to what is now being called “Just-in-Time Software” — software that doesn’t exist as a rigid monolith, but is dynamically assembled by an agent at the exact moment the user needs it, using Markdown and TypeScript rather than rigid frameworks.

4. Skills and the Router (DRY + MECE)

A model with memory is a librarian. A model with skills is a worker.

A “skill” is a codified set of instructions that tells the agent how to execute a specific task. In Claude Code and other platforms, these are often defined in individual SKILL.md files (with YAML frontmatter) stored in a central .claude/skills/ registry — what people are increasingly calling Claude Code skills, and an emerging ecosystem of agent skills marketplaces is already forming around the same idea.

But as your organisation adds hundreds of skills, you run into a new problem: agent confusion. If you have ten different skills that all vaguely relate to “managing calendar invites,” the agent won’t know which one to pick.

This is where the Router comes in.

The Router (often implemented as an agents.md index or a RESOLVER.md routing table) is the directory for your agent’s Brain. It looks at the user’s request and maps it to the exact right SKILL.md or tool. To build an optimal Router, you must apply two rigorous principles — the closest thing this emerging space has to an agent skills standard:

DRY (Don’t Repeat Yourself): You should never have multiple skills that do the same thing.
MECE (Mutually Exclusive, Collectively Exhaustive): Your skills must cover every possible action without overlapping.

When an employee creates a new workflow, they run a “Check Resolvable” meta-skill. This checks the new skill against the existing Router table to ensure it is DRY and MECE. If it passes, it becomes a permanent part of the organisation’s Brain.

5. Task-Based LLM Routing

If you have built the Brain and the Router, you no longer need to rely on a single, expensive foundational model for every task. You can implement task-based LLM routing.

Not all prompts are created equal. Some need deep reasoning, others just need speed. An intelligent model router evaluates the incoming task and directs it to the most appropriate model:

Background maintenance and formatting: Routed to fast, cheap models like GPT-3.5 or Gemini Flash.
Complex reasoning and code generation: Routed to premium models like Claude Sonnet or GPT-4o.
Creative writing: Routed to models with specific stylistic strengths.

By routing traffic to different models based on the task type, you drastically reduce latency and API costs while maintaining top-tier performance where it actually matters.

Recursive Self-Improvement

This is where the magic happens. When you shift your focus from the model to the infrastructure, you unlock the ability to create recursive self-improvement loops.

Imagine a system where every interaction between an employee and an agent is logged. Overnight, a separate agent reviews these logs. It identifies where the primary agent failed, where context was missing, or where a skill was poorly defined. The system then rewrites the SKILL.md file or updates the MEMORY.md context retrieval parameters.

The system improves its own capacity to improve. It gets smarter every day, entirely independent of whether a new foundational model has been released. This is how super intelligence happens inside an organisation. It is a compounding flywheel of codified human expertise.

Stop Chasing, Start Building

The obsession with foundational models is a distraction. It allows leaders to feel like they are “doing AI” simply by paying for API access, while avoiding the hard, structural work required to actually transform their business.

You cannot just let AI “create a bunch of Markdown files” and call it a strategy. The biggest gains in AI are available right now, today, using the models that already exist. But those gains require you to build the Brain: the Karpathy LLM Wiki, the AGENTS.md context layers, the Router, the Just-in-Time software approach, and task-based LLM routing.

If you build the Brain, the model is just a plug-and-play component. If you don’t build the Brain, no model in the world will save you.

Answer Engine Optimisation (AEO) FAQ

What is the difference between an AI model and AI infrastructure?

An AI model (like GPT or Claude) is the reasoning engine. AI infrastructure includes the denormalised memory (the Brain), context files (AGENTS.md, CLAUDE.md), the Router, and skill registries (SKILL.md) that surround the model. The infrastructure is what makes the model useful in an enterprise context.

What is Andrej Karpathy’s LLM Wiki concept?

Andrej Karpathy’s LLM Wiki is a pattern for AI agent memory. Instead of retrieving chunks from raw documents at query time (basic RAG), the AI incrementally builds and maintains a persistent, structured markdown wiki. The AI reads new sources, extracts facts, and updates entity pages, creating a compounding knowledge base.

What are AI agent skills?

An AI agent skill is a codified, reusable set of instructions — typically a SKILL.md file with YAML frontmatter — that tells an agent exactly how to execute one specific task. Skills are stored in a shared registry, are reused across a team rather than rebuilt per session, and are increasingly discovered through emerging agent skills marketplaces rather than written from scratch every time.

What is task-based LLM routing?

Task-based LLM routing is the practice of directing an incoming prompt to the most suitable AI model based on the specific task. Simple tasks (like formatting) are routed to fast, cheap models, while complex reasoning tasks are routed to premium models, optimising both cost and performance.

What is recursive self-improvement in AI agents?

Recursive self-improvement is when an AI system improves its own capacity to improve. In an enterprise context, this involves an agent reviewing its own interaction logs, identifying failures or missing context, and automatically rewriting its own SKILL.md or MEMORY.md files to perform better in the future.

What is the Router in AI agent architecture?

The Router (often an agents.md or RESOLVER.md file) is the directory for an AI agent’s Brain. It maps a user’s natural language request to the specific, deterministic tool or SKILL.md file required to complete the task. An optimal Router ensures all skills are Mutually Exclusive and Collectively Exhaustive (MECE).

References

Mehta, K. (2026). Andrej Karpathy explained the mental model most agent builders are missing. X (formerly Twitter).
Karpathy, A. (2026). llm-wiki. GitHub Gist.
Agentic AI Foundation. (2026). AGENTS.md: A simple, open format for guiding coding agents.
Perrone, P. (2026). The Complete Guide to AI Agent Memory Files (CLAUDE.md, AGENTS.md, and Beyond). HackerNoon.
Sambharia, S. (2026). Introducing Skills Registry. Portkey Blog.
Shah, D. (2025). Task-Based LLM Routing: Optimizing LLM Performance for the Right Job. Portkey Blog.
Anthropic. (n.d.). When AI builds itself. Anthropic Institute.