Concept

Context Engineering

The discipline that replaced 'prompt engineering': curating everything in the window — instructions, retrieval, tools, memory — as one budget.

Context engineering is deciding what deserves to be in the window for THIS call: system instructions, few-shot examples, retrieved documents, tool definitions, conversation history, scratchpad state. It's a budget-allocation problem. More context is not better — models attend unevenly (middles get lost), irrelevant text actively degrades answers, and every token costs latency and money. The craft is maximal signal, minimal filler.

Long-running sessions rot: history accumulates, stale tool results linger, and the model starts referencing things that no longer matter. The standard treatments are compaction (summarize older turns into a compact state note, keep recent turns verbatim), structured memory (pull durable facts out of chat history into a store you inject selectively), and just-in-time retrieval (fetch documents when a step needs them instead of front-loading everything 'to be safe'). Front-loading is the most common beginner mistake in agent design.

Treat context assembly as code with tests, because it is: a function from (user state, task) → window contents. Log the assembled context for every production call — when quality regresses, the diff of what the model actually saw explains more failures than the model itself. Most 'the model got dumber' reports are context-assembly regressions: a retriever change, a history-trim bug, one new tool description shoving out the examples that carried quality.

Check your understanding
Q1. An agent performs worse after you add ten more tools with verbose descriptions. Why?
Q2. What's compaction in a long-running agent session?
· Score 100% on the quiz.