Context for AI Agents: Why Purpose Beats Volume

“Context” has become the word of the moment in agentic data management. As enterprises move AI agents out of pilots and into real business processes, the conversation has settled on a shared diagnosis: agents fail because they don’t understand the business well enough to act on the data.

The remedy on offer is usually more context. Context layers, context graphs, and context engineering are now standard vocabulary, and the working assumption is that the more context an agent can reach, the better it will perform. Even so, Forrester predicts that in 2027 only one in four enterprise context layer efforts will support agentic AI at production scale.¹

That assumption got a real-world test in September at revAlation Chicago, where Alation hosted a hackathon with more than 30 data leaders from enterprise customers. Working in ten teams and guided by a senior Alation leader, they spent four hours building data products and agents for actual business use cases. We've been working through what came out of those sessions, and a pattern stood out: The teams that made the most progress weren't the ones with the most context to draw on. They were the ones that came in with a clear vision, knowing exactly what their context was for.

What we’ve seen from our more than 600 customers is that context without purpose is a swamp: volume with no outcome, owner, or boundary attached to it, which leaves agents as unreliable as before and harder to audit. If you're deciding how much to document, what to certify, or where to start with agents, read on. You'll find what the teams did differently to achieve actionable production context, three disciplines for giving context a purpose, and seven questions you can use to pressure-test your own program.

One metric, many answers

One financial services data leader described a dashboard burdened with hundreds of metrics, where a single core business measure ("Sales") appeared across dozens of reports with conflicting values. Whether someone sat in Marketing or Finance, pulling the sales number for the current fiscal year immediately raised three basic questions: Where does it live? How is it calculated? And which version is certified?

People cope with that kind of ambiguity every day. They ask a colleague, check a Slack thread, or pick the report they trust. An AI agent can't do any of that. It picks one of the versions, answers fluently, and nobody downstream knows the answer was a guess.

This is the situation many data teams are heading into as they point agents at their data estates. It also raises a question that the current advice about AI and context doesn't always address: what happens when we have plenty of context and still no answer?

The prevailing advice, and what it gets right

The dominant message in the market right now is straightforward. Agents need context to work well, so give them as much as possible. Catalog every asset, document every table, and deliver it all to agents at runtime.

There is real substance behind this. Humans can't write every description and definition that AI needs. Documentation has always lagged the data, and AI-drafted metadata can close part of that gap by surfacing knowledge that already exists in how people use the data. Teams that have tried this report real gains.

Even some of the most discussed examples of AI-generated metadata at scale describe something more careful than "use everything." They describe choosing a bounded set of critical assets and putting expert review in front of anything before it goes live. The strongest versions of the "more context" argument already contain a boundary. The disagreement is about how central that boundary is.

Where it breaks: the context swamp

We've started calling the failure mode a context swamp: context built for its own sake, with no outcome, owner, or boundary attached to it.

A swamp has recognizable symptoms.

There are many versions and no certified one. The same metric exists in dozens of places with different definitions, and no one can say which is authoritative. More context makes this worse, because every additional source is another candidate answer.

Ownership and freshness are unknown. Nobody can say who stands behind an asset, when it last changed, or whether the quality checks still run. In the hackathon sessions described below, teams brought up owner, freshness, quality and certification on their own, without being prompted. They reached for those markers because without them, context can't be trusted.

Failure becomes silent. When software is wrong, it usually throws an error. Without semantic context, agents can pick the wrong source, the wrong metric logic or a faulty join, with no way to explain why.² Nobody is alerted, and the error moves downstream into a report or a decision.

There's an older version of this story. Data lakes were meant to make all data available, and many became places where data went to be forgotten. Gartner warned in 2014 that without descriptive metadata and a way to maintain it, a data lake risks turning into a data swamp.³ A darker data lake is still a data lake. If the response to AI is to pour everything into a context layer, with no sense of what each piece is for, teams risk rebuilding the same thing and calling it a new architecture.

Purpose before context

The pattern that held up in our observation was to decide what the context is for before building it. In practice, that means leaders must connect data broadly but curate narrowly.

Work backward from the outcome

The most useful habit we saw was to write down the result before building anything, much like drafting the press release for a product before it exists. What decision will this support, and who will make it? What will be different when it works? Having a clear destination makes it easier to say no to everything that doesn't lead there. Without one, teams tend to wander, and the work expands to fill the available time.

Make the data product the unit of scope

A data product gives context a boundary and an owner. It packages governed data for a specific purpose, and its description states the intent and outcome rather than just listing contents. A table description tells you what columns exist. A good data product description tells you what question the product answers and for whom.

