Domain 4 — Prompt and Context Engineering (11.0%)

11.0% of the exam, roughly 6 questions. Context engineering matters more here than prompt wording, and output handling is where the marks are.

4.1 Prompt engineering, in the order to apply it

1. Be clear and direct. State the task, the output format and the constraints explicitly.
2. Give examples. The strongest lever for consistency. Include edge cases, not just happy paths.
3. Ask for reasoning on analytical work, before the answer.
4. Use XML tags — <document>, <examples>, <instructions> — to give unambiguous boundaries that both the model and your parser can rely on.
5. Put standing instructions in system and the task in the user turn.
6. Prefill the assistant turn to force a format and skip preamble.
7. Chain prompts when one call is doing too much.
8. Long documents first, question last, each document tagged and identified.

4.2 Context engineering

Context is a budget you spend every turn, and the discipline is deciding what deserves to be in it.

• Order matters. Stable content first — system prompt, tool definitions, reference documents — because that is also what makes prompt caching possible. Volatile content last.
• Trim what has stopped informing anything. Old tool results, superseded drafts and resolved sub-threads cost tokens every single turn they remain.
• Context editing automates that server-side. clear_tool_uses_20250919 clears the oldest tool results once a trigger threshold is crossed, with keep preserving recent ones, exclude_tools protecting specific tools, and clear_at_least ensuring each activation frees enough to justify the cache invalidation it causes.
• Offload rather than accumulate. Write intermediate state to files or a memory tool and read it back on demand.
• Isolate. A subagent's exploration never enters the parent's context; only its conclusion returns.

The wrong answer to degraded quality in a long conversation is "use a model with a bigger context window". Attention dilutes across long contexts, so a larger window lets the problem grow. Trim, isolate or offload.

4.3 Structured output

Two distinct mechanisms, and the exam expects you to know which is which:

Supported schema features include the standard types, properties, required, additionalProperties, enum, const, anyOf, oneOf, type arrays and items. Not supported: pattern (regex), allOf, not, if/then/else, dependentSchemas and recursive schemas. Limits to remember: at most 20 strict tools per request, 24 optional parameters, 16 parameters using anyOf or type arrays.

4.4 Validating the response

A schema guarantees shape, never truth. An invoice extraction can be perfectly typed and still have a total that does not match its line items. So the pipeline is always three stages:

1. Constrain at generation with a schema.
2. Validate against your business rules — cross-field consistency, referential integrity, ranges.
3. Retry with the specific error fed back: "line_items[2].amount was 'N/A'; it must be an integer in cents." Cap the attempts, and route persistent failures to human review with the partial result attached rather than dropping the record or emitting one you know is invalid.

Two edge cases survive the schema: stop_reason: "refusal" and stop_reason: "max_tokens" can both produce output that does not conform. Keep checking stop_reason even when a schema is in force. Enum casing is not guaranteed either — compare case-insensitively.

← Previous: Domain 3 — Agents and Workflows  |  Next: Domain 5 — Tools and MCPs →