Memory and Context Engineering

The first two parts dealt with two questions: how the model works, and how an agent moves from "talking" to "doing." But there has been one problem we kept setting aside — the model does not remember.

Yesterday you spent a full day teaching it your project layout, your code conventions, your stack choices. You open a new session today and everything is gone. It did not "forget" — it was never holding on in the first place. Every inference is a stateless pure function. The moment the context window closes, every piece of information inside it disappears. This is not a flaw in some product; it is a basic property of the model architecture itself.

So engineers built memory systems on top of it — session memory, project memory, global memory — external persistent storage that gets selectively injected back into the context on each call. But context is not free. Every token has a cost: in money, in latency, and in attention dilution. Stuffing everything into the context is not the answer. It is just a new problem.

How do you make every token in a finite window earn its place? That is the question context engineering has to answer. And when the knowledge the model needs simply isn't in its training data — your company's internal frameworks, your team's private codebase, the actual project sitting in front of you — how does the model get to it? The answer used to be: build a knowledge base, retrieve, inject. In the code scenario, that pipeline already breaks. The job stops being injecting knowledge and becomes making knowledge reachable — letting the model walk into the codebase itself, using the primitives the codebase already exposes.

The three chapters in this part — from "how to make the AI remember" to "how to manage context cost" to "how the model gets to the knowledge it needs" — are all answering the same underlying question. The model's knowledge and memory are bounded. Within that bound, how do engineers build a working information supply system around it?