Context bloat
Tokens in the window that the next decision does not need, usually old tool results and repeated text.
Exam context: They are resent on every call and they crowd the instruction. When: A transcript grows by pages of tool output between decisions. When not: The long text is the document the user asked you to use. That document is the task.
See also: 6.1 Context Engineering
Context drift
Later turns follow the recent transcript instead of the original task.
Exam context: The window is what the model conditions on. Recency can outrank an early rule that is still present. When: The answer matches the last tool dump and misses the system instruction. When not: The instruction itself was ambiguous. That is a prompt problem.
See also: 6.1 Context Engineering
Tool-output pruning
Replacing a used tool result with the short fact, or clearing old results past a threshold.
Exam context: The parent keeps the conclusion and loses the dump. When: The tool already returned and the next step needs an id, a total, or an error string. When not: The model has not read the result yet, or the full body is still the evidence.
See also: 6.1 Context Engineering
Compaction block
A summary the API uses as the new start of the conversation. Content before it is ignored on later calls.
Exam context: A long agent loop cannot keep every search page. When: Input tokens are near the trigger and the early turns are exploration. When not: You still need those turns verbatim. Keep them after the block, or do not include them in the summary request.
See also: 6.1 Context Engineering
Context isolation
A subagent or a separate call whose scratch work is not copied into the parent window.
Exam context: The parent stays on the decision. The child spends its own window on the search. When: A subtask would dump logs, files, or many tool calls into the main transcript. When not: The next step needs the parent's intermediate reasoning. Then pass that reasoning in the task.
See also: 6.1 Context Engineering
System prompt
The durable instructions for every call: role, policy, output shape, and the missing-data rule.
Exam context: It is the stable prefix and the rule the case should not be able to rewrite. When: The text must hold on the next request too. When not: The text is this customer's document or id. That is user content.
See also: 6.2 Prompt Engineering
User turn
This call's question and data, including delimited untrusted text.
Exam context: It changes per request and must not sit inside the instruction. When: You have a document, a ticket, or a tool result to judge. When not: You are stating a policy that every future call must follow.
See also: 6.2 Prompt Engineering
Few-shot examples
Several complete input and output pairs, including the edge case, placed before the live task.
Exam context: They show a shape that another sentence of rules did not fix. When: The instruction is already clear and the format or the boundary is still wrong. When not: The source lacks the fact. An example of a filled-in fact teaches invention.
See also: 6.2 Prompt Engineering
Output constraint
A concrete limit on shape: fields, enums, length, or a schema.
Exam context: "Be concise" does not tell a parser what to expect. When: A downstream step will read the answer. When not: You need the value to be true. A constraint governs form, not truth.
See also: 6.2 Prompt Engineering
Input sanitization
Keeping user and retrieved text in a data slot, delimited, length-bounded, and out of the system prompt.
Exam context: Text in the instruction slot is an instruction. When: The call includes content you did not write. When not: You are editing your own policy. That text is supposed to be the rule.
See also: 6.2 Prompt Engineering
Structured output
A response constrained by output_config.format, or a tool input constrained by strict tool use.
Exam context: The program receives a shape it can parse. When: A later step reads fields rather than prose. When not: You need the fields to be true. That is validation against the source.
See also: 6.3 Output Handling
Response validation
Checks you run after parsing: ranges, sums, known ids, and allowed enums.
Exam context: A valid document can still violate the policy. When: The schema succeeded and you are about to store or act. When not: The turn is truncated. Fix the stop before you validate a prefix.
See also: 6.3 Output Handling
Defensive parsing
Accept only a finished block that parses. Reject prose, prefixes, and unexpected types.
Exam context: Model text is not code and not a guarantee. When: You turn a Messages response into an object in your process. When not: You are showing the assistant's prose to a person with no further action.
See also: 6.3 Output Handling
Confident output
A fluent claim, including a citation or a filled blank, with no extra evidence attached.
Exam context: Tone does not measure support in the source. When: You decide whether to trust a field. When not: The field matched a check you already ran. Then the check is the reason, not the tone.
See also: 6.3 Output Handling
Validation retry
A new call that includes the specific validation failure.
Exam context: The model otherwise repeats the sample that already failed. When: The source contains the fact and the shape or the rule missed it. When not: The source never had the fact. Retrying asks the model to invent it.
See also: 6.3 Output Handling