Prompt Engineering · entry 04/06

Context engineering

When systems run for hours with tools and memory, the craft stops being wording and becomes curation: deciding, every turn, what deserves space in the window.

From sentence to system

Prompt engineering optimizes a message; context engineering manages an economy. An agent three hundred turns into a task carries instructions, tool schemas, conversation, retrieved documents, and tool results — all competing for one window, all billed per token, all diluting each other's attention. The question stops being "how do I phrase this" and becomes "of everything this system knows right now, what earns a seat" — a resource-allocation problem wearing a text editor.

The working levers

Compaction: when history swells, summarize the stale middle and keep the head (goal, rules) and the tail (recent work) verbatim — losing the running purpose to a trim is the classic silent failure. Tool-result hygiene: a 40KB JSON response earns its keep as three extracted fields; raw dumps are context debt. Externalized memory: agents that write notes, plans and intermediate results to files, then re-read what's relevant, effectively page state in and out of the window — retrieval applied to the agent's own past. Just-in-time context: load the reference material when the task reaches it, not all upfront on faith. Cache discipline: keep the stable prefix byte-stable; volatile content appends at the end.

Curation beats capacity

Million-token windows tempted a generation of systems into the junk-drawer pattern: paste everything, let attention sort it out. Measured behavior pushes back — recall inside huge contexts is uneven, distractors actively hurt, and costs scale with every token whether it helped or not. The systems that feel smart at hour three are rarely the ones that remembered the most; they're the ones whose window, at every moment, contained mostly things that mattered. Deliberate forgetting is a feature.

Failure mode

Debugging the model when the window is the patient. Late-session drift — ignored instructions, re-done work, invented state — reads as the model "getting dumb," and teams respond with sterner prompts that add to the very pile causing the problem. Dump the actual assembled context at the failing turn and read it: the original goal fell out in compaction, or a stale tool result contradicts a fresh one, or the window is 60% dead JSON. Prompts fail for boring reasons; so do contexts — but you have to look at what the model actually received, which almost nobody does until hour four.