Why Context Preparation Is Important (and Not Only for Agents)

By: Sat Duggal

08.18.26

TL;DR

Context preparation turns institutional knowledge (including lineage, metric definitions, ownership records, and the queries analysts already trust) into a context graph that both agents and people can query. It’s important because an AI agent inherits the tables without inheriting the judgment that a human analyst would have applied to them.

However, the standard framing of context preparation implies the humans querying data are interchangeable. We all know they aren’t. Institutional knowledge concentrates in a few tenured people and thins out for anyone new, covering an unfamiliar domain, or niched down into one corner of the estate.

Agents did not create that gap. They removed the ability to work around it, because an agent fails confidently and at scale where a new hire fails quietly and gets corrected.

DataHub’s 2026 State of Context Management Report found that 66% of organizations report AI models generating biased or misleading insights due to low context maturity, and 57% find it challenging to identify authoritative data sources

Data prep has always run on a quiet assumption that a competent human sits on the other end of the query and supplies the meaning. The analyst knew which table was the right one, which definition of “revenue” applied, which dashboard the CFO really trusted. They held this information and the arrangement worked. And then along came AI agents and they broke that arrangement because they didn’t carry that innate knowledge and experience. The judgement now needs to be written down so that it’s retrievable to agents. And that’s why most organizations are looking into a context platform right now.

It’s a story that feels right and makes sense, but it’s only half of it: The humans were never quite so reliable in the first place. In reality, we know there’s incredible variability across individuals and teams, and one analyst may know something that another doesn’t, that a new employee can only guess at, that gets lost with team turnover. We’ve just been tolerant of those inconsistencies in a way we can no longer be with AI agents.

Understanding context preparation

Quick definition: What is context preparation

Context preparation is the act of activating institutional knowledge for machine consumption. It takes the artifacts that carry organizational meaning, including lineage, business glossary terms, ownership records, documentation, runbooks, and curated queries, and turns them into a queryable context graph. Data preparation produces clean tables. Context preparation produces retrievable meaning.

The distinction between context preparation and data preparation matters because they solve different problems, and most organizations are only thinking about one:

  • Data preparation takes raw data and standardizes formats, corrects errors, and combines datasets so the output is analytically usable
  • Context preparation layers meaning on top of that output so a data consumer who lacks organizational memory can still interpret it correctly

The two ideas run in sequence, not in competition. If you skip data prep, the context graph can point to unreliable data. If you skip context prep, you can have clean data, but users may have gaps in what it means. That second problem is not a data quality problem, which is why throwing more data quality work at it rarely helps.

Data quality tells you whether the numbers are right. Context tells you which numbers to use, and what they mean. This is a problem that sits with humans (where it has been quietly tolerated).

The problem started with people, not agents

You’re the analyst the warehouse was built for: Six years in the role, fluent in the quirks, able to tell a data glitch from a real market signal on sight. You’re the one people tap on the shoulder, the one who has had access to and has retained vast institutional knowledge.

The problem is that most people querying your data are not you.

The first-week hire is not you. Neither is the analyst who changed teams last month, or the one returning from parental leave, or the analyst who inherited a domain when its owner left. Each of them queries the same clean tables and gets none of the interpretive layer that you hold inside you, the information that makes the table trustworthy. Their solution? They ask around, likely tapping your shoulder.

This is a workplace reality we can all relate to, and it’s a gap that runs along tenure. Some people have the context, some don’t, and the ones who don’t know to come and find you.

The second version runs along a different line entirely, and it’s the harder one: two people who are both “the expert,” in two different domains. Finance defines conversion one way, product defines it another. Both definitions have been in use for years, encoded into dashboards, showing up in KPIs and monthly reports. Either the teams don’t know there’s an incongruity or each has reasons for the version it uses. Nobody double-clicks on it until those two teams collide.

The 2026 State of Context Management Report found that 57% of organizations find it challenging to identify authoritative data sources. We’ve all been working around this, and the moments it shows up are just part of the job: It showed up as onboarding time, as Slack threads, as two decks in the same meeting reporting different numbers for the same metric, and everyone shrugging because that is just how it goes. Teams come up with on-the-spot workarounds, but the deeper fix is rarer.

Agents didn’t create this gap, but they exacerbate it

The human version of this problem is mostly quiet: New hires pull the wrong table, somebody nudges them the right way, and the organization carries on without naming the problem. The correction loop is slow and erratic, but it exists.

