"Context" is doing four different jobs in your AI strategy

Sit in enough AI planning meetings and you will hear context used as though it were a single substance you can have more or less of.

It is not. Four distinct problems currently travel under the word. They have different owners, different costs and different failure modes, and the reason this matters is not linguistic tidiness.

One: what fits in the window

The most literal meaning — how much material a model can consider at once.

A technical constraint that has loosened dramatically and is frequently mistaken for a solved problem. Larger windows let you put more in front of the model. They do not guarantee it attends to all of it, and they do not make it cheap; cost and latency scale with what you actually send. A large window is a capability, not a strategy.

Owner: whoever builds the application. Failure mode: assuming that because everything fits, everything is used.

Two: what the system retrieves

The engineering meaning. Getting the right material in front of the model at the right moment — the documents, records and history relevant to this particular request.

This is where most enterprise AI projects actually live, and where most struggle, because retrieval quality is determined by the state of the underlying content. If your documents are duplicated across four systems, three versions deep, with no reliable indicator of which is current, retrieval will surface all four with equal confidence. The model is not the problem in that scenario and no amount of tuning will make it one.

Owner: data and platform engineering. Failure mode: treating a content problem as a model problem.

Three: what the organization knows and has never written down

The interesting meaning, and the hardest.

Every process carries knowledge that exists only in the people who run it. Which customers you flex payment terms for. Which supplier’s claims get checked twice. Why that account is coded oddly. None of it is written anywhere, because the people who know it never needed to write it down for each other.

This is the context that determines whether an automated process produces the right answer or a defensible-looking wrong one. It cannot be retrieved, because it was never recorded. It has to be elicited — which is slow, and the people holding it have the least time.

Owner: nobody, currently. Failure mode: assuming it gets captured as a by-product of the project.

Four: what an agent carries between steps

The newest meaning, and the one causing most confusion, because it uses the same word for a different substance entirely.

When a system takes multiple steps, something must persist between them: what has been tried, what was learned, what the goal was. This is state management. It is an architectural problem with decades of prior art under other names, and calling it context borrows credibility from the other three meanings while obscuring that it is a well-understood engineering problem with known solutions.

Owner: the application architect. Failure mode: designing it implicitly, then discovering that behavior depends on accumulated state nobody can inspect.

Why the conflation is expensive

These four have almost nothing in common except the word.

One is a purchasing constraint. Two is a data engineering program. Three is an organizational elicitation exercise that may take years and has no obvious owner. Four is systems design.

So a strategy that says we need better context is not a strategy. And there is a specific pathology to watch for: meaning three — the expensive, unglamorous one — gets quietly absorbed into meaning two, because retrieval has a budget line and tacit knowledge does not. The project then delivers a working retrieval system and a set of answers that are confidently wrong in exactly the ways only an insider would catch.

Ask which one they mean

Insist on the distinction in the room. When someone says context, ask which of the four they mean. It is a mildly irritating question and it will save you a quarter.

Then assume the third is your real constraint, because it is the only one with no owner, no budget and no vendor. Retrieval you can buy. Window size you can pay for. State management is engineering. The knowledge your experienced people have never written down will determine whether any of it works, and the only way to get it is to ask them — early, before the architecture assumes it away.

Related Reading

• Enterprise Search & RAG Platforms
• Vector Database & AI Search
• AI Agent & Agentic AI Platforms
• Enterprise Content Management (ECM)
• An executive guide to open-weight models
• Most of your agent projects should be workflows
• Ten Google engineers explained why ML systems rot. Most MLOps advice still ignores them.
• From Models to Systems: How Enterprise AI Actually Gets Built
• Generative AI Operating Models: How CIOs Are Structuring AI Governance