Context engineering: what belongs in the window.

AI practice did not move through three clean eras. People still write prompts, curate context and build larger systems around both. But a three-layer history is a useful working model: first we concentrated on how to ask, then on what evidence to place beside the question, and now on the operating system that coordinates the work.

The middle layer is context engineering. It is the deliberate selection, ordering and maintenance of the material a model receives for a task. That includes instructions, source documents, examples, tool results and prior decisions. Its hardest question is not how much information you can load. It is which information deserves the model's attention now.

A prompt tells the model what job it is doing, which constraints matter and what form the answer should take. That remains important. Yet a precise instruction cannot supply facts it does not contain. “Explain why the forecast changed” is a clear request, but the answer will still be weak if the model receives an old forecast, conflicting definitions or no record of the latest pricing decision.

Context is the evidence and working state placed around that instruction. Once models became more capable at following ordinary language, many failures that looked like prompt problems were better diagnosed as evidence problems: missing records, stale records, contradictory sources or too much unrelated material competing with the useful parts.

Suppose the task is to explain a changed quarterly forecast and draft the decision note. The available folder contains last year's board deck, a current CRM export, three pricing policies, meeting notes and a finance memo approved yesterday. Loading the entire folder feels safe. It also puts obsolete and authoritative material side by side without telling the model which should win.

I use four filters. Relevance: does this item bear directly on the forecast? Freshness: was it current when the numbers changed? Authority: who owns or approved it? Task proximity: does it help answer this exact question, or is it merely about the same broad subject? In this case, keep the current CRM definitions, yesterday's approved memo and the active pricing policy. Include one prior forecast only if comparison is required. Leave the rest available for retrieval rather than placing it in the first request.

The method is not a scoring formula. It is a way to make inclusion explainable. If a source is present, you should be able to say what work it is there to do.

Selection is only the start. Retrieval brings in evidence when the task needs it. Ordering places instructions and decisive sources where the workflow expects them. Compaction turns an older exchange into a shorter working record, provided important decisions and unresolved questions survive. Removal keeps obsolete or distracting material out. Each practice spends capacity in service of usable attention.

The failure state I call the dumbzone is not a precise token threshold. It is the point where output remains fluent while task performance has become less dependable. That can happen because instructions are buried, sources conflict or earlier decisions were compressed badly. The remedy is not always a shorter context. It is a context whose contents and transformations can be inspected.

There is no universal ideal context size. A legal review may need broad source coverage. A classification task may need only a definition and a few examples. Different models and retrieval systems behave differently, so the working set has to be evaluated on representative tasks rather than chosen by folklore.

The student in me likes accumulation: another paper, another transcript, another source in case it helps. Context engineering taught me a more professional discipline. Preserve access to the wider library, but make each item in the active working set earn its place through relevance, freshness, authority or task proximity.

Capacity tells you what will fit. Context engineering decides what belongs.