Context Engineering

Context Engineering is 3.8% of CCDV-F, so expect around two questions from it. The sub-skill sits above prompt wording and below application architecture: given a finite window and a task that will not sit comfortably inside it, decide what occupies that window on each turn.

The thing to hold onto is that context is a budget spent on every single request, not a container filled once. In an agent the largest consumer is rarely the standing instructions. It is accumulated tool output: file contents, search results, service responses, and the record of things that were tried and abandoned. That material arrives without anybody deciding to add it, which is why context problems present as gradual degradation across a long session rather than as an obvious failure on turn one.

Questions here typically describe a symptom and ask for the remedy. An agent that was sharp early and vague an hour later, a summariser that lost a constraint agreed twenty turns ago, a research task drowning in retrieved documents: each has a different structural fix, and the fixes are not interchangeable. What is being tested is whether you can read the symptom, not whether you can list the techniques.

Learn the failure modes and the volumes involved, and the remedies fall out of them.

What the exam tests here

• •Attributing window pressure to its real source, which in an agent is usually tool output
• •Choosing between on-demand retrieval, compaction, external notes and delegation for a described symptom
• •What a compaction step must preserve and what it can safely discard
• •The interaction between assembly order and cached reuse, since both depend on stability
• •Preventing failed attempts and superseded results from steering later turns

Budget the window by consumer, not by section

Divide a request into what you control at design time and what accumulates at run time. Standing instructions and tool definitions are fixed and paid on every call, so their cost is predictable and optimising them is a one-off job. Conversation history and tool results are neither: they grow with the task, and in a tool-using agent they dominate everything else within a few dozen turns.

That asymmetry decides where effort goes. Trimming two hundred tokens of preamble is a rounding error next to a tool returning an entire file when the model needed one function. Instrument the split before optimising it, because the intuition that the preamble is the problem survives only until you measure a real agent session and find it accounts for a tenth of the traffic.

Four remedies for four different symptoms

On-demand retrieval answers "I cannot know in advance which of these thousands of documents matters", keeping identifiers cheap in the window and fetching bodies only when a step calls for one. Compaction answers "this session is long and the early turns are settled", replacing a stretch of history with a summary and continuing from it.

External notes answer "this has to survive beyond the window", writing decisions and state to a file the agent can reopen. Delegation answers "this subtask will read far more than it concludes", handing it to a separate context that returns findings rather than transcript. Matching these correctly is most of the sub-skill. Compacting a retrieval problem shrinks the wrong thing, and delegating a task whose value is the detail throws away what you needed.

Compaction is lossy, so decide what survives

A summarisation step is not neutral compression. Something is being deleted, and the failure mode is quiet: the agent carries on confidently without the constraint it accepted nine turns ago. Write the retention policy explicitly instead of asking for a generic summary. Decisions, commitments, open questions, paths and identifiers, and anything the user stated as a requirement should survive close to verbatim. Raw payloads, superseded drafts and the reasoning behind an abandoned branch generally should not.

Compaction also costs more than the summarisation call itself. Rewriting the middle of a conversation changes the bytes of the prefix, so a cached history stops matching from that point and the following request rebuilds it. Usually worth paying, which is why compacting every few turns is a poor default.

Assemble in a stable order

The window has an ordering as well as a size, and two separate forces pull the same way. Cached reuse requires that everything ahead of a breakpoint stay byte-identical, so anything volatile placed early poisons what follows it. Attention behaves more predictably when material sits in a consistent position relative to the request.

A layout satisfying both puts fixed instructions and tool definitions first, then stable reference material, then the accumulating exchange, then the current request. What breaks it is small and easy to overlook: a session identifier interpolated into the preamble, a tool list assembled per user, a retrieved document appended above the history instead of below it. Treat assembly as code with a defined order rather than as string concatenation.

Where candidates go wrong

Common questions