Context Engineering
The context window is finite. What goes into it — and in what order — determines the quality of every output. Context engineering is the practice of deliberately designing the information architecture of the context window.
The Context Budget
Every context window has a token budget. Allocate it deliberately:
- System prompt: The foundational instructions (typically 5-20% of the budget)
- Retrieved context: Documents, data, and information pulled in for the current task
- Conversation history: Previous turns in the conversation
- User input: The current request
- Working space: Room for the model to generate its response These compete for space. More retrieved context means less conversation history. A longer system prompt means less room for everything else.
Information Architecture in Context
Order matters. The model pays different amounts of attention to different positions:
- Beginning: High attention. Put your most important instructions here.
- Middle: Lower attention. This is where information can get lost in long contexts.
- End: High attention. The most recent information (user input) naturally goes here.
- Adjacent to the task: Information placed right before the user's question gets more attention than information earlier in the context.
Context Selection
Not everything should go into the context. Design selection criteria:
- Relevance: Does this information help answer the current question?
- Recency: Is this the most up-to-date information available?
- Specificity: Is this specific enough to be useful, or is it too generic?
- Redundancy: Is this information already covered elsewhere in the context?
- Authority: Is this from a reliable source?
Context Strategies
- Retrieval-augmented generation (RAG): Pull relevant documents into the context dynamically
- Summarisation: Compress older context into summaries to free up space
- Prioritised history: Keep recent and important conversation turns, drop less important ones
- Structured context: Organise information with clear headers and sections so the model can navigate it
- Context caching: Pre-compute and cache frequently used context blocks
Context Quality Signals
How to tell if your context engineering is working:
- Output relevance: Do outputs address the actual question using the provided context?
- Hallucination rate: Is the model making things up because the context is insufficient?
- Context utilisation: Is the model actually using the provided context, or ignoring it?
- Consistency: Are outputs consistent when the same context is provided?
Design Artefacts
- Context budget allocation documents
- Information architecture diagrams for the context window
- Context selection criteria per feature
- Retrieval strategy specifications
- Context quality monitoring metrics