Context engineering

Context engineering is the discipline of deciding what a language model sees for a given task: which instructions, which documents, which data from your systems, which tool descriptions, in what order and in what quantity. It then builds the system that assembles this context automatically for every case, so that no person has to paste it together by hand.

How is this different from prompt engineering?

Prompt engineering is about the wording of the instruction. Context engineering is about everything around it: the retrieved documents, the state of the case, the list of available tools, the examples, the history of the conversation.

In an AI agent the instruction is often the smallest part of the context window. The rest is assembled by code at the moment of the call. Rewording the prompt fixes one class of problem. Getting the context right fixes most of the others, which is why the term has displaced prompt engineering in teams that run agents in production.

What does context engineering decide?

Selection. Of the thousand things the system could show the model, which are relevant to this case. This is where retrieval-augmented generation and plain filters do their work.

Compression. A long history becomes a summary. A raw document becomes a structured extract. The model reads less and reads the right part.

Ordering. Models weight the beginning and the end of the context more heavily than the middle. What goes first and last is a decision, not an accident.

Format. Tables and schemas beat prose for data. A price list as a table produces fewer invented numbers than the same list as paragraphs.

Budget. The window is finite and billed per token. More context is slower and more expensive, and past a point it is also worse, because the relevant part is buried.

Provenance. Which parts of the context came from you and which came from outside: an email, a web page, an uploaded PDF. Marking that boundary is the first line of defence against prompt injection.

Why does this matter for a company?

Context engineering is the work behind the sentence "the agent knows our company". The familiar symptoms of shallow AI adoption are context failures. People paste the same background into every chat because the context lives in their heads. Workflows die with their creator because the context lived in one person's chat history. Three AI tools hold three partial copies of the same facts.

Done properly, context becomes a maintained asset: a set of documents, rules and connectors, often exposed through MCP, that every agent in the organisation draws on. What the agent should remember across cases is the neighbouring question of agent memory.

Who maintains that asset is an organisational decision, not a technical one. The companies that get it right name an owner for it, the same way they name an owner for the CRM.

Example: answering tender questions

An agent answers the questionnaire in a public tender. The poor version dumps the entire company wiki into the window and hopes. The engineered version assembles, per question: the question itself, the three most relevant passages from the reference-projects database, the current compliance statements, the definitions section of this tender, the formatting rule this client insists on, and an explicit marker on which parts came from the tender document and which from your own files.

The result uses a fraction of the window, and every element in it is traceable. When an answer is wrong, the assembled context is the first place to look. Very often the fault is a missing or stale passage, and that is a data fix rather than a model problem.

Where a company starts with this depends on where its context currently lives. Mapping that is part of the consulting work before any agent is built.