“The model has a 128,000-token context” and “the agent understands the
business” are not the same sentence. The former is a technical specification.
The latter is a property of the system. And the distance between the two is
called business context.
Introduction
Yesterday we defined memory: what an agent must remember. Today it is the turn of its
inseparable companion: context. And we take it on by correcting the
most widespread confusion in all of enterprise AI, fed by the model
makers themselves: the idea that a large context window
solves the problem.
It does not solve it. It solves something much more modest: it allows more text
to go into the inference. Which text to put in, in what order, with what permissions and for what
decision, is another problem. And that problem is the one that separates a demo from a
system that operates.
The problem
A services company has connected its corporate assistant to “everything”:
documentation, policies, databases, emails. The model has a
huge context window, so the AI team concluded that “the model
can see the whole company”.
In production, the assistant does things nobody understands:
- A buyer asks “can I approve this 18 % discount?” and the
assistant answers “yes, within policy” — not knowing that the buyer
who is asking only approves up to 15 %, or that the applicable policy is the
2026 one, not the 2024 one that was also in the window. - A support technician requests a customer’s history and the assistant
mixes the histories of three different customers who shared an address
in an attached document. - To the same question, answered to different users, the assistant gives
different answers: to some it shows data they are not allowed to see,
to others it omits information they should have.
In all three cases, the model was not “too dumb”. The problem is that
the context window is a container, not a brain: putting the whole
company in the container does not give it comprehension; it gives it noise, and the model
chooses from the noise without knowing what it is entitled to, what is in force and for what
decision it is being asked to answer.
The concept
Two terms that the commercial conversation mixes up, and that must be separated
once and for all:
- Context window. The model’s technical capacity:
how many tokens it can process in an inference. It is a number
(8K, 128K, 1M). It is a specification of the hardware and the model. - Business context. The situated information that
a concrete decision needs: who acts, on what, at what moment,
under what constraints. It is not a number: it is a set of dimensions
that must be identified and populated.
The dimensions of business context that an enterprise agent needs, in
practice:
- User context. Who asks and what they can see: role, permissions,
department. (In the example: the buyer approves up to 15 %.) - Task context. What is being done and at what point: “discount
approval”, not “general question”. - Temporal context. When it happens: which version of the policy is
in force today, which contract is active now, what expires soon. - Organizational context. Where the structure places the decision: which
unit, which approval hierarchy, which budget. - Historical context. What has happened before: previous decisions,
incidents, the state of the dialogue (memory, day 9). - Transactional context. The concrete state of the object of the
decision: this order, this customer, this contract, with its current
values. - Permissions and risk context. What is allowed to do and how much
risk it carries: thresholds, escalation levels, approval
requirements.
None of those dimensions is “more text in the window”. They are selections
made from different sources, with different rules and as a function of
the decision. And that selection process has a name:
Context Engineering: the design of systems that curate and maintain the
optimal set of information that reaches the inference — the
correct information, in the correct format, at the correct moment — so that the
model can complete the task.
The definition is the one that has consolidated since mid-2025 (Anthropic
formulated it explicitly: “the set of strategies for curating and
maintaining the optimal set of tokens during the inference of an LLM,
including all information that reaches the prompt beyond the prompt
itself”). The step this series adds is that, in the company, context
is not curated by hand: it is built dynamically from the seven
dimensions above, from the layers we have been building
(semantics, ontology, entities, graph, memory). Context engineering
is, in practice, the orchestrator that decides what to bring from each layer for
each decision.
Architecture
In the series diagram, context is the other pillar of
retrieval, alongside memory:
KNOWLEDGE
↑
┌──────────┴──────────┐
↓ ↓
MEMORY CONTEXT
(day 9) (today: business context,
built dynamically
from the 7 dimensions)
Context and memory are two sides of the same coin: memory is
what is remembered; context is what is brought now, and why. And
both feed the same thing: the set of tokens the model is going to
process. The design difference is that context is rebuilt in each
decision (it is not a fixed store), while memory persists.
Use case
The services company, with its discount question. We break it down:
- Problem. The assistant approves or rejects discounts with inconsistent
criteria because it does not know who is asking, which policy is in force
or which threshold applies. - Decision. Validate whether an 18 % discount is approvable by the
buyer who requests it. - Knowledge needed. The discount policy in force and its
approval hierarchy; the buyer’s profile; the customer’s
history; the state of the order. - Data. Policies (PDF, several versions), CRM (customer, profile), ERP
(order), permissions system (roles). - Relationships. Buyer → role → approval threshold; policy →
version → currency; customer → order → line; customer → discount
history. - Context. The user is a junior buyer (threshold 15 %); the
policy in force is the 2026 one; the order is from a strategic
customer with a history of accepted discounts; the decision carries medium risk
(amount above a threshold). - Memory. The last discount to this customer was 12 %, approved;
there is an open negotiation that justifies the exception. - Reasoning. 18 % > buyer’s threshold (15 %) → the buyer cannot
approve it; the 2026 policy allows an exception up to 20 % with
the director’s approval → escalate to the director with the justification
(strategic customer + open negotiation). - Action. Answer “you cannot approve it yourself (threshold 15 %); I have prepared
the exception request for the director with the justification” and
queue the approval. - Infrastructure. The seven dimensions of context built
dynamically (user, task, temporal, organizational, historical,
transactional, permissions/risk) + the case memory + the reasoning
that applies the hierarchy. The huge context window was necessary
but insufficient: without the seven dimensions, the model chose from
the noise.
Trade-offs
- Cost. Building dynamic context is an orchestration system: you
have to identify the sources of each dimension, the selection rules and
the order. It is more expensive than “putting it all in the prompt”. - Complexity. The seven dimensions are not independent: the
permissions context can cancel the historical context (a data point the user saw
yesterday and should not see today). Managing those interactions is the
real work of context engineering. - Latency. Building the context adds steps before the inference.
For low-criticality decisions it may not pay off; for high-impact
decisions it is exactly where the cost is recovered. - Token budget. Even with huge windows, context has a
cost (economic and of the model’s attention: too much context degrades
precision). You have to curate, not accumulate. - Security. Context is the point 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 most important
access control in the system. - Honest limitation: context engineering curates the context that the
lower layers provide. If the semantics, the graph or the memory are
bad, the context inherits the garbage. It is not a compensating layer: it is a
layer that amplifies.
Implication for the company
For the CIO, the lesson is one of expectations: the “large context window”
is a purchase specification, not a property of the system. The property
that must be demanded is that the agent builds the correct context for each
decision, and that is infrastructure design, not model selection.
For the CDO, context engineering is where all the layers we
have seen converge: semantics, ontology, entities, graph, memory. If those layers
do not exist, the context is built on air. And it is also where
permissions and risk are applied operationally.
For top management, the message is one of control: an agent that does not know which
context to bring is an agent that cannot be audited. The context built
explicitly is what allows answering “why the agent answered
that”.
Conclusion
A huge context window is a technical specification: it allows putting
more text in. An agent that understands the business builds business context:
the situated information of the seven dimensions (user, task, temporal,
organizational, historical, transactional, permissions/risk), curated
dynamically for each decision. We call that process context
engineering, and it is the last link of the first half of this series.
We have finished describing what an agent needs: data with
meaning, resolved entities, relationships, retrievable knowledge,
typed memory and situated context. From tomorrow we change the question:
from “what does an agent need?” to “how is the piece by piece
infrastructure that provides it built?”.
Next article
Tomorrow: How to Build a Knowledge Layer for a Company.
We start the second half of the series: the design of the architecture that
integrates data, semantics, ontology, entities, relationships and knowledge in
a layer the agent can use.
Sources
- Anthropic (2025). “Effective context engineering for AI agents”. —
Definition of context engineering: “the set of strategies for curating
and maintaining the optimal set of tokens during the inference of an LLM”. - Working definition of the ICE: see series, Day 1.
