The Model Is a Stateless Function

The agent that impressed you yesterday remembers nothing about yesterday. On Tuesday you corrected it — we use NodaTime here, not DateTime maths — and it apologised and fixed the code. On Wednesday, fresh session, it made the same mistake again, because Tuesday's correction lived in Tuesday's conversation and Tuesday's conversation no longer exists. In part 2 I argued the prompt is the smallest and least durable layer of the system; this part is about the model underneath, and the single mental shift that makes the whole of context engineering fall into place.

Input tokens in, output tokens out

Here is the entire mental model, written as a signature:

// The whole thing. No class, no fields, no cache.
Token[] Model(Token[] contextWindow);

An LLM call is a stateless function. Tokens in, tokens out. There is no hidden state carried between calls, no persistent understanding of you or your project, no accumulation of insight across turns beyond what is explicitly present in the window this time. Call it twice with the same input and you get draws from the same distribution; change nothing but one token of input and the output can change; change nothing at all except what you failed to include, and the model cannot know what you left out.

This lands strangely at first, because working with an agent feels like working with something that learns. It picks up your conventions mid-session. It refers back to decisions from an hour ago. It seems to know things. But every one of those effects has the same mechanical explanation: the tokens are still in the window. The convention it “picked up” is sitting in the message history, re-read on every call. The decision it “remembers” is forty turns up the transcript, re-sent with every request. The learning is an illusion produced by re-reading, and the illusion evaporates at exactly the boundary of the window — which is why Wednesday's agent knows nothing about Tuesday.

Every turn of an agent loop — choosing a tool, writing a file, answering a question — has many plausible next steps and many wrong ones, and the only thing that determines which path the model takes is the content of the window at that moment. Not what it saw last week. Not what you meant. What is in the window, now.

Where “memory” actually lives

Once the function is pure, everything that looks like memory must be explainable as input. It is, and cataloguing the inputs is worth a minute because the catalogue is the terrain the next three parts operate on. What the model sees on a given call is some assembly of:

• System prompts and instruction files — the persistent behavioural frame, injected at session start
• Tool definitions — what the model believes it can do
• Retrieved documents — files it has read, search results, anything pulled in on demand
• Message history — the prior turns, tool calls and results, replayed each call
• Memory contents — notes persisted across sessions and read back in

That last one deserves emphasis, because “the agent has memory” is the claim that most often smuggles the wrong mental model back in. Memory features, in every implementation I have used, are just writing: somewhere, a process took tokens out of one window and wrote them to a file or a store, and some later process read them back into another window. The agent that greets Wednesday knowing about Tuesday's NodaTime correction knows it because a file was written and re-read — because someone, human or machine, did context engineering. Nothing persists unless something writes it down and something else reads it back in. The entire discipline is downstream of that sentence.

The same logic dissolves the mystery of why agents behave so differently in different repositories with identical prompts. It is not mood. The repository is input — the instruction files it carries, the code the agent reads, the conventions visible in that code. Change the repository, and you have changed the argument to the function.

Six days in June

The discipline had been practised before it had a name. Through the first half of 2025, practitioners building production agents — Dex Horthy's 12-factor agents work from that April prominent among them — were already talking about owning the context window as the core engineering act. What the idea lacked was a banner.

It got one on 19 June 2025, when Shopify's CEO Tobi Lütke posted: “I really like the term ‘context engineering’ over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.” Six days later, on 25 June, Andrej Karpathy added his endorsement — his post opens with a “+1” for context engineering over prompt engineering — and supplied the definition the field still quotes: “context engineering is the delicate art and science of filling the context window with just the right information for the next step.”

The chronology is worth keeping straight, because retellings often reverse it: Lütke first, Karpathy seconding him days later. And the two posts are worth reading as a pair, because they carve the discipline along exactly the seam this series follows. Lütke's framing — plausibly solvable — is the completeness test: is everything the task needs actually in the window? Karpathy's — just the right information for the next step — is the precision test: is anything in the window that should not be? Provide everything necessary; include nothing that is not. Most of context engineering is the tension between those two sentences.

A CPU and its RAM

Karpathy also supplied the analogy I reach for whenever the stateless-function framing feels too austere. In his Software 3.0 talk he describes the LLM as a new kind of operating system — the model as a CPU, the context window as its RAM, the working memory that is the only thing the processor can actually see. The analogy is his, and it earns its keep because it imports thirty years of engineering instinct in one move. Nobody expects a CPU to remember the last program. Nobody blames the processor when the working set was never loaded. And nobody — this is the instinct that matters most — treats RAM as free.

Anthropic's engineering guide on effective context engineering states the constraint plainly: “Context is a critical but finite resource for AI agents.” Finite is the operative word. The window is not a bucket you fill; it is a budget you spend, and every token you spend on one thing is a token unavailable for another. Later in the series we will see that the budget degrades before it exhausts — quality falls off well before the window is technically full — but even at this altitude the consequence is clear: what goes into the window is a set of decisions, and if you are not making them, they are being made anyway, by defaults, by tooling, and by accumulation.

What statelessness changes in practice

Three habits fall straight out of the mental model, and they are the ones I drill first.

Write it down or lose it. Anything that should survive the session — a correction, a decision, a convention — must leave the conversation and land in an artefact something will read back in. Saying it to the agent is not teaching; it is spending.

Restart instead of accumulating. When a session goes wrong, the wreckage stays in the window and becomes input. A history full of failed attempts and corrections tells the function that failed attempts are what this conversation produces. A fresh window with a clean statement of what is now known beats a long transcript of how painfully you got there.

Treat every window as designed input. Not “what did I tell it” but “what does it see” — the full assembly: instructions, tools, files, history, memory. That inventory, once you start taking it, is rarely flattering. It is also exactly where the leverage is.

You do not train your agent. You furnish its room, every morning, from scratch — and the furnishing turns out to have a well-mapped taxonomy. Next, the first two of its four pillars: write and select.