Context engineering
What goes into the prompt, and what gets left out. It became a named discipline once context windows grew large enough that the limit stopped being capacity and started being attention — a model given 200,000 tokens does not use them evenly.
| # | File | Covers |
|---|---|---|
| 01 | Context engineering | the budget, what earns its place, ordering |
| 02 | Memory Strategies for LLM Conversations and Agents | the memory taxonomy and seven strategies |
The two answers worth having
More context is not better context. Retrieval quality beats retrieval quantity: models lose information in the middle of a long window, so fewer, better-ranked chunks outperform stuffing the top fifty. The stable content also belongs first, because that is what provider prompt caching matches on.
Memory is a policy, not a store. The transcript is the full record; memory is the decision about how much of it the model sees on this turn. Working memory is this conversation, episodic is what persists per user, semantic is the shared knowledge base — and a rolling summary is what keeps the first bounded once the raw history stops fitting.
Why it exists as a topic
The API is stateless, so every turn resends the history and you pay for all of it. That single fact generates the whole discipline: summarisation, sliding windows, retrieval-backed memory and context budgets are all answers to a cost and attention problem that does not exist in a stateful system.
See The chat API surface for the mechanism, and Context windows for what happens inside the window.