An agent doesn’t have this loop: It’s going to retrieve the most popular pattern rather than the most accurate one. And it will format the answer clearly and return it with complete confidence. Nobody catches it because there’s no signal that anything went wrong, and the degrees of “human-in-the-loop” are variable too. Gartner predicts that more than 40% of agentic AI projects will be canceled by the end of 2027, and this failure mode is a large part of why.

Scale is compounding the problem too: One new hire making an interpretive error is something most organizations can absorb. An agent making errors in every response or to every user who asks a variant of the question becomes a lightning rod that’s now expensive enough to find a solution to.

The 2026 State of Context Management Report puts numbers on where organizations land:

  • 66% report AI models generating biased or misleading insights due to low maturity in providing sufficient context
  • 57% are duplicating AI efforts across departments because no unified context graph exists, which is the organizational version of the same problem: teams solving context locally because there is nowhere to solve it centrally.

What does the gap cost when nobody closes it?

The gap shows up in different ways:

  • The knowledge exists somewhere but is hard to reach reliably
  • The knowledge has never been spelled out at all

When the knowledge exists but nobody can reach it

Pinterest ran into this problem at scale: Its data platform had grown alongside the product without governance keeping pace, leaving more than 400,000 tables, 500 new ones created daily, and no lifecycle policy. The institutional knowledge existed. It just sat somewhere analysts could not get to.

Analysts spent their time reverse-engineering trust, going through code, tracing lineage, and dropping Slack messages hoping someone would respond. The knowledge existed, but it was buried, tribal, and impossible to verify.

Aman GairolaEngineering Manager, Pinterest

Note what analysts were spending their time on. Not analysis. Reconstruction of context that other people already had.

Pinterest’s fix combined tier-based governance requirements with AI-generated documentation and lineage propagation, cutting manual documentation effort by roughly 70% and reducing 400,000 tables to 100,000 curated, AI-ready assets.

The outcome that matters most is that patterns developed by one team became retrievable by any analyst in the company. Knowledge that used to live in individual heads or unanswered Slack threads now surfaces through a plain-language question.

When the knowledge was never spelled out at all

FIS had the harder version. They build software for more than 20,000 bank clients whose systems process 75 billion transactions a year, and the relevant data sat on a mainframe where column names carry no semantic meaning at all. A few letters and numbers, indistinguishable at a glance.

Automated approaches close part of a gap like this. Databricks Genie’s ontology derivation got FIS partway there by inferring structure from what the systems already contained. Then it stopped, precisely where the undocumented knowledge began.

That got us honestly about halfway there. In any large enterprise, the real knowledge is gonna be tied up in people’s heads, and I don’t know anybody that’s writing an adapter yet that can go into someone’s brain and pull that out.

Frank ShowalterVP of Data Engineering and Governance, FIS

The obvious instinct is to get everybody in a room, hash it out and write it down. DataHub’s internal research, cited in FIS’s account of the project, found that documenting a single table properly takes roughly 16 hours of workshop time. Run that across 500 business-critical tables and you are looking at 8,000 hours, or about four years of one person’s working time, before an agent can operate reliably on any of it.

Workshops also surface the disagreements nobody knew existed, and then the room has to settle them. That part isn’t a failure. Somebody does have to decide whether finance or product owns the definition of conversion, and no tooling makes that conversation go away.

The problem is that a workshop is a poor venue for it. The conflict surfaced because somebody happened to book a room, not because anything was watching for it. It surfaced for the dozen tables on the agenda and not the hundreds that weren’t. Moreover, whatever gets decided lives in the workshop notes, not anywhere an agent or a new hire will find it six months from now.

What closes the gap for agents and people alike

Both versions need the same fix, and it isn’t a better-organized workshop. You need one place where meaning gets gathered, conflicts get resolved, and the result stays available long after the people who settled it have moved on. That is an infrastructure requirement, not a tool you install. A context platform provides that infrastructure. That’s what the DataHub Context Platform does, through four capabilities.

1. Unifying what’s scattered

Context Ingestion pulls semantic definitions, technical metadata, and unstructured institutional knowledge from across the stack into a single context graph. Metric definitions in dbt, join logic in a BI tool, and business knowledge in Confluence or Notion stop being separate lookups. The knowledge that was siloed in whoever has been there longest gets a location that outlives them.

2. Generating what was never written down

Context Intelligence extracts semantic meaning from signals that already exist, including query history, BI dashboards, and dbt models, and turns them into validated metric definitions and join patterns. That changes the arithmetic. Instead of 16 hours of workshop time per table before agents become useful, you start from how analysts have already used the data, and save the human effort for the gaps that signal cannot fill.

