Star schemas (a common data warehouse layout with a central table of facts, like sales, linked to surrounding tables of details, like customers or products) have a hidden dependency that most teams don’t notice until something breaks: a human analyst. Take the sales_fact table’s revenue column. That column means recognized ARR, but you’d only know that if you’d sat through a quarterly close meeting and heard the CFO correct someone for mixing up bookings with revenue. The schema itself never captures that correction. It doesn’t need to, because the analyst just remembers it.
Now take that human out of the loop and hand the same table to an AI agent. Suddenly that assumption falls apart. The agent has no way of knowing that revenue means recognized ARR specifically. It doesn’t know RevOps uses a 30-day cohort window while Finance works off calendar quarters. It doesn’t know that enterprise accounts in active expansion get manually pulled out of the churn calculation. None of that lives in the schema, and no foreign key join is going to surface it.
This is essentially a context problem, not a model quality problem. LLMs aren’t guessing randomly here. They’re doing what any capable system does when it’s missing context: picking the most plausible interpretation and running with it. In human-assisted analytics, that’s fine, because an analyst reviews the output and catches the wrong interpretation before it matters. In an automated agentic workflow, there’s often no one checking, so the same behavior becomes a real structural problem.
It helps to remember what star and snowflake schemas were actually built for: query speed and analyst productivity. Every dimension table and every fact-to-dim join assumes someone who already understands the business is the one running the query. Once the agent becomes that someone, the whole design assumption stops holding up.
- The core gap: Star schemas capture what data means to a query engine. They don’t capture why decisions were made about it.
- The failure mode: Agents give confident, technically correct answers that don’t match how the business actually operates.
- The fix: A context layer that carries metric provenance, exception history, and tribal knowledge, not just column definitions.
What AI Agents Actually Require from a Data Model
AI agents need four things from a data model that star schemas don’t provide: unambiguous entity resolution, metric definitions with provenance, exception history, and tribal knowledge. Without all four, agents operating in production will consistently produce answers that are technically correct by schema definition and wrong by organizational reality.
Unambiguous entity resolution
In most production warehouses, revenue, MRR, ARR, and bookings are different columns in different tables with overlapping names and subtly different definitions depending on which team owns them. An agent resolving “what’s our MRR trend?” needs to know which table, which column, which definition, and whose definition — without asking. The semantic ambiguity that a senior analyst navigates manually on instinct is a hard blocker for any agent without an explicit entity map.
Metric definitions with provenance
An agent needs to know what a metric computes, who owns the definition, when it changed, and what triggered the change. When Finance redefined “closed-won” in January to exclude trials under 14 days, that change needs to be first-class context for any agent reasoning about pipeline numbers from Q4 onward. A metric definition without a change history is a timebomb in agentic workflows that span reporting periods.
Exception history
Past anomalies, and the human decisions made about them, shape how agents should read current data. Say your team knows Q3 churn was inflated because of a forced product migration that hit one specific contracted cohort, and someone manually adjusted the figures with a note in Notion. An agent reasoning about this quarter’s churn needs to know that this exception exists. Without it, the agent treats the Q3 spike as normal behavior and bases its current-quarter interpretation on a number that everyone who actually worked with it had already flagged as misleading.
Tribal knowledge
The institutional reasoning that makes data make sense to your team, and it usually lives in Slack threads, post-mortem docs, and engineering Notion pages, not in any schema. If you ask an agent – “What drove the churn increase in Q3?” and it only has access to the star schema, it will give you a confident, plausible answer that’s probably wrong. The real cause, a forced migration that hit one specific cohort, is written up in a Notion post-mortem somewhere. The schema has no idea it exists.
Decision traces deserve special attention here. Every time a senior analyst makes a judgment call, like overriding a metric, adjusting for a one-time event, or flagging something as a non-recurring anomaly, that decision reflects organizational context built up over years. When that analyst leaves, all of that context leaves with them. For human analysts, that’s a costly problem. For AI agents, it’s a production outage.
Why Semantic Layers Close the Delta Partially
Semantic layers like dbt MetricFlow, Snowflake Cortex Analyst, and LookML represent a genuine improvement over raw warehouse access for AI agents — but they have a ceiling for agentic use that is lower than most teams expect when they first deploy agents.
The ceiling has four edges:
Manual maintenance
Every metric definition in a dbt YAML file is a maintenance commitment. As business logic evolves (For example: finance changes the cohort window, RevOps adds an enterprise exception, a migration inflates one quarter’s numbers) and those definitions drift from reality unless someone updates them. Most teams don’t update them fast enough. A MetricFlow metrics file that was accurate in Q2 can be subtly wrong by Q4 without anyone noticing until an agent produces a number that doesn’t reconcile with the board deck.
Structural limitation
Semantic layers define what things are, not why decisions were made. Your MetricFlow definition for churn rate says churned_customers / customers_at_start_of_period. It doesn’t say that Customer Success and Finance use different cohort windows, that RevOps manually adjusted Q3 figures, or that enterprise accounts under active expansion are excluded from the denominator. Snowflake’s Cortex Analyst has the same constraint: it stores metric definitions in a Semantic View, but those definitions are manually configured and locked to whatever your team thought to write down at configuration time.
No unstructured ingestion path
LookML and dbt metrics are, structurally, definitions of structured data about structured data. There’s no mechanism to ingest a Slack thread explaining why the Q3 anomaly happened, a Notion post-mortem encoding the exception precedent, or a meeting recording where the CFO clarified what “revenue” means for the board deck versus the RevOps dashboard. That category of context matters most for agent reasoning, and it’s entirely outside what any current semantic layer handles.
Static governance
Semantic layers don’t track interpretation history. They don’t record that a metric definition changed on a specific date, who made the call, or what prompted it. When an agent reasons across time periods with different underlying definitions, it does so blind to the boundary where the definition shifted.
The practical failure looks something like this: an agent confidently answers – “What was our churn rate in Q3?” using the MetricFlow-defined calculation, and the number doesn’t match the board deck. Technically, the agent’s math is correct according to the schema. Practically, it’s wrong according to how the business actually works. After something like that, nobody in the room trusts the agent again, and earning that trust back is harder than building it in the first place.
The Context Graph: What It Adds and How It’s Built
A context graph is a strict superset of the semantic layer — the architectural layer that finally closes the gap between what star schemas express and what AI agents need to reason reliably in production.
It contains metric definitions, plus relationship graphs, decision traces, tribal knowledge, governance precedents, data lineage signals, and exception history. It layers above your existing semantic layer, extending what that layer can express. The defining difference from every existing semantic layer: a context graph is mined, not authored. You don’t write it in YAML. You extract it from the organizational artifacts that already exist, because that’s where the real context lives.
Jedify’s Semantic Fusion™ constructs the Context Graph through four stages: Connect, Generate, Refine, and Deploy.
Connect ingests from both structured sources (Snowflake, BigQuery, Databricks, Redshift, dbt models, CRM systems) and unstructured sources: Slack exports, Notion pages, internal documents, meeting recordings, and BI dashboard query history. Both sides feed the same graph. This dual ingestion is the architectural move that distinguishes a context graph from a semantic layer, because organizational knowledge that was never in a schema finally has an ingest path.
Generate is where the autonomous construction happens. FP-Growth and Apriori algorithms mine SQL query log history for co-occurrence patterns: which metrics are consistently queried together, which dimension filters are always applied, which entity combinations surface repeatedly across analysts’ sessions. Named Entity Recognition (NER) extracts business terms and metric synonyms from data assets and unstructured text. BERTopic clusters recurring concepts across the unstructured corpus, identifying that “the Q3 migration”, “product transition cohort”, and “forced upgrade” all refer to the same event, then associating that cluster with the churn anomaly in the structured data. The output is a semantic universe: entities, relationships, definitions, synonyms, and the connections between them — assembled without a single line of YAML.
Refine brings data teams into the loop. The autonomously generated graph isn’t perfect because mining is probabilistic, and some entity groupings could be wrong. The human-in-the-loop interface lets your team inspect the semantic universe, correct misclassified entities, add exception precedents that have no written source, and encode tribal knowledge explicitly. Each correction feeds back into the model via RLHF, improving subsequent generations. This is a validation pass, not a build-from-scratch exercise — and that distinction matters for team adoption.
Deploy exposes the refined Context Graph through Jedify’s Contextual MCP Server. Any MCP-compatible agent framework (Claude Desktop, Cursor, custom pipelines built on the Jedify SDK) connects via a single standardized endpoint. At query time, agents pull the relevant context dynamically: what “revenue” means in the context of this specific prompt, from this team, at this point in time. Live context scoped to the request, pulled at runtime.
The MCP delivery model matters here. Context isn’t something a developer manually stuffs into a system prompt for each request. It’s infrastructure. Every agent in your stack, no matter which framework built it, pulls the same organizational context from the same endpoint, the same way, every time it runs.
Practical Path: Layering Context on Top of Your Existing Stack
The context graph layers above your existing data infrastructure without replacing it — your warehouse, your dbt semantic layer, and your CRM integrations all stay in place and become inputs to the graph, not casualties of it.
Nothing in this architecture requires ripping out your current stack. The warehouse stays. The dbt semantic layer stays. The Context Graph layers above both, consuming them as inputs and adding what they can’t express.
Step 1: Connect structured sources
Wire your warehouse (Snowflake, BigQuery, Databricks, Redshift), dbt models, CRM, and financial systems into Jedify through native connectors. This populates the base graph with metric definitions and entity relationships already captured in your existing semantic layer. Semantic Fusion™ reads what’s there and builds on it, so you’re not re-entering anything that already exists.
Step 2: Connect unstructured sources
Slack exports, Notion pages, internal documents, and meeting recordings. This step captures the organizational context your schema was never designed to hold. A single Notion post-mortem encoding the Q3 migration exception delivers more agent reasoning value than weeks of YAML maintenance, because it captures the why that no metric definition can express.
Step 3: Let Semantic Fusion™ run
The graph mines query logs using FP-Growth and Apriori, runs NER across data assets and documents, applies BERTopic to the unstructured corpus, and surfaces entity clusters and relationship patterns. Review the generated semantic universe in the human-in-the-loop interface: correct the entity groupings that need adjusting, add exception precedents from institutional memory, and encode tribal knowledge that has no written source. Most data teams complete a meaningful initial refinement pass in a few hours, not a few weeks.
Step 4: Expose context via Jedify’s Contextual MCP Server
Set JEDIFY_API_KEY in your MCP configuration. Your existing agent infrastructure (Claude Desktop, Cursor, or a custom pipeline) connects through a single endpoint. One MCP connection replaces the fragmented per-prompt context injections your team has been maintaining manually, and eliminates the inconsistency that comes from different developers writing different system prompts for the same underlying business logic.
Setup time to first context delivery is under an hour for a standard data stack. Agents then answer the Q3 churn question correctly because the post-mortem, the exception, and the definition are all in the Context Graph.
The Next Step: Run a Context Gap Audit Right Now
A context gap audit is the fastest way to map exactly where your current semantic layer fails your AI agents — and to prioritize what context infrastructure to build first before deploying agents in production.
Pull the ten agent prompts your team runs most frequently. Run each against your current semantic layer or direct warehouse connection. For each result, record three things:
- Did the agent correctly disambiguate entities (the right “revenue” definition, the right cohort window)?
- Did it apply the correct metric definition for the context in which the prompt was asked?
- Did it account for known exceptions (the Q3 migration adjustment, the enterprise account exclusions, the Finance cohort change from January)?
Every failure becomes a line item in your context gap map. These are context infrastructure failures, meaning specific pieces of tribal knowledge, exception history, or governance precedent that need to be encoded before your agents can be trusted in production. The gap map shows you exactly what to build first, in priority order.
Connecting Jedify to your existing data stack takes under an hour with self-serve setup, using connectors for Snowflake, BigQuery, Databricks, Redshift, dbt, and major CRMs. From there, let Semantic Fusion™ run its initial autonomous construction pass. Review the generated semantic universe in the human-in-the-loop interface, correct the top entity groupings, and add the five most critical exception precedents your gap audit surfaced. At that point, your agents finally have the context map they were missing.
Frequently Asked Questions
What is a context graph for AI agents, and how does it differ from a semantic layer?
A context graph is a structured knowledge layer that extends a semantic layer with metric provenance, decision traces, exception history, and tribal knowledge mined from unstructured sources like Slack and Notion. A semantic layer defines what metrics compute; a context graph also encodes why definitions changed, who made those calls, and what organizational exceptions constrain how data should be interpreted. The key distinction is that a context graph is mined from existing artifacts, not manually authored in YAML.
Why do star schemas fail when AI agents replace human analysts?
Star schemas (common data warehouse layouts with a central table of facts, like sales, linked to surrounding tables of details, like customers or products) were designed for analysts who carry institutional knowledge in their heads — they know which “revenue” definition applies, which cohort window each team uses, and which anomalies were one-time events. AI agents have no access to that implicit knowledge. When an agent queries a star schema, it selects the most plausible interpretation of ambiguous column names and metric definitions, which frequently conflicts with organizational reality even when the SQL is technically correct.
What does metric provenance mean, and why do AI agents need it?
Metric provenance is the complete history of a metric definition: what it computes, who owns it, when it changed, and what triggered each change. AI agents need provenance because they often reason across time periods that span definition changes. An agent comparing Q4 pipeline to Q1 pipeline without knowing that “closed-won” was redefined in January will produce a number that is internally consistent but misleading — a failure that provenance tracking directly prevents.
How does Jedify’s Semantic Fusion build a context graph without manual YAML authoring?
Semantic Fusion uses three automated techniques: FP-Growth and Apriori algorithms mine SQL query logs for co-occurrence patterns between metrics and dimension filters; Named Entity Recognition (NER) extracts business terms and synonyms from data assets and documents; and BERTopic clusters concepts across the unstructured corpus to link organizational events (like a product migration) to the anomalies they caused in structured data. A human-in-the-loop refinement pass then validates and corrects the generated graph.
What is the MCP server, and why does it matter for agent context delivery?
The Contextual MCP Server is the runtime delivery layer for the context graph. Rather than requiring developers to inject context manually into each agent’s system prompt, the MCP server exposes organizational context as infrastructure through a single standardized endpoint. Any MCP-compatible agent framework (like Claude Desktop, Cursor, or a custom SDK pipeline) connects once and receives dynamically scoped context at query time, eliminating per-prompt maintenance and inconsistency across teams.
How long does it take to set up Jedify on an existing data stack?
Setup time to first context delivery is under an hour for a standard data stack. Jedify provides native connectors for Snowflake, BigQuery, Databricks, Redshift, dbt, and major CRMs. The initial Semantic Fusion pass runs autonomously; most data teams complete a meaningful human-in-the-loop refinement pass — correcting entity groupings and adding critical exception precedents — within a few hours, not weeks.
What is a context gap audit, and how should a team run one?
A context gap audit systematically identifies where your current semantic layer fails your AI agents before those failures reach production. Pull the ten prompts your agents run most frequently, run each against your current data layer, and evaluate three things per result: entity disambiguation accuracy, metric definition correctness in context, and exception handling. Each failure maps to a specific missing piece of context infrastructure — tribal knowledge, exception history, or governance precedent — giving you a prioritized build list.
Can a context graph coexist with an existing dbt semantic layer, or does it replace it?
A context graph layers above your existing semantic layer without replacing it. Your warehouse, dbt models, and CRM integrations remain in place and become inputs to the graph. Semantic Fusion reads your existing metric definitions and builds on them, so you avoid re-entering anything already defined. The context graph adds what the semantic layer cannot express: provenance, exception history, unstructured organizational knowledge, and governance traces.
