Context Engineering Beat Prompt Engineering. Here’s the Handoff.

Ask an engineer what is in their agent’s context window right now and watch the pause. Almost nobody can answer precisely, which is strange given that it is the only thing the model sees.

Context engineering is the practice of being able to answer that question, and then defending every item on the list. Sourcegraph’s framing (deciding which tokens earn a place) is the cleanest definition going (Sourcegraph↗ (opens in a new tab)), and it splits neatly into four jobs.

1. Selection: what gets in

The failure this prevents is dilution. Retrieval that returns twenty chunks including six near-duplicates does not give the model more information; it gives it a majority vote on the wrong thing.

• ·Deduplicate aggressively before ranking, not after.
• ·Budget by role: system, task, evidence, history. Each gets a token ceiling and competes only within its own bucket.
• ·Log the final selection for every run. If you cannot replay what the model saw, you cannot debug it.

2. Compaction: how it gets smaller

The failure this prevents is context rot. The slow drift where a long transcript buries the instruction that mattered. Summarizing history is not lossy noise reduction; it is the mechanism that keeps the task in view.

The practical version: after every N turns, replace the transcript with a structured state object, decisions made, facts established, open questions, current goal. It is smaller, it is more legible, and it survives model swaps because it is not phrased as chat.

3. Ordering: where it sits

The failure this prevents is instruction loss. Long-context recall is real but uneven. The middle of a large window is the weakest position, and the end is the strongest. If your system prompt is at the top of a 90k-token conversation, it is competing against 90k tokens of recency.

Fix: keep durable identity at the top, and re-state the immediate task at the bottom, right before generation. It feels redundant. It measurably is not.

4. Isolation: what stays out

The failure this prevents is cross-contamination. One long-running conversation that researches, drafts, critiques, and schedules will carry the research’s hedging into the draft’s voice and the critique’s pessimism into the schedule.

Sub-agents with clean windows solve this, and the cost is an interface: each sub-task needs an explicit input contract and an explicit output contract. That interface is worth writing anyway. It is what makes the system testable.

What we changed in ClawLI

Our writing pipeline used to assemble one window: profile, memory hits, recent posts, analytics, brief, instructions. It worked until an organization had enough history that memory hits crowded out the brief. Reach and specificity both dropped and the prompt looked fine, because the prompt was fine.

The fix was pure context work: bucket budgets, dedupe on memory retrieval, tool results summarized to three fields, and the brief re-stated last. Same model, same prompt, materially better drafts.

How to start on Monday

1. Dump the full assembled context for ten real runs to a file and read them. Actually read them.
2. Count duplicated facts. That number is your dedupe ROI.
3. Add per-bucket token budgets and log utilization per run.
4. Move the task statement to the end and re-measure on your golden set.

Nothing here requires a new model or a new framework. It requires looking at the thing you have been shipping blind. More on measuring the result: evals or it did not ship.

I write more about context assembly patterns at Alex Cinovoj↗ (opens in a new tab), and the production versions of these handoffs ship inside the systems we build at TechTide AI↗ (opens in a new tab). The pattern generalises well past content.