3. Validating what conflicts

Context Hub doesn’t settle the argument between the two teams who define conversion differently. It gives that argument a trigger, a venue, and an outcome that persists. Auto-generated context captures how data has been used, not how it should be used, so a wrong but popular pattern arrives looking exactly like a correct one.

Context Hub doesn’t settle the argument between the two teams who define conversion differently. It gives that argument a trigger, a venue, and an outcome that persists. It routes those conflicts to the domain experts who can resolve them, as a structured decision to approve or correct rather than a blank page to author from. (More on why this step is load-bearing in Why AI Agents Need Human-Validated Semantic Context)

4. Delivering it wherever the question is asked

Context Activation turns context retrieval into something every agent shares, through MCP, APIs, SDKs, and prebuilt skills, so the same definition reaches Claude, Snowflake Intelligence, Databricks Genie, or a custom agent without being rebuilt per tool. Whoever asks, the relevant context arrives the same way. It also reaches the person three weeks into the job who is searching rather than querying. One validated definition, retrieved by whoever asks.

Pinterest‘s Analytics Agent, built on this kind of foundation, became the company’s most-used internal agent, running at 10 times the usage of the next and adopted by 40% of its analyst population within two months. Adoption at that level is not a story about agents outperforming people. It is a story about people finally reaching context that was already theirs.

The assumption, revisited

Data preparation assumed a competent human would supply the meaning. Context preparation stops assuming. It means treating context as infrastructure rather than as documentation somebody will get around to, and writing the meaning down where anyone can retrieve it.

That is worth doing for the agent you are about to deploy. It’s also worth doing for the analyst who starts next Monday.

FAQs

Context preparation is important because clean data alone does not carry meaning. AI agents retrieve well-formatted numbers without knowing which definition applies, which table is authoritative, or whether a metric was redefined last quarter. Data teams face a quieter version of the same problem whenever someone queries outside their domain. Context preparation turns the interpretive layer into something both can retrieve.

No, though the two get conflated. Context engineering is the runtime discipline of curating what goes into a single agent’s context window on a given task, deciding what to retrieve and how to fit it within the limits of large language models (LLMs). It grew out of prompt engineering as agents moved beyond one-shot requests. Context preparation is the upstream work of building the layer that context engineering retrieves from. That distinction matters at budget time, because context engineering done per application is unsustainable without shared infrastructure underneath it. Every team ends up building and maintaining its own. We cover the distinction in context engineering vs. context management.

Both. Agents are the reason most organizations are funding it, because agents fail confidently and at scale. But the underlying gap predates them. Institutional knowledge concentrates in tenured people and is thin or absent for new hires, team switchers, and anyone covering an unfamiliar domain. A context graph makes the same validated meaning retrievable regardless of tenure.

Context Intelligence works backward from signals that already exist rather than asking teams to author documentation first. It mines query history, BI dashboard logic, dbt models, and unstructured docs to extract metric definitions, proven joins, and the analytical intent behind recurring questions. That solves the cold-start problem, since the domains your analysts query most heavily get context first. Context Hub lets subject matter experts review, refine, and add context directly rather than routing it through the data team.

Auto-generation surfaces both definitions and has no way to choose between them, so an agent retrieves whichever is more popular and answers with equal confidence either way. Context Hub is built for this case. Conflicting definitions get routed to the domain experts who can adjudicate them, presented as a specific proposal to approve, edit, or reject rather than a blank documentation task. The resolved definition then becomes the one every agent and search retrieves.

Faster than a documentation project, because you do not need full coverage to get value. Context Intelligence bootstraps from existing query history, so the highest-traffic domains get context first, and those are the domains where questions actually get asked. Most teams scope evals to one domain, get the pass rate to a level they trust, and expand from there rather than attempting the whole estate at once.

No. It extends both. Existing semantic models encode how metrics are calculated but usually sit inside one tool, drift out of date, and stay inaccessible to agents running elsewhere. DataHub ingests those definitions, fuses them with lineage, quality, ownership, and usage signals from across the stack, and serves the result to any agent through MCP, GraphQL, or the API.

Evals are the mechanism. You define benchmark questions, and DataHub runs them continuously to check whether the current context produces correct answers, which catches regressions before a business user sees one. When a change degrades accuracy, the failure traces back to the specific context that caused it. Miro measured its improvement from roughly 50% to 90% accuracy through exactly this loop rather than a one-time fix.

Recommended next reads

View All Blogs