What context really is
Context is the material available to a model for one response: instructions, the user request, selected documents, tool results and the recent conversation. It is not durable memory. When the next call begins, the harness decides what comes back in.
That makes context engineering an ordinary engineering task: choose the smallest reliable input that lets the next decision be made.
raw logs, tickets, docs, prior state
↓ select and summarize
task + constraints + relevant evidence + expected output
↓
model
More is often worse
A huge context window is not an excuse to throw in every runbook, ticket and log line. Irrelevant material competes with the real signal. Stale instructions can quietly override the current task. Sensitive data may be copied into a provider request without a reason.
Give each item a reason to exist: Does it constrain the action? Does it establish evidence? Does it define the output? If not, leave it out or retrieve it only when needed.
Context needs provenance
When the model makes a proposal, a reviewer should be able to answer: which sources did it see, when were they retrieved, and which claim came from where? This is how a confident summary becomes something an engineer can check.
The model is stateless between calls unless your harness restores information. That is a design fact, not a model flaw.
Try it
Run workbench advanced from the cloned Workbench folder. It prints the exact context packet: task, chosen evidence and character budget. It also records which sources did not fit. Run it again after changing the budget in the code or tests, then inspect what entered and what stayed out.
The practical question is not “what else can fit?” It is “what missing evidence would make the next decision safer?” Add only that.
Keep this with you
Context is rented attention. Spend it on evidence and constraints.