Conference season just wrapped, and I spent most of it on the road — and in the room for more keynotes than I can count. One word ran through nearly all of them. Vendors could not stop talking about “context.”
Here’s why: An AI model will hand you a fluent, confident answer without knowing enough about your business to get that answer right, and context is what closes that gap. It’s the information a system pulls together at the moment it has to act. For instance, a support agent about to approve a refund needs the return policy, the customer’s history, information about the product in question and the rule that allows the exception. Give it just one wrong piece and the answer can come back confident and wrong. This is a nuisance for many people who are using generative AI purely to draft text. But with agents empowered to issue a refund or update a sales forecast, that mistake can cost a business a lot of money.
So just about every vendor in data, analytics and AI now promises to deliver trusted context, and each one says that its product or platform should be the place where that context lives. The money these vendors are investing backs up their talk. IBM paid about $11 billion for Confluent to put real-time data under its agents, and Salesforce spent roughly $8 billion on Informatica for a governed data foundation beneath its own. And those are just two big examples of the several acquisitions that have occurred lately.
The trouble is that context is a loose word, loose enough that companies that operate in storage, databases, business intelligence, observability, data protection, governance, security and business applications can all claim to sell it. The tricky part is, they’re all telling the truth. But if you ask how they actually produce context, they part ways fast, because they are solving different problems.
Rival Camps Are Selling The Same Word
One vendor camp says you earn context by defining it before the AI ever runs. You decide what your terms mean and write them down in a central location so every tool draws on the same definitions. The most established version is the semantic layer, where a term like “active customer” or “net revenue” gets one agreed definition instead of the five conflicting ones scattered across dashboards. Analytics leaders like Qlik, Strategy, ThoughtSpot and Domo, semantic specialists like AtScale, and the big cloud providers have all sold some form of this for years, and now they are messaging it as context for AI.
Push past the semantic layer and you reach the ontology, a map of how the whole business connects, so the software can follow the chain from customer to order to product to contract without guessing. That part is newer, and for many of these vendors it still sits on the roadmap rather than in the product. Palantir is the exception that built its business on ontology, modeling a company’s entire operation before turning AI loose on it. The payoff is trust, since a system looking up a defined meaning is not guessing. The drawback is that modeling a business by hand has always been slow and expensive, and it is sure to be one of the first line items cut when budgets tighten.
Then there is the retrieval camp, which finds up-front modeling too slow and bets on the model instead. You point the AI at your documents, tickets and logs and let it pull in whatever looks relevant. This is the basic approach of the now well-known retrieval-augmented generation. It’s why a new role — the context engineer — showed up this year to design what an agent sees and when. The appeal is speed, because there’s no year-long modeling project. You aim it at your data and go.
The catch shows up in production, where a model that retrieves text resembling the question still doesn’t understand how the business fits together. It readily invents connections that aren’t there, and naive single-pass retrieval still struggles once a task takes more than one hop. Newer agentic and graph-based retrieval are addressing that problem, though they do it by bolting structure back on. For a consumer who wants AI to help with quick day-to-day stuff, retrieval generally works fine, as long as you’re reviewing the responses and can spot when something isn’t correct. But for a business? It’s becoming more and more of a tough sell by itself.
Both of these approaches assume the data is already in hand. Storage and infrastructure vendors make their case a step earlier, at the layer where the data physically sits. Dell, NetApp and the newly renamed Everpure argue that before you can define meaning or infer it, you have to find your data, label it and move it to the model fast enough to keep expensive chips busy. Dell folded an AI-data startup called Dataloop into its lineup to do exactly that, and Everpure bought a data-intelligence company 1touch the same week it retired the Pure Storage name earlier this year.
These vendors’ currency is metadata, the data about your data. For that refund order mentioned above, things like the purchase date, payment method and warranty status all help describe it without being it. That descriptive layer of metadata is what makes any record findable and safe to use. Moving the right bytes to the model fast is necessary work, but metadata alone isn’t enough. That order’s date, payment method, and warranty status still don’t tell the model whether the customer counts as active, whether the refund comes out of net revenue, or which rule lets the agent approve it. That meaning comes from defining terms up front, like one does with a semantic layer and ontology, and no amount of metadata produces it.
A different worry drives the governance and data-quality crowd. Collibra, Alation and Atlan, along with data-observability players such as Acceldata and Monte Carlo, argue that any context an AI cannot vouch for is a liability. If an agent acts on data that is stale, wrong, or off-limits to a given user, a faster model just reaches the bad outcome sooner. They emphasize that lineage, quality and permissions are what decide whether context is safe to act on, and their case only gets stronger as agents move from suggesting things to doing them. Informatica has leaned hard into this, pitching itself as the trusted data layer that sits underneath everyone else’s AI stack. Data-protection and security vendors make a related case. The data an agent can reach has to be recoverable and accessible to the right people before it counts as context you can trust.
Why The Data Platforms Start With An Advantage
The biggest players do not need to pick just one of these approaches; they host all of them. Snowflake, Databricks, Oracle and the data engines inside Google, Microsoft and AWS assemble context directly on top of data they already store, while everyone else has to reach that data first and keep it current. It’s a head start the rest of the field is chasing through integration and acquisitions.
What the platform vendors are racing to build is that ontology, the map of the whole business, now assembled on top of the data they already hold. The running version of it is a knowledge graph, which is the live network of entities and relationships an agent actually queries. Snowflake is getting there by separating the context a customer declares from the context the platform derives on its own. Databricks put a knowledge graph under its Genie tools. Microsoft brands its version Fabric IQ. Google Cloud wired the same idea through what it now calls its Agentic Data Cloud and Knowledge Catalog. Most of these offerings are still in preview, and the promise that every agent will inherit your definitions describes where these products are heading more than where they are today. Drop any of them into a real enterprise, and the first thing it will expose is how inconsistent your current definitions are.
There is a different type of player in this fight, too — the application vendors — and they sell context about how your company runs rather than what your data means. Microsoft, through Copilot, maps how your people, files and meetings connect. Salesforce wires customer data straight under its agents, and ServiceNow does the same inside its workflows, which is why it bought the data catalog and knowledge-graph company data.world. The pitch from all of them is convenience: Your work already lives with us, so let us switch on the context for you. The catch is that the layer making all your AI useful then belongs to a vendor rather than to you.
Own The Meaning Even When A Vendor Builds It
If you’re an enterprise technology leader being sold all of this, what are you to do? Who do you pick? The storage vendor, the data platform, the analytics tool, the governance suite and the application suite each insist they are the right home for your context, and for every vendor I’ve named here there are a dozen more making the same case. Almost none of them will give you the honest answer, which is that no single vendor covers all of it. Your context is scattered across all of those systems, so in practice you will pull it from several. And if each one assembles its own version, you will inevitably end up with competing versions of the truth — the same inconsistency that made people stop trusting their dashboards a decade ago.
Carry one question into every pitch: Do you still own the meaning underneath the context, whoever builds it for you? What protects you from those competing versions of the truth is to control the layer that defines what your terms mean, so that, whichever system answers a question, it draws on the same definitions — no matter who stores or serves the data. Treat that layer as yours even when a vendor builds it, the same way you would never hand a competitor your customer list, and include the right to export it in a portable format in the contract. Addressing this challenge is also why a group of vendors, convened by Snowflake, floated an open standard called Open Semantic Interchange. Plenty of folks have waved that off as a committee project, but its real value is portability. The wrinkle is that the platforms racing to own the layer where your meaning lives are the same ones shaping the standard meant to free it, so the right to export needs to live in your own contract.
Holding that export right is what lets you bet on a platform to build the layer in the first place. If I had to place that bet today, I would back the players who can build and maintain that map cheaply and already sit on your data, which points more to the large platforms than to any single-purpose tool. The teams relying on retrieval alone look the most exposed. I hold that view loosely, because the same advances in AI models that make an ontology cheap to build could make some of them unnecessary.
None of this solves the hardest part, which is that past a certain point, more context makes the answer worse. The facts that matter get buried in noise, and every extra token costs money and time on every request. The winners in this market will be the ones that assemble the right context cheaply and the same way every time. Gathering more context is the easy part. The companies that crack the problem of gathering the right context will likely be worth far more than the ones selling plumbing today.
Moor Insights & Strategy provides or has provided paid services to technology companies, like all tech industry research and analyst firms. These services include research, analysis, advising, consulting, benchmarking, acquisition matchmaking and video and speaking sponsorships. Of the companies mentioned in this article, Moor Insights & Strategy currently has (or has had) a paid business relationship with AWS, Dell, Everpure, Google, IBM, Microsoft, NetApp, Oracle, Salesforce and ServiceNow.
