{"course":{"slug":"context-engineering","title":"Context Engineering","url":"https://addaly.com/learn/context-engineering","level":"advanced","track":"build"},"lesson":{"slug":"the-four-kinds-of-context","title":"Four kinds of context, four different problems","url":"https://addaly.com/learn/context-engineering/the-four-kinds-of-context","position":3,"of":87,"minutes":8,"answer":"Sort every token in the window into instructions, exemplars, knowledge or state: the four differ in half-life, trust, cache behaviour and failure mode, and almost every layout decision follows from which kind a block is.","keyIdea":"Sort every token in the window into instructions, exemplars, knowledge or state: the four differ in half-life, trust, cache behaviour and failure mode, and almost every layout decision follows from which kind a block is."},"body":{"format":"markdown","text":"## Sorting the window by what it is for\n\nEverything you put in a context window belongs to one of four kinds. The kinds matter because each has a different half-life, a different trust level, a different cache behaviour, and a different thing that goes wrong with it. Mixing them up is the most common structural mistake in a system that has grown past its first version.\n\n### 1. Instructions: what the system is\n\nThe role, the constraints, the refusal policy, the output contract, the tone. Written by you, changed on a deploy, identical for every user.\n\n- **Half-life:** weeks.\n- **Trust:** full. You wrote it.\n- **Cache:** perfect, if you put it first and never interpolate anything variable into it.\n- **Failure mode:** growth. Instructions accrete. Every incident adds a sentence, and nobody ever deletes one. A 300-token system prompt becomes 2,400 tokens of contradictory rules over eighteen months, and the contradictions are invisible because nobody reads it end to end.\n\n### 2. Exemplars: what a good answer looks like\n\nFew-shot examples, formatting demonstrations, a worked case.\n\n- **Half-life:** months, but they rot silently when the task drifts.\n- **Trust:** full, unless somebody pasted a real customer's message into one, which happens more often than teams admit.\n- **Cache:** perfect, if they sit with the instructions rather than being selected per request.\n- **Failure mode:** they are expensive per unit of behaviour bought. Four examples at 250 tokens each is 1,000 tokens on every call forever. Sometimes one sentence of instruction does the same job.\n\n### 3. Knowledge: what is true that the model does not know\n\nRetrieved passages, an uploaded document, the row from your database, today's price.\n\n- **Half-life:** one request. It is chosen for this question.\n- **Trust:** varies, and this is the important part. Your own product documentation is trusted. A PDF a stranger uploaded is not. Both arrive in the same field.\n- **Cache:** poor by construction, since it changes per request. Anything you cache here you cache for a segment of users, not all.\n- **Failure mode:** wrong selection, and it is invisible from the answer. The model produces a confident, well-formed reply based on the four passages you gave it and never mentions the fifth passage you did not.\n\n### 4. State: what has happened so far\n\nConversation history, tool results, the agent's scratchpad, the user's profile, the current step of a workflow.\n\n- **Half-life:** minutes, and growing.\n- **Trust:** mixed and often mislabelled. A tool result is data from a system; the model's own previous output is a guess it made; a user's earlier message is user input. Teams routinely treat all three as equally reliable because they arrive in the same message list.\n- **Cache:** good in the middle, because history is append-only, until you compact it, at which point the whole suffix invalidates.\n- **Failure mode:** unbounded growth. A tool that returns 30,000 tokens of JSON on turn three is a design bug that surfaces as a cost bug on turn nine.\n\n## The fifth thing, which is not context\n\nOutput reserve. The window is shared between what you send and what comes back. On most APIs the limit you hit is the sum, and `max_tokens` is subtracted from the space available for input. Budget it first, not last: decide the answer needs 800 tokens, subtract it, and spend what remains.\n\nThis is the single most common cause of the error message that reads like a lie: a request that is comfortably under the context limit and still fails, because the requested completion length did not fit alongside it.\n\n## Why the sorting is useful\n\nOnce material is sorted, three decisions become mechanical instead of arguable.\n\n**Order.** Stable before variable, because caching matches from the first token forward. Instructions and exemplars are stable; knowledge and state are not. That single rule decides most of your prefix layout, and it is covered properly in its own lesson.\n\n**Trust.** Instructions and exemplars are yours. Knowledge and state largely are not. The boundary between them is where your defences go, and it is a boundary you can draw on a diagram only if the four kinds are separated in the code that builds the request.\n\n**What to cut when it does not fit.** State compacts. Knowledge is re-ranked and truncated. Exemplars can be reduced from four to two and measured. Instructions are the last thing you touch, because they are the only part guaranteeing that the output is usable at all. Most naive truncation does exactly the opposite: it drops from the front, which is where the instructions live.\n\n## The audit worth doing today\n\nTake one real production request. Print each of the four kinds with a token count beside it. Teams doing this for the first time usually find one of three things: tool definitions costing more than the instructions, a history that nobody has ever capped, or retrieved passages making up two thirds of the window while the retrieval quality has never been measured on its own.\n\nAll three are fixable this week. None of them is visible from the model's output."},"check":{"question":"A request is 12,000 tokens against a 16,000-token limit, and the API rejects it. `max_tokens` is set to 6,000. Why?","options":[{"text":"The limit applies to input and output together, so 12,000 plus a 6,000-token reserve exceeds 16,000.","correct":true},{"text":"The tool definitions are being counted twice, once in the schema and once in the serialised prompt.","correct":false,"tempting":"Invents a double-count; tool definitions are serialised once, and their cost is real but singular."},{"text":"The request exceeded the model's effective context even though it is under the advertised one, and the API enforces the effective limit.","correct":false,"tempting":"Confuses a quality degradation, which is real and unenforced, with a hard API limit, which is arithmetic on the declared numbers."},{"text":"History has not been compacted, and uncompacted history is charged at a higher rate against the window than other blocks.","correct":false,"tempting":"Assumes tokens are weighted by origin; every token counts once regardless of which of the four kinds it belongs to."}]},"prev":{"slug":"what-context-engineering-is","title":"Nobody typed this","url":"https://addaly.com/learn/context-engineering/what-context-engineering-is"},"next":{"slug":"anatomy-of-a-request","title":"What the model literally receives","url":"https://addaly.com/learn/context-engineering/anatomy-of-a-request"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Four kinds of context, four different problems', in Context Engineering. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/context-engineering/the-four-kinds-of-context (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Four kinds of context, four different problems","courseTitle":"Context Engineering","module":{"index":1,"slug":"the-window-as-a-surface","title":"The window as an engineering surface"},"answer":null,"keyIdea":"Sort every token in the window into instructions, exemplars, knowledge or state: the four differ in half-life, trust, cache behaviour and failure mode, and almost every layout decision follows from which kind a block is.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"sorting-the-window-by-what-it-is-for","runs":[{"text":"Sorting the window by what it is for"}]},{"t":"p","runs":[{"text":"Everything you put in a context window belongs to one of four kinds. The kinds matter because each has a different half-life, a different trust level, a different cache behaviour, and a different thing that goes wrong with it. Mixing them up is the most common structural mistake in a system that has grown past its first version."}]},{"t":"h3","id":"1-instructions-what-the-system-is","runs":[{"text":"1. Instructions: what the system is"}]},{"t":"p","runs":[{"text":"The role, the constraints, the refusal policy, the output contract, the tone. Written by you, changed on a deploy, identical for every user."}]},{"t":"ul","items":[[{"text":"Half-life:","b":true},{"text":" weeks."}],[{"text":"Trust:","b":true},{"text":" full. You wrote it."}],[{"text":"Cache:","b":true},{"text":" perfect, if you put it first and never interpolate anything variable into it."}],[{"text":"Failure mode:","b":true},{"text":" growth. Instructions accrete. Every incident adds a sentence, and nobody ever deletes one. A 300-token system prompt becomes 2,400 tokens of contradictory rules over eighteen months, and the contradictions are invisible because nobody reads it end to end."}]]},{"t":"h3","id":"2-exemplars-what-a-good-answer-looks-like","runs":[{"text":"2. Exemplars: what a good answer looks like"}]},{"t":"p","runs":[{"text":"Few-shot examples, formatting demonstrations, a worked case."}]},{"t":"ul","items":[[{"text":"Half-life:","b":true},{"text":" months, but they rot silently when the task drifts."}],[{"text":"Trust:","b":true},{"text":" full, unless somebody pasted a real customer’s message into one, which happens more often than teams admit."}],[{"text":"Cache:","b":true},{"text":" perfect, if they sit with the instructions rather than being selected per request."}],[{"text":"Failure mode:","b":true},{"text":" they are expensive per unit of behaviour bought. Four examples at 250 tokens each is 1,000 tokens on every call forever. Sometimes one sentence of instruction does the same job."}]]},{"t":"h3","id":"3-knowledge-what-is-true-that-the-model-does-not-know","runs":[{"text":"3. Knowledge: what is true that the model does not know"}]},{"t":"p","runs":[{"text":"Retrieved passages, an uploaded document, the row from your database, today’s price."}]},{"t":"ul","items":[[{"text":"Half-life:","b":true},{"text":" one request. It is chosen for this question."}],[{"text":"Trust:","b":true},{"text":" varies, and this is the important part. Your own product documentation is trusted. A PDF a stranger uploaded is not. Both arrive in the same field."}],[{"text":"Cache:","b":true},{"text":" poor by construction, since it changes per request. Anything you cache here you cache for a segment of users, not all."}],[{"text":"Failure mode:","b":true},{"text":" wrong selection, and it is invisible from the answer. The model produces a confident, well-formed reply based on the four passages you gave it and never mentions the fifth passage you did not."}]]},{"t":"h3","id":"4-state-what-has-happened-so-far","runs":[{"text":"4. State: what has happened so far"}]},{"t":"p","runs":[{"text":"Conversation history, tool results, the agent’s scratchpad, the user’s profile, the current step of a workflow."}]},{"t":"ul","items":[[{"text":"Half-life:","b":true},{"text":" minutes, and growing."}],[{"text":"Trust:","b":true},{"text":" mixed and often mislabelled. A tool result is data from a system; the model’s own previous output is a guess it made; a user’s earlier message is user input. Teams routinely treat all three as equally reliable because they arrive in the same message list."}],[{"text":"Cache:","b":true},{"text":" good in the middle, because history is append-only, until you compact it, at which point the whole suffix invalidates."}],[{"text":"Failure mode:","b":true},{"text":" unbounded growth. A tool that returns 30,000 tokens of JSON on turn three is a design bug that surfaces as a cost bug on turn nine."}]]},{"t":"h2","id":"the-fifth-thing-which-is-not-context","runs":[{"text":"The fifth thing, which is not context"}]},{"t":"p","runs":[{"text":"Output reserve. The window is shared between what you send and what comes back. On most APIs the limit you hit is the sum, and "},{"text":"max_tokens","code":true},{"text":" is subtracted from the space available for input. Budget it first, not last: decide the answer needs 800 tokens, subtract it, and spend what remains."}]},{"t":"p","runs":[{"text":"This is the single most common cause of the error message that reads like a lie: a request that is comfortably under the context limit and still fails, because the requested completion length did not fit alongside it."}]},{"t":"h2","id":"why-the-sorting-is-useful","runs":[{"text":"Why the sorting is useful"}]},{"t":"p","runs":[{"text":"Once material is sorted, three decisions become mechanical instead of arguable."}]},{"t":"p","runs":[{"text":"Order.","b":true},{"text":" Stable before variable, because caching matches from the first token forward. Instructions and exemplars are stable; knowledge and state are not. That single rule decides most of your prefix layout, and it is covered properly in its own lesson."}]},{"t":"p","runs":[{"text":"Trust.","b":true},{"text":" Instructions and exemplars are yours. Knowledge and state largely are not. The boundary between them is where your defences go, and it is a boundary you can draw on a diagram only if the four kinds are separated in the code that builds the request."}]},{"t":"p","runs":[{"text":"What to cut when it does not fit.","b":true},{"text":" State compacts. Knowledge is re-ranked and truncated. Exemplars can be reduced from four to two and measured. Instructions are the last thing you touch, because they are the only part guaranteeing that the output is usable at all. Most naive truncation does exactly the opposite: it drops from the front, which is where the instructions live."}]},{"t":"h2","id":"the-audit-worth-doing-today","runs":[{"text":"The audit worth doing today"}]},{"t":"p","runs":[{"text":"Take one real production request. Print each of the four kinds with a token count beside it. Teams doing this for the first time usually find one of three things: tool definitions costing more than the instructions, a history that nobody has ever capped, or retrieved passages making up two thirds of the window while the retrieval quality has never been measured on its own."}]},{"t":"p","runs":[{"text":"All three are fixable this week. None of them is visible from the model’s output."}]}],"check":{"question":[{"text":"A request is 12,000 tokens against a 16,000-token limit, and the API rejects it. "},{"text":"max_tokens","code":true},{"text":" is set to 6,000. Why?"}],"options":[{"text":[{"text":"The limit applies to input and output together, so 12,000 plus a 6,000-token reserve exceeds 16,000."}],"correct":true,"tempting":null},{"text":[{"text":"The tool definitions are being counted twice, once in the schema and once in the serialised prompt."}],"correct":false,"tempting":[{"text":"Invents a double-count; tool definitions are serialised once, and their cost is real but singular."}]},{"text":[{"text":"The request exceeded the model’s effective context even though it is under the advertised one, and the API enforces the effective limit."}],"correct":false,"tempting":[{"text":"Confuses a quality degradation, which is real and unenforced, with a hard API limit, which is arithmetic on the declared numbers."}]},{"text":[{"text":"History has not been compacted, and uncompacted history is charged at a higher rate against the window than other blocks."}],"correct":false,"tempting":[{"text":"Assumes tokens are weighted by origin; every token counts once regardless of which of the four kinds it belongs to."}]}],"order":[1,2,0,3],"why":null},"prev":{"slug":"what-context-engineering-is","title":"Nobody typed this","minutes":9},"next":{"slug":"anatomy-of-a-request","title":"What the model literally receives","minutes":10}}}