Context Engineering

Context engineering is the practice of deciding what information a model sees for a given step, in what order, and in what format. It is broader than prompt engineering. Prompting focuses on instructions; context engineering focuses on the entire input package: system prompts, user request, retrieved context, memory, examples, tool results, and workflow state.

In modern GenAI systems, output quality often depends less on wording tricks and more on whether the right context was assembled at the right time.

A useful mental model is to treat context as layered:

1. Instruction layer — system prompts, role definitions, policies, and formatting rules.
2. Task layer — the current user request, explicit constraints, and desired output.
3. Knowledge layer — retrieved documents, tool documentation, memory, and examples.
4. Execution layer — intermediate tool results, workflow state, previous decisions, and recent observations.

These layers should not be mixed carelessly. Stable rules belong in instructions; volatile data belongs in execution context.

Good context engineering is selective. More tokens do not automatically mean better performance.

• Retrieve only what is relevant — rank and filter evidence instead of dumping full documents.
• Summarize old state — long traces should be compacted instead of replayed forever.
• Localize tool context — only include the tool descriptions and examples needed for the current step.
• Separate raw evidence from synthesis — do not blend source snippets with instructions carelessly.
• Use step-specific prompts — retrieval, planning, routing, and synthesis often need different context shapes.

context = [
  system_instructions,
  user_request,
  retrieved_evidence[:k],
  recent_tool_results,
  summarized_memory,
]

Most context failures come from one of four patterns:

• Context overload — too much low-value material dilutes important signals.
• Context omission — a critical policy, tool result, or document never makes it into the prompt.
• Instruction collision — system rules, user instructions, and retrieved content conflict.
• Stale state — summaries or memory persist after the task has changed.

The solution is usually architectural, not linguistic: better retrieval, better state compaction, clearer layering, and tighter workflow boundaries.

In production systems, context engineering should be observable and testable:

• Log context assembly decisions — capture which sources, chunks, summaries, and tool outputs were included.
• Version prompt and retrieval logic — context assembly changes should be traceable like code.
• Measure context effectiveness — track whether longer context actually improves outcomes.
• Design for compactness — context budget is a product constraint, not just a model parameter.

Prompt engineering asks, "What should I tell the model?" Context engineering asks, "What should the model know right now, and what should be left out?"