Don’t Turn Context Into the Next Data Swamp

Context layer series, part 1 of 3
First of three posts on enterprise context for AI. The second covers how to build a context engine. The third covers why context needs its own security model.

Foundation models know a remarkable amount. Context is the knowledge we provide to supplement what the model already knows.

A model understands language, business terminology, industries, software, and a huge body of general knowledge. What it does not know is your business: what you mean by a qualified opportunity, which metric finance treats as authoritative, how you handle a pricing exception, which system wins when two disagree.

That gap is what context fills. It sounds modest. It is the central problem in enterprise AI right now, and most enterprises are about to get it wrong, for reasons that have nothing to do with AI and everything to do with how large organizations behave when a new technology arrives and nobody wants to be the one who missed something.

We have seen this before. We did it with data.

We have seen this movie

Around 2013, the instinct in enterprise data was to collect everything. Storage was cheap, Hadoop could land any file anywhere, and the logic seemed sound: we do not know which data will matter later, so keep all of it.

The data lake was born from that reasoning. So was the data swamp.

A data leader at a large retailer once summed up his environment for me: “We can answer any question. We just can’t tell you whether the answer is right.” Petabytes of data, duplicate tables with different transformations, feeds nobody could trace to an owner, and a business that had quietly stopped trusting the numbers. Governance and lineage were bolted on years later, at considerable expense.

The lesson was not “collect less.” The lesson was that the value of information comes from knowing what it means, who owns it, whether it is current, and whether it can be trusted for the decision in front of you. Storage was easy. Making information usable was the work.

We are about to run the same experiment one level up.

The same instinct, applied to context

Look at the pressures on a CIO right now. The board wants an AI strategy. Every vendor sells “connect everything.” The demos that impress are the ones where an assistant seems to know the whole company. The safe-feeling move is to index every document, capture every conversation, connect every source, and let the model sort it out.

A regional insurer I will call Northbridge Mutual did exactly that. In 2025 they built a “knowledge hub” for an underwriting assistant: forty thousand documents, the full Confluence space, three years of Slack, several shared drives. The pilot demoed beautifully.

Within weeks the assistant was citing a 2019 guideline replaced in 2023, treating a threshold someone had floated in Slack as policy, and applying one state’s rule to another state’s application. Every answer was fluent and confident. Underwriters could not tell which ones to trust, so they checked all of them, which took longer than not using it. Adoption stalled in four months.

The model was fine. Nobody had decided what the model should know.

More context is not better context. The value of context comes from relevance, not volume.

Context is scattered, and there is no end to it

Part of the problem is where context lives.

Some is in systems: how the CRM is configured, what an ERP approval workflow really does, which API gets called before which. Some is in processes: the order a team works a case, the checks people run before signing off, steps everyone follows and nobody wrote down. Some is in documents: policies, runbooks, contracts, playbooks, wikis, usually in several versions. Some is in telemetry: patterns in logs, alerts, and tickets that experienced operators recognize instantly. And a great deal is tribal knowledge in people’s heads: why we do it this way, which signal to ignore, what happened last time someone tried the obvious fix.

That inventory will never be complete. Context accumulates every day, in every team. Some of it becomes wrong the moment a policy changes or a person leaves. There is no boundary around it.

So “capture all of our context” is not a project with a finish line. It is a chase with no end, and the more you catch, the more you have to keep current, reconcile, and govern. Treating context capture as a completeness exercise is the fastest route to the swamp.

The useful question is not how much context we can gather. It is which context a given task needs.

There is no universal context

Context is task-specific in a way data is not.

A revenue analyst asking why bookings fell in a region needs definitions of bookings and pipeline, the fiscal calendar, territory changes, pricing changes, known one-time events, and how similar patterns were read before.

Someone approving a discount for one of those same customers needs something entirely different: discount authority, margin thresholds, strategic account status, contractual commitments, prior exceptions, approval policy.

Same company. Much of the same data. Different context.

This is why one universal context, collected once and handed to every AI system, does not hold up. Plenty of knowledge can contribute: metadata, lineage, documentation, policies, conversations, prior decisions, human expertise. Its value depends entirely on the task.

The problem is selection, not collection

Every additional piece of context is another judgment call for the system. Is it relevant? Current? Authoritative? Does it contradict something else in the pile? Was it written for this geography, customer, product, or point in time?

As context grows, the model is not becoming better informed. It is receiving more signals it has to reconcile, and models are very good at reconciling. That is the danger. Northbridge’s assistant never reported that the 2019 guideline conflicted with the 2023 one. It picked one and answered smoothly.

So the hard question becomes: given a task, what is the smallest useful set of knowledge to bring into it?

Semantic similarity does not get you there. A document can be closely related and still be the wrong one. A policy can be relevant and outdated. A prior decision can look identical and have been made under different circumstances. A good context system has to understand the task, who is performing it, which systems and data are involved, what is authoritative, what has changed, and what should be left out. Retrieval becomes an intelligent process in its own right. That is the subject of the next post.

Context is only useful next to data

Nobody comes to AI because they want context. They want to do something: understand why revenue changed, resolve a customer issue, reconcile invoices, have an agent complete a workflow across systems.

Those tasks run on data. Context tells the system how to interpret it. A revenue number without context is ambiguous. Context without the number cannot answer the question. A shipment delay is data; the supplier history, the SLA, and the exception policy are the context that tells you what to do about it.

Data and context should not be two separate concerns in two separate systems. They need to meet at the moment of the task.

Your context is yours

Much of the most valuable context is not generic knowledge. It is accumulated know-how: why sales handles this account type differently, why operations distrusts one signal, why an exception is allowed for one customer and not another.

Two companies running the same CRM, ERP, and warehouse can have entirely different context around how they operate them. As models commoditize, that context will not. It may become one of the most differentiated forms of IP a company has, and one of the most sensitive. That is the third post.

Sufficient context, not maximum context

The big data era taught us that collecting information is not the same as making it useful. AI is a chance to apply that lesson early.

The goal is not the largest context repository. It is a system that delivers sufficient, reliable, task-specific context when it is needed. That means being deliberate about three problems:

• Gathering. Where does knowledge live, and how do we capture it without hoarding it?/li>
• Organizing. How do we understand authority, conflicts, freshness, and provenance?
• Retrieving. How do we find exactly what a task needs, and nothing more?

If you are being asked to fund a context initiative, four questions are worth asking first:

• What are the first five tasks this context will serve, specifically?
• Who decides what is authoritative when sources disagree?
• When the system gives an answer, how will we know what it used?
• What should this system explicitly not know?

Those questions lead somewhere more interesting than “where should we store context?” The real question is how to build a context system that understands enough about the task to know what knowledge matters.

Because if we get this wrong, the next great enterprise data swamp will not be made of data at all. It will be made of context.