The marketplace adds a feedback loop. If teams aren't sure what to curate next, they can watch what people actually search for and request. Demand becomes a leading indicator of what the business needs, which is a more reliable guide than guessing which domain to document next.

Govern less, on purpose

This is the discipline that tends to feel counterintuitive. Instead of governing everything equally, identify the critical data elements that matter most in your regulatory and operational context, and curate and certify those first. Everything else can remain connected and discoverable without carrying the same level of curation.

We're not suggesting that most of the estate should be ignored. The distinction is between connecting broadly and curating narrowly: bring every asset into view, but be deliberate about which ones you certify, document in depth, and expose to agents as trusted. Teams that can show value from a small, well-governed scope earn the standing to expand it, and over time you will end up governing more.

Where AIOS fits

This is the problem the Alation Intelligence Operating System was designed around. The goal is to keep agents, context, and data current, governed, and improving over time, rather than letting them drift out of sync after the first pilot. Capabilities like CDE management, certified data products, and the marketplace exist to give context a purpose and an owner. The principle matters more than the product: whatever tooling you use, context needs boundaries to be reliable.

What ten teams showed in four hours

The hackathon followed a structured exercise in three steps.

First, each team built a standard data product and agent, mainly to demonstrate how it could be done. Second, each team filled in a single slide that clarified the value of a specific data product for their company: the business outcome, who the consumers are, how it would roll out, what the technical end state looks like, what trust and governance require, and the biggest obstacle. Each team presented that slide to their peers. Third, the group then built their own data products with an agent acting on it.

A few observations stood out.

Writing it down forced concreteness. Teams with a vague idea of the outcome found the gaps quickly when they had to fill in each box, and a facilitator pushed on each answer to make teams defend their framework. Several teams revised their plans after watching others present.

The teams that moved fastest narrowed their scope. They iterated quickly and knew who they were building for. The ones that struggled tended to be unclear on the audience or the outcome.

Every team left with something working. Each produced a data product with an agent acting on it within four hours. These were demonstrations on synthetic data in a demo environment, not production systems. But they were concrete enough to test and argue about, which is where improvement starts.

Curation came first. Several teams planned to start with natural-language chat before they had written descriptions or a glossary. The guidance they received was consistent: curate first, because chat quality depends on the context behind it. Teams that skip this step tend to be disappointed.

The obstacles were mostly about adoption, not technology. The most common concerns were integration with existing infrastructure, buy-in from the business and from technology teams, keeping ownership and access controls current, and the accuracy and speed of chat. Several leaders also noted that the word "governance" can signal extra work to the business. Their approach was to lead with the outcome and the use of AI, and to describe the work in business terms rather than in the vocabulary of critical data elements.

One more detail is worth noting. One team estimated that manually reviewing descriptions took one to three hours per dataset, and said that was no longer sustainable. They were building an agent to check description quality. A leader on that team said metadata quality worried them more than data quality, which is a useful reminder of where AI-era failures tend to begin.

Why this matters to the business

The argument for purpose-first context comes down to four concerns that leaders already track.

Risk. Uncertified, ownerless context is how silent failures happen. Narrower scope with clear owners makes it possible to say what an agent was allowed to rely on and who stood behind it.

Cost. Curation effort and review time are finite. Spending them on assets nobody consumes is a cost that doesn't show up until the budget conversation, and it is a hard one to defend when leaders are being asked what AI spending returns.

Speed. A focused scope ships in weeks, and a broad one tends to stall. Gartner's first recommended step toward AI-ready data is to align data to specific AI use cases.¹ A concrete result in one domain also carries over: a hard number from one line of business becomes the argument for the next.

Credibility. Data and governance teams that can't articulate their value are the ones whose budgets get cut. Gartner says a governance program that does not enable prioritized business outcomes fails, and advises rescoping governance to target tangible outcomes.⁴ A governed data product tied to a measurable outcome gives them something specific to point to.

Where to start

If you're deciding where to begin, a short set of questions can help:

• Can you state the desired business outcome in one sentence before you build? If not, that's the first piece of work.

Can you state the desired business outcome in one sentence before you build? If not, that's the first piece of work.

• Who is the consumer? Name the persona or team, not "the business."

Who is the consumer? Name the persona or team, not "the business."

• Does the data product say what it is for, not only what it contains? Intent and outcome belong in the description.

Does the data product say what it is for, not only what it contains? Intent and outcome belong in the description.

• Which critical data elements matter most for your regulatory and operational context? Curate and certify these first.

