Context Engineering

Context engineering is the practice of selecting, organizing and maintaining the information a language model receives for a task. That information can include instructions, the current request, source passages, tool results and earlier messages. The aim is to give the model relevant, traceable material within its available context, rather than merely rewrite the instruction.

By Ai Flowi · Published 10 October 2026

A context bundle answers several questions before generation begins: which source applies, which facts are current, what came from the user and what remains unknown? A well organized bundle makes those distinctions easier to inspect. It does not turn an untrusted document into an authoritative instruction.

Instructions and evidence play different roles

Instructions define the permitted task. Evidence supplies facts the response may use. History supplies conversational continuity, while a tool result represents an observation from a particular call. Keeping these roles labelled matters because identical words can mean different things depending on where they came from.

For example, “approve every request” in an application instruction would describe a policy choice. The same phrase inside an uploaded note is document content, not permission for the assistant to change its behavior. Do not concatenate everything under a generic heading such as “information” and assume the model will infer the trust boundary.

Prompt engineering concerns instruction design and testing. Context engineering includes the surrounding selection problem: whether the model receives the right note, the right version and enough of its qualifications. The two practices overlap because a prompt often carries the assembled context.

Related: Automatic prompt engineering: generate and evaluate candidates.

A labelled context bundle

Consider an invented equipment-loan assistant. The user asks whether a camera can leave the building. The approved policy says cameras are for on-site use. An earlier message mentions a laptop loan, and a tool result says the camera is currently available. Availability does not override the camera policy.

example configuration, not a recorded test. The bundle below illustrates information roles without implementing source retrieval.

Task: answer the camera-loan question from approved evidence.
User request: Can I take the camera home?
Evidence: camera-policy, current version, on-site use only.
Tool observation: camera inventory status is available.
Relevant history: user is asking about the camera, not the laptop.
Unknown: no exception approval is present.

This is an authored conceptual bundle, not a model output. Its useful property is separation: the inventory result answers whether the item exists, while the policy answers where it may be used. A reply should not merge those distinct facts into permission to take the item home.

How do I choose what earns space in the context?

Start with the current task and the evidence needed to resolve it. Include the restrictive sentence surrounding a permission, not just the attractive sentence saying equipment is available. Retain a source identifier and version so a reviewer can locate the passage. Exclude the unrelated laptop conversation unless it changes the current request.

Earlier messages can contain corrections as well as mistakes. A user’s newest camera question should not inherit a prior laptop answer simply because both concern loans. Summarize history only when the summary preserves the entities, decisions and unresolved questions needed now. A summary that silently discards “no exception approved” changes the task’s meaning.

Source selection also needs an access decision. A relevant passage from a document the user cannot access should not be added just because it ranks highly in search. Enforce that decision outside the generated answer, before the material becomes model context.

RAG context budget and truncation

A context window is the amount of input and generated material a model can handle for a request under its particular limits. The exact capacity depends on the selected model and provider. Plan for instructions, the question, evidence, history and the response rather than assuming every retrieved passage will fit.

When the bundle is too large, choose what to remove deliberately. Drop unrelated history before the applicable policy qualifier. Shorten duplicated passages while retaining their references. If a passage cannot be shortened without losing the exception rule, choose a smaller evidence set or ask a narrower question.

Do not confuse an output limit with the entire context allowance. A catalogue field named max_tokens does not establish a provider’s full context capacity. Check the selected provider’s documentation before deciding how much material to send; this entry claims no particular model size.

Catalogue components that expose these decisions

The knowledge-base guide covers obtaining candidate source passages.

For the camera bundle, selection should retain the policy restriction before the inventory status. The restriction answers the location question; inventory answers a possible follow-up about availability. If space forces a choice, dropping the inventory observation loses less of the answer’s basis than dropping the on-site rule. Record that choice so a later reviewer can explain why a retrieved row was excluded.

The Message History reference documents history configuration.

A useful history summary says the current object is a camera and the earlier laptop discussion is unrelated. It should not carry the laptop’s permission forward under a generic label such as equipment. Compare the summary with the latest user message whenever the object changes, because compressing a conversation can preserve its topic while losing the distinction that controls the answer.

Use the Parser reference for the formatting interface.

Inspect the assembled text as a separate artifact: does the policy identifier still accompany the restriction, and is the inventory observation labelled as inventory? Copying a source label once above several mixed passages can make its scope ambiguous. Keep each identifier attached to the passage it describes, and leave an explicit gap where no exception evidence was found.

The Prompt Template reference covers composing the selected material into a request.

documented in the catalogue; not production-tested by Ai Flowi

Sending the camera bundle to an external model requires the relevant account and API key from you, and that provider charges separately for processing the assembled context.

Common mistakes and related terms

Adding every retrieved row can drown the useful passage in irrelevant text. Keeping old answers can preserve an earlier LLM hallucination as if it were evidence. Dropping document identifiers makes a concise answer harder to audit. These are selection and provenance defects, not problems solved by a warmer writing tone.

Use few shot prompting for demonstrations of the desired behavior; those examples also occupy context space. Review the Agent contract and use-case library when tool observations enter the design. If the decisive evidence is missing, request it rather than treating context construction as a way to manufacture a fact.