There’s a name worth introducing for what I’ve been circling around for the past several posts. The thing that’s emerged in the agent era — the architecture that replaces the model-and-prompt of 2023 — needs a noun. Calling it “the harness” is too narrow; the harness is just the runtime component. Calling it “the agent” is too narrow; agents are processes that run on this thing. What we have now is broader than either of those, and it deserves a name that captures what’s actually distinctive about it.
The phrase I keep returning to is the large procedural substrate: the layered system of skills, runtimes, memory hierarchies, verification loops, and environments inside which a reasoning model operates. The model is embedded in it the way a CPU is embedded in a computer — necessary, central, but not the system.
The substrate is what we’re actually building and shipping.
Everything else in the agent era follows from this shift in unit of analysis.
Procedures live outside the model now
The word “procedural” matters. The substrate’s defining property is that it encodes procedures — sequences of action, recipes for tasks, patterns of operation — externally to the model. This is the inverse of the prompt era, in which all procedures lived in the model’s context as instructions, and the inverse of the pure fine-tuning era that briefly competed with it, in which procedures were baked into model weights. The substrate keeps procedures outside the model, in artifacts (skills, scripts, runbooks) that can be authored, versioned, audited, and reused independently of the model. The model is the executor; the procedures are the program.
The word “substrate” matters too. A substrate is what something else grows or operates on. The model grows behaviors on this substrate; the substrate is the soil. A different substrate would produce different behaviors from the same model. A better substrate makes a given model dramatically more capable. This is the framing that lets you make sense of phenomena like “the same model performs vastly better inside Claude Code than in a chat window” — the model didn’t change; the substrate did.
Five layers, each doing distinct work
The substrate has, in my reading, five primary layers, each doing distinct work.
1. Skills. The unit of procedural knowledge. A skill is a packaged procedure — a description of when it applies, what it does, what inputs and outputs it has — that can be loaded into the model’s context only when relevant. The skill library is what an organization’s procedural knowledge actually looks like once externalized from the prompt. This is where institutional know-how lives now.
2. Runtimes. The harness machinery from earlier in this series: the loop, the context manager, the tool dispatcher, the permission system, the execution environment. Runtimes are the OS of the substrate. They don’t know what the agent is doing; they provide the primitives that let any agent do anything.
3. Memory systems. Stratified memory — working memory in context, episodic memory across trajectories, semantic memory about persistent entities. The memory layer is where state lives, and the question of “what should the model remember between turns, and how” turns out to be one of the hardest unsolved problems in the substrate. Most of the differentiation between mature agents in 2026 is in this layer.
4. Verification loops. Procedures that check whether procedures worked. Test runners for coding agents. Schema validators for data agents. Re-readers and self-critics for content agents. Programmatic checks that operate outside the model’s reasoning, providing ground truth that the model cannot bluff its way around. These loops are how the substrate detects and recovers from failure.
5. Environments. The world the agent actually operates in. The filesystem, the browser, the database, the third-party APIs, the MCP servers. Environments are where actions actually happen and where consequences actually accumulate. The environment is the part of the substrate that connects the model’s procedural execution to the actual world; without environments, the model is computing in a void.
The layers are unusually intertwined
The interesting thing about these five layers is how much they interact. A good skill assumes a runtime with progressive disclosure, a memory system that can persist its outputs, a verification loop that can validate them, and an environment in which its actions make sense. Layered systems always have this property — TCP assumes IP, HTTP assumes TCP — but the substrate’s layers are unusually intertwined. You can’t really build a great skill library without a good runtime, and you can’t build a good runtime without thinking about what skills it will host.
This is why teams building seriously in this space have stopped specializing in “the model layer” or “the prompt layer” and started specializing in “the substrate.” The substrate is the unit of competence. You can hire a model specialist, but unless they also understand runtimes and memory and verification, they can’t ship anything useful. The shape of a hireable AI engineer has shifted accordingly. The pure prompt engineer has aged out of the job market. The pure ML engineer is over-qualified for the substrate’s middle layers and under-qualified for its breadth. The role that’s emerging — call it “agent engineer,” “AI systems engineer,” whatever — is fundamentally about working across the whole substrate, treating the model as one component among several.
The architecture of the next decade
I want to make a stronger claim about the procedural substrate than just “it’s the architecture we’re using now.” I think it’s the architecture of the next decade or more of AI applications, in the same way that the relational database was the architecture of business software for thirty years after Codd. The reason isn’t that it’s the only possible design. It’s that it’s the design that solves the actual problem we have: how to build reliable, auditable, composable systems on top of a probabilistic component. The substrate’s layered structure, with procedures externalized and verification loops in place, is what allows us to ship things that work in production despite the model’s stochasticity. As long as that property remains — and there’s no sign it’s going away — the substrate is the answer.
What changes, of course, is which components inside the substrate matter most. The model might shrink in relative importance as the substrate matures. New layers might emerge — observability is starting to look like it deserves its own layer. The boundaries between memory and runtime might shift. The substrate is a living architecture, not a frozen one. But the basic move — model embedded in a procedural environment, with intelligence distributed across the system rather than concentrated in any single component — is the durable shape.
The remaining posts in this series work through consequences of this view. Trajectory as interface. Behavioral evaluations. Context engineering as the new design discipline. The death of full autonomy. Each is downstream of the substrate concept, and each makes more sense once you’ve internalized that the substrate, not the model, is what we’re really building.