What is context engineering?

Build the input for this step

A coding assistant is asked to fix a CSV export. The failing example is small: “Paris, France” must remain one quoted cell, rather than becoming two columns. The assistant needs the task, the API constraint, the failing example, the relevant code, and an appropriate way to check the repair.

It probably does not need a conversation about dashboard colors or the complete output of unrelated CI jobs. Context engineering is the decision about what the model should see for this call. After reading this article, you should be able to identify a missing input fact, distinguish it from a capacity problem, and explain who constructs the next call.

Anthropic's context engineering guide describes curation as an ongoing part of an agent loop. Prompt wording matters, but the complete input also includes selected history, files, retrieved evidence, tool definitions, and observations from earlier actions.

Enough room is not enough information

A context window sets a capacity limit. It does not certify relevance, authority, or task coverage. Our CSV request can fit comfortably while omitting the test that explains the bug. Adding thousands of unrelated tokens can consume room without supplying that missing example.

Use the existing selection experiment below to compare sufficient, incomplete, and overloaded inputs. The right-hand packet shows the authored content behind each selection. Remove repository rules to lose the API constraint, or the failing test to lose the concrete regression case.

Read the result as an input check

The “missing evidence” preset is smaller than the sufficient packet. It still lacks the failing example. The overloaded packet includes every required item, but exceeds the teaching budget. These conditions require different repairs: retrieve the missing evidence in the first case; select or compress material in the second.

“Required input facts are present” means only that the declared checklist is satisfied. It does not establish that a model will find the correct patch. Model behavior must be observed separately. Lost in the Middle found that evidence position affected performance in its studied long-context tasks. RULER tested several kinds of long-context work and distinguished advertised capacity from effective task performance. Neither result gives this local token counter a model-quality score.

The harness owns the next packet

The application or harness selects and labels the input before calling the model. The model proposes a response or tool call. If a tool runs, the harness receives its result and decides how that observation enters the following call.

For the CSV repair, a focused test failure should replace uncertainty with a specific observation. The next packet should preserve the current goal and constraints, include the relevant result, and omit material no longer needed. Persistent files and application state survive outside this temporary packet; the model does not automatically receive all of them.

flowchart LR
  G[Goal + constraints] --> C[Harness builds context]
  E[Selected evidence + tools] --> C
  C --> M[Model proposes next action]
  M --> T[Harness checks and runs tool]
  T --> O[Result + updated state]
  O --> C

Select, label, and preserve what matters

Select the smallest useful evidence set for the current action. Label where each fact came from and which instruction has authority. Compress repeated history when it helps, while retaining decisions, unresolved questions, failures, and exact references that a summary could lose.

A repository file or retrieved page can contain text that looks like an instruction. Its appearance in context does not give it the authority to change the user's goal or permissions. Keep trusted constraints separate from untrusted evidence and enforce consequential limits in the application.

Persist important state outside the prompt, then retrieve the relevant part when needed. A summary is a lossy view, not the canonical record. Splitting work across agents can isolate useful contexts, but introduces its own coordination and shared-budget obligations.

Diagnose the missing resource

Before adding more tokens, inspect the actual input sent to the model. Was the important fact selected? Was it current and authorized? Was its source clear? Did a tool result survive into the next call? Did compression erase a constraint? Measure tokens with the actual tokenizer and reserve output space according to the chosen API; official model guidance is provider-specific, not a universal budget.

Then change one part and evaluate the task again. Context engineering succeeds when the next action has the evidence and constraints it needs—not when the packet is as large as possible.