Four constraints on context engineering

From art to engineering

Prompt engineering was about finding magic words. Context engineering is about managing a scarce, priced, position-sensitive resource, much closer to memory hierarchy design than to copywriting. The research literature described the constraints; running these systems in production added a cost dimension on top of them. This post covers both.

Constraint 1: position matters

Liu et al.'s "Lost in the Middle" result is old news by now, but its production corollary isn't widely practiced: models attend best to the beginning and end of context, worst to the middle. Modern frontier models flattened the curve, but they didn't eliminate it.

Practical layout, top to bottom: identity and rules → tools → curated reference → conversation → the live task, restated last. If something must not be missed, it goes at an edge, usually the bottom edge.

Constraint 2: tokens are priced by position too

Prompt caching charges you a premium (~1.25×) to write a prefix once, then ~0.1× to reread it every turn after. The catch: the cache is a prefix cache. One changed byte at position N invalidates everything after N.

Design rule: sort your prompt by volatility. Anything that changes per-turn (timestamps, mutable state, retrieval results) lives after everything that doesn't. A single per-turn line high in the prompt, a timestamp is the classic case, invalidates the cache for everything below it on every request, and the difference lands directly on the bill.

def assemble(system, tools, memory, transcript, task):
    return [
        block(system,  cache=True),   # never changes
        block(tools,   cache=True),   # changes on deploy
        block(memory,  cache=True),   # changes on compaction
        block(transcript),            # append-only
        block(task),                  # volatile, always last
    ]

Constraint 3: attention is a budget

Even within the window, every token competes for attention. Fill the window to 95% with tool logs and the model gets measurably dumber at the actual task, a problem known as context rot. Two mitigations do most of the work:

• Compaction. When the transcript crosses a threshold, summarize it into a structured state block (decisions, open questions, file map) and drop the raw scroll. This is aggressive: the raw transcript is gone. It works because the model reading the summary back is the same model that wrote it, so it can trust its own compression.
• Memory files. Facts that must survive sessions go to disk, not context. An index loads every session; bodies load on demand. Context becomes a cache over durable state.

def should_compact(ctx):
    return (
        ctx.tokens > 0.7 * ctx.window
        or ctx.tool_output_fraction > 0.5   # transcript is mostly logs
        or ctx.turns_since_compaction > 30
    )

Constraint 4: don't read it yourself

The highest-leverage trick of 2026 barely appears in papers: subagent fan-out as a context firewall. When a question requires reading fifty files, the orchestrator shouldn't read them. It spawns a searcher that burns its own disposable window and returns three sentences. Reading happens in a sandbox; only conclusions enter the main line.

The mechanism carries the economics: the orchestrator's window stays small, stable, and cached while each searcher burns a disposable window, so total cost tracks the number of conclusions rather than the volume of reading, and the orchestrator's context never fills with material it only needed once.

The checklist

• Sort by volatility; breakpoint the stable prefix; never edit above the fold mid-session.
• Put must-not-miss material at the edges, preferably the end.
• Compact on shape (log fraction), not just size.
• Persist facts to memory files; context is a cache over durable state.
• Fan out the reading; keep the conclusions.
• Watch cache-hit rate in your metrics dashboard the same way you watch p95 latency: it doesn't look dramatic, but a drop shows up directly in the bill.

None of the techniques above depend on a better model. They depend on treating the context window as a priced, position-sensitive resource instead of a scrolling log.

What's the difference between context engineering and prompt engineering? (2026 update)

Three weeks after this post shipped, the discourse moved again. This section is the bridge, and the answer to the question this post's title raised. Prompt engineering shapes one turn: the words. Context engineering (everything above) shapes what a turn can see: the window. And the new layer, loop engineering, shapes what happens across a thousand turns nobody watches: the machine that writes the prompts and manages the windows for you. They stack. Every technique on this page became more important once the loops arrived, because a loop is an amplifier: unmanaged context inside one compounds instead of averaging out.

Meanwhile the prompting layer itself inverted: the frontier models now follow instructions so well that the craft became deletion. Part 2 covers what died, what survived, and how Opus 4.8, Fable 5 and GPT-5.6 each want different things. The saga reads in the order the discipline evolved: words, window, loop. This page is the window, and the techniques above still hold.