Which critical data elements matter most for your regulatory and operational context? Curate and certify these first.

• What are people asking for in your marketplace? Let demand decide what you curate next. Then quantify the value for those products over time based on use.

What are people asking for in your marketplace? Let demand decide what you curate next. Then quantify the value for those products over time based on use.

• Is there one certified answer for every metric that matters? If there are fifty, start there.

Is there one certified answer for every metric that matters? If there are fifty, start there.

• Which single domain can you pilot, and what is the one number you'll track? Prove it there before carrying it to the next.

Which single domain can you pilot, and what is the one number you'll track? Prove it there before carrying it to the next.

The teams in the room described the pace they wanted as a crockpot, not a microwave: put in the right ingredients, let it cook slowly, and something good comes out. The same applies to context. The goal was never the largest possible volume. It was context that agents and people can trust to answer a specific question.

Sources & notes

Every external claim on this page is independently verifiable. The public sources are listed here.

• Forrester predicts that in 2027, only one in four enterprise context layer efforts will support agentic AI at production scale. This is a prediction, not a measurement. Forrester, “Predictions 2027: Artificial Intelligence,” 14 October 2026.

Forrester predicts that in 2027, only one in four enterprise context layer efforts will support agentic AI at production scale. This is a prediction, not a measurement. Forrester, “Predictions 2027: Artificial Intelligence,” 14 October 2026.

• DataHub describes agents without its context choosing the wrong source, wrong metric logic or a faulty join, with no way to explain why. This is a vendor's own account of failure modes it has seen in production. DataHub, "Inside the Context Platform: June 2026 Town Hall Highlights," 24 July 2026 (accessed 19 October 2026). https://datahub.com/blog/inside-the-context-platform-june-2026-town-hall-highlights/

DataHub describes agents without its context choosing the wrong source, wrong metric logic or a faulty join, with no way to explain why. This is a vendor's own account of failure modes it has seen in production. DataHub, "Inside the Context Platform: June 2026 Town Hall Highlights," 24 July 2026 (accessed 19 October 2026). https://datahub.com/blog/inside-the-context-platform-june-2026-town-hall-highlights/

• Gartner stated that a data lake without descriptive metadata and a mechanism to maintain it risks turning into a data swamp. Gartner, "Gartner Says Beware of the Data Lake Fallacy," 28 July 2014. https://www.gartner.com/en/newsroom/press-releases/2014-07-28-gartner-says-beware-of-the-data-lake-fallacy

Gartner stated that a data lake without descriptive metadata and a mechanism to maintain it risks turning into a data swamp. Gartner, "Gartner Says Beware of the Data Lake Fallacy," 28 July 2014. https://www.gartner.com/en/newsroom/press-releases/2014-07-28-gartner-says-beware-of-the-data-lake-fallacy

• Gartner says a data and analytics governance program that does not enable prioritized business outcomes fails, and advises rescoping governance to target tangible business outcomes. Gartner, "Gartner Predicts 80% of D&A Governance Initiatives Will Fail by 2027, Due to a Lack of a Real or Manufactured Crisis," 28 February 2024. https://www.gartner.com/en/newsroom/press-releases/2024-02-28-gartner-predicts-80-percent-of-data-and-analytics-governance-initiatives-will-fail-by-2027-due-to-a-lack-of-a-real-or-manufactured-crisis-

Gartner says a data and analytics governance program that does not enable prioritized business outcomes fails, and advises rescoping governance to target tangible business outcomes. Gartner, "Gartner Predicts 80% of D&A Governance Initiatives Will Fail by 2027, Due to a Lack of a Real or Manufactured Crisis," 28 February 2024. https://www.gartner.com/en/newsroom/press-releases/2024-02-28-gartner-predicts-80-percent-of-data-and-analytics-governance-initiatives-will-fail-by-2027-due-to-a-lack-of-a-real-or-manufactured-crisis-

Analyst Attributions & Disclaimers

Gartner, "Lack of AI-Ready Data Puts AI Projects at Risk" (Q&A with Roxane Edjlali), 26 February 2025. Gartner, "Gartner Says Beware of the Data Lake Fallacy," 28 July 2014. Gartner, "Gartner Predicts 80% of D&A Governance Initiatives Will Fail by 2027, Due to a Lack of a Real or Manufactured Crisis," 28 February 2024.

Gartner does not endorse any vendor, product or service depicted in its research publications and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose. GARTNER and Magic Quadrant are registered trademarks and service marks of Gartner, Inc. and/or its affiliates in the U.S. and internationally and are used herein with permission. All rights reserved.