The ML Engineer means the tokens inside the model’s context window. The Information Architect means the business meaning behind a business term. The Product Owner means what the user is actually trying to accomplish. All three are right. All three are talking about something genuinely different. And because of this, “we need better context for our AI” becomes a sentence that everyone nods at and no one can act on, because each person is picturing a completely different thing.
Context is not a thing. It’s a relationship.
Nothing is context in the abstract. Information is only context for something, for someone, for a purpose, at a moment. A customer’s churn risk is context for a retention agent and noise for a payroll run. Last quarter’s board deck is context if the task is forecasting and clutter if the task is resetting a password.
This is why the term feels slippery. People instinctively treat context as a substance (“we have a lot of context”) when it’s actually a relation (“this is context for that task”). Once you accept that context is relational, the obvious next question is: relative to what?
That’s where the three meanings separate cleanly. They’re not competing definitions. They’re three different altitudes of the same stack.
Altitude 1: The window
Context as what the model can see right now
This is the narrowest, most literal, and most precise meaning. To the AI model, context is simply the set of tokens present at inference time: the system instructions, the user’s message, the tool definitions, the retrieved documents, the conversation history, the runtime state. That bounded window is the entire universe the model can reason over for a given turn. Anything outside it doesn’t exist as far as that response is concerned.
The discipline most associated with this altitude is context engineering, which in 2025 began to overtake prompt engineering as the thing serious teams obsess over. The shift matters. Prompt engineering asks, what words do I use? Context engineering asks, what configuration of information should occupy the window, so the model is most likely to do the right thing? It’s a systems question, not a wording question. (Andrej Karpathy and others have written about this shift explicitly.)
Here is the counterintuitive part that many data professionals get backwards: at this altitude, more context is worse, not better. The instinct is to “give the AI all our data.” That instinct is a trap. Anthropic’s engineering team frames the context window as a finite resource with diminishing returns. The model has a limited “attention budget,” and every token you add spends some of it. Researchers have a name for what happens when you overfill the window: context rot. As the token count climbs, the model’s ability to accurately recall and reason over what’s in there actually degrades. A bigger window isn’t a bigger brain. It’s just more room to bury the signal.
So the goal at Altitude 1 isn’t abundance. It’s the smallest set of high-signal tokens that makes the desired outcome likely. Curation beats volume. That single sentence reframes most enterprise AI strategy.
Altitude 2: The meaning
Context as what your data actually means
Before any token reaches the window, something has to decide which tokens. And to do that, it has to know what your data means. This is business context; the altitude information architects are standing at when they say the word.
A model handed a raw table sees columns and values. It doesn’t know that rev_amt is recognised revenue and not bookings, that one of your four “customer” tables is the canonical one, that “active user” was redefined last quarter, or that EMEA numbers exclude a subsidiary for compliance reasons. None of that lives in the data. It lives in the heads of your analysts and in the gap between what the data says and what it means.
The infrastructure that closes this gap goes by several names: the semantic layer, the context layer, the knowledge graph, the ontology, the business glossary. They are all doing the same fundamental job: encoding meaning so that something other than a human can use it. Metric definitions, entity resolution, relationships, business rules, governance, and lineage that lets you trace why a number is what it is.
The payoff is significant. Research suggests that AI agents querying through a well-built semantic/context layer are substantially more accurate than agents firing SQL directly at a warehouse, because the layer hands them consistent, governed definitions instead of leaving them to guess. The reason most agent pilots stall before production isn’t that the model is too weak. It’s that the agent doesn’t share the business context a human analyst carries implicitly, and so it confidently returns the wrong “revenue.”
Two things are worth separating here. A semantic layer classically governs structured data: your metrics and dimensions in the warehouse. But the vast majority of what an enterprise knows actually lives in unstructured form: contracts, specs, manuals, policies, etc. The emerging idea of a context layer extends the same meaning-making discipline across both, so an agent can reason over everything the organisation knows, not just the rows in a table. Either way, the principle is identical: this altitude is about durable, governed meaning. It’s the reservoir the window draws from.
Altitude 3: The intent
Context as intent, situation, and organisational action
The same request can mean very different things depending not only on who is asking, but on the organisational situation in which it appears. “Show me revenue by region” isn’t a single task. From a CFO during quarter-close, it is a request for certified, auditable numbers suitable for executive decision-making. From a sales manager in a pipeline review, it may be a directional view used to spot emerging patterns. From an analyst exploring a hypothesis, it may be a starting point for further investigation rather than a final answer. The words are the same. The operating context is not.
This is why context at this altitude includes user intent and the surrounding conditions of action: the business process underway, the user’s role and authority, the decision at stake, the constraints of time and policy, the acceptable level of uncertainty, and the consequences of being wrong. In enterprise settings, an answer is rarely consumed in isolation. It feeds a workflow, informs a decision, triggers an action, or becomes part of a control process. That operational setting is genuinely context, because it determines what information is relevant, what level of precision is required, and what form the answer must take.
Without this altitude, systems easily become contextually naive. They may retrieve the right documents, apply the right definitions, and still produce the wrong answer for the actual situation. A technically correct response can be operationally useless if it ignores whether the task calls for speed or auditability, exploration or compliance, recommendation or execution. The failure isn’t in the model’s reasoning alone. It is in the absence of the organisational frame that gives the task its meaning in practice.
This is also the hardest kind of context to encode, because much of it is implicit. Humans infer it from roles, routines, timing, stakes, and shared institutional knowledge. Machines don’t. Someone has to make it legible: by capturing user role and permissions, identifying where a request sits in a business process, representing policies and risk thresholds, and carrying those signals forward into retrieval, reasoning, and response generation.
Seen this way, operating context sets the target for everything downstream. It answers the question: what are we actually trying to do here, in this organisation, in this process, at this moment, and under these constraints? Without that answer, even strong models with rich knowledge and large windows are liable to solve the wrong problem well.
Putting the three together
These altitudes aren’t rivals. They form a flow:
- The intent (operating context) sets the target: what are we actually trying to do, for whom, right now?
- The meaning (business/knowledge context) is the governed reservoir of what everything means.
- The window (machine context) is the destination: the curated slice of meaning that, guided by the operating context, actually reaches the model.
Read it as a sentence: The operating context decides what matters, the meaning layer supplies it in a form a machine can trust, and the delivery layer decides how the right slice flows into the finite window at the right moment.
Information context without operating context retrieves the wrong things precisely. Operating context without a meaning layer asks good questions of data the machine can’t interpret. Both without disciplined window management drown a capable model in its own attention budget.
This is also why context engineering is often misfiled as a purely technical problem. The term was born at the window, but the discipline reaches across all three altitudes. Defining what “revenue” means is data governance. Structuring meaning so a machine can navigate it is information architecture. Capturing intent and institutional knowledge is knowledge management. Modeling entities and relationships is semantic modeling. Deciding what finally enters the window is ML engineering. Context engineering is the seam that stitches these disciplines together. When organisations staff it as one team’s job, that is usually the moment it quietly fails.
So, when someone says “context,” ask three questions
The next time “we need better context” lands in a meeting, don’t nod. Disambiguate:
- Context for whom? The model, the agent’s reasoning, or the business? (Which altitude?)
- Context of what kind? Tokens in a window, governed meaning, or intent and situation?
- Context for what moment? What task, what user, what stakes, and why now?
If the people in the room can’t answer those three, you don’t really understand context. You just have a word everyone likes.
And notice the through-line across all three altitudes, because it’s the thing the hype keeps getting wrong: context isn’t volume. It isn’t “feed the AI everything.” It’s the right information, in the right form, at the right moment, for the right purpose. More isn’t the goal. Relevance is. A model degrades under too much context exactly the way a person drowns in a 400-page brief ten minutes before a meeting.
The organisations that win the next phase of AI won’t be the ones with the biggest models or even the most data. They’ll be the ones that did the unglamorous work of contextualisation: building the meaning layer, capturing intent, and engineering what actually reaches the window. That work spans governance, architecture, knowledge management, and engineering at once. That’s not a feature you buy. It’s a discipline you build.
Context isn’t a thing you have. It’s a relationship you engineer. And engineering that relationship across all three altitudes already has a name: Enterprise Architecture.