# Agentic AI Stack

> The layers between a model and the real world: the tools an agent can reach, what it remembers, the loop that drives it, and the runtime it executes in. The model is the commodity now; almost everything that decides whether an agent works in production lives in the layers around it.

## Model and gateway

The frontier models have converged: several of them produce work good enough to build on, so the choice stops being a benchmark score and becomes tool-use reliability over a long horizon. A gateway in front of them handles routing, fallback, and cost, so a run is not pinned to one provider staying up. Reaching for a bigger model rarely fixes a failing agent; the fault is almost always a layer below.

## Tools and integrations

This is where the agent acts on anything outside its own text: files, a shell, a browser, an API, a database. MCP has settled in as the common protocol for wiring those tools to an agent, so a capability written once can be spoken to by any client. The lesson holds hardest here: every tool added widens the space of ways a run can go wrong, so the win is a small, sharp toolset rather than every integration on offer.

## Memory and knowledge

A single turn holds everything in its context window and forgets it at the end. Memory is what carries state across steps, sessions, and users: a scratchpad the run writes to, a store it reads back, retrieval over a corpus the model was never trained on. Get this layer wrong and no larger model saves you, because the agent is reasoning carefully over the wrong context.

## Orchestration

The loop that drives the whole thing: the model reasons, takes an action, reads the result, and goes again until the work is done or a bound stops it. Frameworks live at this layer, but they are scaffolding, not the point. The bounds that keep a loop from running forever are their own subject in [Loop engineering](/garden/loop-engineering). Where this loop runs is the next layer down, and it decides whether the loop survives at all.

## Runtime and execution

Where a turn actually executes, and how it stays isolated from the next. This is the layer that went from an afterthought to real infrastructure fastest, because an agent that writes and runs its own code has to be treated as hostile: a shared-kernel container is too thin a wall around arbitrary code. Isolation has moved past plain containers toward microVMs and user-space kernels, so a run's blast radius is a disposable box rather than the host. In practice my own work happens inside a dev container, described in [Agentic Engineering](/garden/agentic-engineering): the agent runs as a non-root user with only the repository mounted and credentials kept outside it.

### Durable schedules

A turn is not the unit of real work; a task is. Durable, resumable schedules are what let a long task survive the process that started it, so a crash, a timeout, or a closed session picks up where it left off instead of starting from nothing. This is why where the loop runs is a property of the stack underneath, not of the loop itself.

## Observability, evals, and guardrails

These are less a layer than rails running the height of the stack, because they touch every layer. Observability makes a run legible after the fact; evals decide whether a change actually helped, measured on a real distribution of tasks rather than a demo; guardrails screen an action before it takes effect, not just the text going in and out. The verification habit from [What I learned experimenting with OpenClaw for analyst workflows](/garden/openclaw-analyst-workflows) is the same instinct one level up: a second, skeptical pass catches what the first one talked itself into.

## Not the model-serving stack

One distinction worth keeping: this stack is not the model-serving stack. GPUs, batching, and inference routing sit below it and serve tokens; everything here sits above the model and governs what it does with the world. So when an agent fails, the useful first move is to find the failing layer, not to swap in a bigger model.