Context is not “given”: it is built, in each decision, from several
sources and under a budget. Context engineering is the craft of
orchestrating that construction. And it is the layer that is most underestimated, because it is
not seen: when it works, the agent simply “understands”; when it fails,
nobody knows why it answered that.
Introduction
Ten days ago we defined business context (the seven dimensions) and the
concept of context engineering. Yesterday we built the memory that feeds
context. Today it is the mechanism’s turn: how, in each
decision, is the context the agent actually needs built.
Because there is a temptation that is worth naming from the start: that of
“giving the model everything”. Huge context windows, “putting the whole
company in the prompt”. And we have seen why that does not work: the model
chooses from the noise without knowing what it is entitled to. Context engineering is the
opposite discipline: give exactly enough, what is correct and what is pertinent, and nothing else.
The problem
A retail chain has deployed a customer intelligence agent that
helps the pricing team and the category managers. The agent has
access to “everything”: sales, stock, promotions, customer history,
competition, reports. And the pricing team starts to detect something
subtle:
- They ask “what margin do we have on reference R-118 in the north zone?” and
the agent answers with the national margin, because the national data was
the first one in the context. - They ask “how does the competitor’s promo affect our reference
R-204?” and the agent ignores that R-204 is out of stock in three stores in the
zone, so the competitor’s promo does not affect our stock
(although it does affect potential demand). - To two different category managers, the same question gives
different answers, because to each one a different piece of the
“everything” was put in the prompt.
The problem is not a lack of information: there is an excess. The problem is that there is no
mechanism that builds, for each question, the specific context that
that question needs, with the zone, stock, promo
currency and each user’s permissions constraints. The “everything” is not context: it is noise
with good intentions.
The concept
Context engineering is, operationally, a context
orchestrator: a component of the system that, given a decision or a question,
builds the context as a process with steps, not as a
concatenation of data.
The steps of a context orchestrator, in practice:
- Classify the task. What type of decision is being made (pricing,
approving, diagnosing, answering). The type of task determines which
dimensions of the context matter. - Resolve the subject. Which entity or object is the focus (this reference,
this customer, this zone, this contract). Entity resolution (day 5)
resolves the canonical identity of the subject. - Select the dimensions. Of the seven dimensions of business
context (day 10: user, task, temporal, organizational, historical,
transactional, permissions/risk), which are relevant to this task.
Not all tasks need all the dimensions. - Retrieve from each source. For each relevant dimension, retrieve from
the appropriate source:
– User/permissions → from the identity system.
– Transactional (state of the object) → from the source systems (ERP,
CRM, stock) via API, or from the knowledge layer.
– Historical → from the episodic memory (day 9, 12).
– Relational (scope, dependencies) → from the knowledge graph (day 7).
– Stable knowledge (policies, rules) → from the RAG (day 8) or from the
ontology (day 4).
– Temporal (currency) → from the knowledge layer with
currency metadata. - Apply the token budget. Context has a cost (economic
and of the model’s attention). It is prioritized: the most pertinent first, and
the excess is cut. Curate, do not accumulate. - Format with structure. Context is not injected as loose
plain text: it is structured (labeled sections, facts with their source,
rules separated from data) so that the model processes it well and, above
all, so that the answer is auditable: each piece of context has
its origin. - Register the context used. For each answer, it is saved what
context was built and where each piece came from. That is what makes
possible auditing “why the agent answered that” (day 18).
The essential point: context is a deterministic (or
semi-deterministic) construction that the system makes before calling the model. The
model does not “find” the context: the system gives it to it, built. And that
distinction is the one that turns context from an accident (what happened
to be in the prompt) into a property of the system.
Architecture
In the series diagram, context engineering is the mechanism that
turns the layers built into the prompt of each decision:
AGENTS
↓
REASONING
↓
┌───────────┴───────────┐
↓ ↓
MEMORY CONTEXT
(day 12) (TODAY: context orchestrator,
7 steps, budget,
format, registry)
↓
KNOWLEDGE (day 11)
The context orchestrator is the point where all the previous layers
(semantics, ontology, entities, graph, RAG, memory) are turned into the
concrete set of tokens of a decision. It is the most “engineering” layer
of the whole cognitive infrastructure, and the one least seen when it works.
Use case
The retail chain, with its margin question. We break it down:
- Problem. The customer intelligence agent gives
inconsistent answers and at the wrong level of granularity (national instead of
zone), because it does not build the specific context of each question. - Decision. Calculate the margin of reference R-118 in the north zone
and assess the impact of the competitor’s promo. - Knowledge needed. The price and cost of R-118 in the north zone; the
stock per store; the competitor’s promo and its currency; the
pricing rules of the category; the margin history of R-118. - Data. Sales, stock, cost, promotions (own and competitor),
category reports. - Relationships. R-118 → category → pricing rules; R-118 → stores →
north zone → stock; competitor promo → affects → category. - Context. The user is the
north zone manager (permissions: sees the north zone, not the national one); the question is of the zone (not the national one); the competitor’s
promo is in force until the end of the month; R-118 is out of stock in 3
stores of the zone. - Memory. Last quarter, a similar competitor promo
reduced the margin of R-118 in the north zone by 4 %; the decision taken
then (partial counter-promo) and its result. - Reasoning. North zone margin (not national); stock out in 3
stores → the competitor’s promo does not affect the current stock of those
stores, it does affect potential demand; cross with the last-quarter
episode (partial counter-promo reduced the impact); apply the
pricing rules of the category. - Action. Answer “north zone margin: X %; the competitor’s promo
affects potential demand (stock out in 3 stores); according to
the similar Q1 episode, a partial counter-promo reduced the impact;
proposal: partial counter-promo in the stores with stock” with the
justification and the sources. - Infrastructure. The context orchestrator building: task
(pricing) → subject (R-118, north zone) → dimensions (user/zone,
transactional/stock, temporal/promo currency, historical/Q1 episode) →
retrieval from each source → budget → format → registry. The
context built is what gives the correct and auditable answer.
Trade-offs
- Cost. The context orchestrator is a system with
orchestration logic: task classification, dimension
selection, retrieval from multiple sources, budget. It is infrastructure, not a
prompt. - Complexity. The interactions between dimensions (permissions that cancel
history, temporality that changes transactional) are the real work and the
most delicate. An orchestrator that does not manage those interactions produces
incoherent contexts. - Latency. Building the context adds steps (and calls to several
sources) before the inference. For low-criticality decisions it may
not pay off; for high-impact decisions, it is where it is recovered. - Token budget. The budget is a real constraint: too much
context degrades the model’s attention and raises the cost. Curation requires
deciding what is cut, and that is a quality decision, not a saving one. - Security. The orchestrator is where permissions are applied for real:
if a dimension brings data the user cannot see, the context has
failed and the model is going to use it. It is the operational access control of the
system. - Honest limitation: the orchestrator builds context from what
the lower layers provide. If the knowledge layer or the
memory are bad, the context inherits the garbage. It does not compensate: it amplifies.
Implication for the company
For the CIO, context engineering is the layer that makes the agent auditable:
if each answer has its registered context with origin, it can be
explained why the agent answered what it answered. Without it, the agent
is a black box with an assistant’s face.
For the CDO, the context orchestrator is where all the layers
we have built converge (semantics, ontology, graph, RAG, memory) and where
permissions and temporality are applied operationally. It is the layer of greatest
return per unit of complexity, and the most difficult to do well.
For top management, the message is one of consistency: an agent that builds
correct context gives the same correct answer to the same question,
independently of who asks it (within their permissions). That
consistency is what separates a production system from a toy.
Conclusion
Context engineering, operationally, is a context orchestrator:
it classifies the task, resolves the subject, selects the
pertinent dimensions, retrieves from each source, applies the token budget,
formats with structure and registers what was used. Context is not “given”: it is
built, deterministically and auditable, before calling the model.
Today the agent has knowledge, memory and context. It is missing one thing to
be a real agent: to know which part of the reasoning is its own (the
model’s) and which part is the infrastructure’s (the one of the rules, the graph,
the temporality). That division is tomorrow’s topic, and it is one of the
most important architecture decisions of the whole series.
Next article
Tomorrow: What Should the Model Reason About, and What Should Infrastructure Resolve?. We will see why not everything should be resolved inside the LLM,
and how the reasoning is divided between the model (language, generalization)
and the infrastructure (rules, graph, temporality, constraints).
Sources
- Anthropic (2025). “Effective context engineering for AI agents”. —
Definition of context engineering as “the set of strategies for
curating and maintaining the optimal set of tokens during the inference”. - Working definition of the ICE: see series, Day 1.
