Context Engineering

How Context Engineering Works

A language model does not process a task using all
information that exists somewhere about the topic in question.
Its output can only be based on relationships learned by the model and on the information made available to it during processing.

This context can include, for example:

• system instructions
• user requests
• previous parts of a conversation
• documents
• search results
• stored states
• tool results
• rules and specifications
• examples
• information about the current task

Context Engineering concerns how this context is assembled for a specific task.

Context Is More Than a Prompt

A prompt is an input or instruction to a model.
The context can contain considerably more.

For example, a system could receive the user request:

Update the mail server configuration.

For meaningful processing, the following could additionally be necessary:

current configuration
applicable architectural rules
version of the software being used
documentation for this version
information about dependent services
desired target state

The wording of the user request alone does not solve the information problem.
The model needs the information relevant to the task.

This shifts the question from:

“How do I formulate the perfect prompt?”

to:

“What information does the system need now, and how does it get exactly this information?”

More Context Is Not Automatically Better

An obvious strategy is to give a model as much information as possible.
This can work, but it has limits.

Additional information can:

• be irrelevant to the specific task
• be outdated
• contradict other information
• contain different versions of the same facts
• hide important information among unimportant information
• consume the available context window

A large document archive is therefore not yet good context.
What matters is which parts of it are needed for the current task.
Context Engineering is therefore also a selection problem.

Valid Context

In addition to relevance, there is the question of whether information is valid.

For example, a system can contain several configuration examples:

config-2024.conf
config-2025.conf
config-current.conf

All three files can look technically correct.
For the current task, however, perhaps only one of them is valid.
The same problem arises with documentation, rules, architectural decisions, or previous conversation content.

Context Engineering must therefore ask not only:

“Is this information relevant to the topic?”

But also:

“Is this information still valid for the current state of the system?”

Context Has Provenance

Information can come from different sources.

It can, for example:

• have been entered by the user
• come from internal documentation
• have been loaded from a database
• have been found through a search
• have been generated by a tool
• come from an earlier interaction
• have been generated by another AI system

This provenance can be important for evaluating it.
For certain questions, a current configuration file from a running system may have different evidentiary value than documentation that is several years old.
A summary previously generated by the language model itself is, in turn, not automatically an independent source.
Context Engineering can therefore also require information about where a component of the context comes from.

Context Can Be Provided Incrementally

Not every potentially relevant piece of information has to be fully loaded into the context at the beginning of a task.
A system can initially provide a small context and make further information available when it is needed.

For example, the initial context could contain:

task
current system state
applicable rules
overview of the components involved

Detailed documents are additionally available for individual components.
If the model needs information about one of these components, the corresponding details can be loaded.

This creates a multi-level information structure:

overview
    ↓
relevant area
    ↓
specific details
    ↓
original source

This can help keep the immediately provided context small without fundamentally losing access to more detailed information.

Compression Changes Information

Long information can be summarized or compressed to require less context.
However, this creates a new problem.
A summary is not identical to its source.
Details can be lost.
Exceptions can disappear.
The weighting of individual statements can change.
And an incorrect summary can subsequently be used again as context itself.
It can therefore be useful to retain the provenance of, or access to, the underlying source alongside a compressed representation.
Compression is therefore not a cost-free reduction of context.
It is a transformation of information.

Contradictory Context

Context can contain contradictory information.

For example, documentation could say:

Port 8080 is used.

A current configuration, by contrast, contains:

listen_port=8443

The model must now deal with two different statements.
Without additional information, it may not be possible to determine which one is valid.

A Context Engineering system can therefore require mechanisms to, for example:

• indicate currency
• distinguish sources
• define priorities
• describe scopes of validity
• make contradictions visible
• request further information when uncertain

The goal does not have to be to resolve every contradiction automatically.
It may be sufficient or even necessary to make it visible first.

Context and Rules

Rules are also context.

For example, a system can specify:

Direct output to stdout is not permitted in this project.

For an AI system to take this rule into account, it must be available during the relevant task.

If several hundred rules exist, the Context Engineering question arises again:

Which of them are relevant to the file or component currently being worked on?

One possibility is to structure rules by scope and provide only the rules relevant to the current work area.
The subsequent check of whether the generated solution actually complies with these rules is a different task, however.
Context can communicate a rule to a model.
It does not guarantee that the model complies with it.

Context Engineering and Evaluation

A well-assembled context can improve the conditions for a good output.
However, it does not prove its correctness.

A language model can:

• overlook information
• apply rules incorrectly
• misinterpret relationships
• draw incorrect conclusions from correct context
• add plausible but unsupported statements

Context Engineering and Evaluation therefore perform different tasks.

Context Engineering asks:

“What information is available to the system for this task?”

Evaluation then asks:

“How well does the result meet the requirements?”

The two complement each other, but do not replace each other.

Context Engineering Is a Systems Problem

As soon as AI systems no longer process only individual isolated prompts, context management can become an important part of their system design.

Decisions must be made about:

• information sources
• selection methods
• updating
• versioning
• priorities
• validity
• compression
• storage
• access
• context boundaries
• loading additional information
• handling contradictory information

Context Engineering is therefore not only a question of wording text.
It is the design of information provision around an AI model and the task it is processing.

Why Context Engineering Has Practical Effects

• Relevant information is provided selectively: The model does not have to process all available data at the same time.
• Outdated context can be identified: Currency and validity can be part of context management.
• Context windows are used more selectively: Immediately required information can be prioritized over background material.
• Large bodies of knowledge become usable: Information can be structured and loaded when needed.
• Contradictions become visible: Different sources do not have to be silently merged into an apparently unambiguous statement.
• Rules can be provided for specific tasks: Not every rule has to be present in the context for every task.
• Sources remain traceable: Compressed information can remain connected to its origins.
• Evaluation can become more reproducible: The context used can be documented as part of the conditions of an evaluation.

Typical Example

A software project has several hundred documents.

They contain:

• architectural decisions
• programming guidelines
• documentation for external libraries
• old drafts
• current configurations
• examples
• bug reports
• technical notes

An AI system is intended to modify a single function.
Loading all documents into the context would be neither necessary nor necessarily helpful.
Instead, the system first determines which component is affected.
For this component, the currently valid architectural rules, relevant programming guidelines, the affected source file, and the necessary technical documentation are provided.
During processing, it becomes apparent that the function uses an external service.
The documentation for this interface is then loaded additionally.
The model therefore does not work with all available knowledge, but with a context assembled for the current task.
After the change, it is independently checked whether the result actually meets the applicable rules and functional requirements.

Distinction

• Context Engineering concerns the selection, structuring, and provision of the context relevant to a task.
• Prompt Engineering focuses more strongly on the design of instructions and inputs for a model. Prompts can be part of the context.
• Retrieval-Augmented Generation (RAG) is a possible technical method for searching for information and providing it for generation. RAG can therefore be part of a Context Engineering solution, but is not the same as Context Engineering.
• The Context Window describes the technically limited amount of context that a model can consider during processing.
• AI Evaluation examines the quality and properties of generated results. Suitable context can influence these results, but does not replace their evaluation.

Further Reading

Related Concepts

→ Prompt Engineering
→ Prompt
→ System Prompt
→ Context Window
→ Language Model
→ Token
→ Probabilistic
→ AI Evaluation
→ AI Assurance
→ Observability