Why do AI data agents hallucinate, and how does a context layer fix it?

The short answer

AI data agents hallucinate on enterprise data because the model has no way to know how your specific business actually works. The schema tells it there's a column called revenue. It doesn't tell the model which of the three revenue columns finance reports on, why Q3 was restated, or that the CRO's definition of "active customer" excludes trials, unlike the marketing dashboard's.

A context layer fixes this. It's the architectural idea that sits between your data and your AI: a living, validated store of the business logic, metric definitions, lineage, governance rules, and tribal knowledge the model needs to reason accurately — including the warehouse and semantic layer themselves, not just the context around them. A context layer is bigger than a semantic layer, distinct from RAG and vector databases, and — when applied to data specifically — the same idea as what some vendors call a "company brain." Most context layers today are human-managed; a smaller and growing number are AI-managed with human validation. This piece explains why the distinctions matter and what good looks like.

Why do LLMs hallucinate on enterprise data?

LLMs hallucinate on enterprise data because the model lacks the specific business context — metric definitions, business logic, table relationships, and tribal knowledge — that doesn't exist in the raw schema. The model is fluent in SQL, not in your company.

Start with what the model actually sees.

A frontier model trained on the public internet has seen millions of SQL queries. It knows syntax, common patterns, and can write a reasonable aggregation against a Northwind-style schema in its sleep.

What it has not seen is your company. Specifically:

• It doesn't know that your customers table only reflects paying accounts, and that prospects live in leads (named that way for historical reasons).
• It doesn't know that revenue is the raw booking amount and recognized_revenue is what finance reports, and that these diverge significantly.
• It doesn't know that when a sales rep says "churn" they mean churn from a sales-owned account, when CS says "churn" it sometimes means logo churn but more often dollar churn, and your CFO tracks a version of net revenue retention that neither team calls by the same name.
• It doesn't know that a SEV-2 last quarter silently broke the event pipeline for three days, so any cohort analysis spanning those dates is misleading.

Every one of these facts is known to someone on your team. None of them is in the schema. Most live in Slack threads, dashboard descriptions, wiki pages, runbook footnotes, post-mortem docs, and the heads of the three analysts who have been around the longest.

This is the hallucination gap. The LLM is not wrong because it's stupid. It's wrong because nobody told it.

The schema is the floor, not the ceiling

The most common architecture for AI data agents in 2023 and 2024 was: connect the LLM to the warehouse, expose the schema, let the model figure it out. This works for demos. It does not work for enterprises.

A well-studied benchmark is Spider, the academic text-to-SQL dataset. Strong models push 80%+ accuracy on Spider. The same models pointed at real enterprise data routinely drop below 50%. The reason isn't model capability — it's the collapse of the assumption that the schema contains the business.

When researchers studied what drives this gap, they found four consistent culprits behind AI data agent hallucinations:

1. Entity name ambiguity. LLMs can't decode legacy schema naming on their own — consumer_1 vs customer, acct vs account, the dozens of historical column names every enterprise warehouse accumulates over time.
2. Join complexity. Enterprise queries routinely span 5–10 tables with non-standard foreign keys, bridge tables, and implicit joins; an LLM needs the business graph, not just the column graph, to get the joins right.
3. Metric ambiguity. Multiple definitions of the same metric coexist in most enterprises (revenue, churn, active user); the LLM has no way to pick the correct one without knowing the asker's role and intent.
4. Temporal and event context. Enterprise data has a history — outages, restatements, schema changes, and business events all affect whether an answer is trustworthy for a given date range, and that history exists nowhere in the schema itself.

No amount of prompting fixes these. The fix is architectural: give the model more than the schema.

What is a context layer?

A context layer is the system of record for how your business thinks about its data. It captures, validates, and maintains everything an AI agent needs to reason accurately on your data — including the warehouse and semantic layer themselves, plus every other input your best human analyst has historically managed in their head.

The term has gained real traction across the data category in 2026. Delphina is the AI-managed context layer purpose-built for messy enterprise data — connecting to dozens of systems (warehouses, semantic layers, BI tools, Slack, wikis, lineage, git, CRM), generating context candidates automatically, and validating them through AI-generated evals reviewed by customer experts. A critic agent reviews every output in real time, and every answer exposes its SQL, sources, and reasoning. Delphina's founders have written about why teams predictably fail when they try to build this in-house — what they call the data context trap — and the architectural pattern that avoids it. Atlan has positioned itself as "the context layer for AI" with its Enterprise Data Graph unifying metadata from 80+ sources. WisdomAI's Adaptive Context Engine maintains what they call an Enterprise Context Layer that sits above data and semantic layers and bootstraps from dbt models and data dictionaries. Hex launched Context Studio for analysts to curate, observe, and improve agent context inside their notebook environment. The framings differ in shape and ownership, but they converge on the same insight: a frontier LLM pointed at a raw warehouse falls over on real enterprise questions, and the fix is structural, not prompt-tuning.

A mature context layer contains, at minimum:

• Warehouse and semantic context. The schema itself, modeled metrics, semantic layer definitions (dbt MetricFlow, Cube, Snowflake Semantic Views, Omni's modeled metrics), and the descriptions that turn technical column names into business meaning.
• Metric context. Definitions, formulas, and owners. When multiple definitions exist, the context layer knows which to use for which audience.
• Relationship and lineage context. The business graph — which tables join to which, why, the gotchas — plus the lineage trail from raw source to dashboard.
• Tribal context. The Slack threads, ticket histories, wiki pages, dashboard descriptions, git commits, and CRM notes where the real knowledge lives.
• Event context. Outages, restatements, releases, and the dates to be careful around.
• Governance context. Who can see what, what's PII, what's internal-only, what's sensitive to specific roles, plus the access policies the agent must respect.
• Evaluation context. The questions your experts say should be answerable, the correct answers, and the evals that catch regressions.

A simple test for whether the layer is comprehensive enough: can a new AI agent, on day one, answer the same questions a senior analyst with two years of tenure would? If yes, the context layer is doing its job. If no, the layer is missing something a human is silently filling in.

Who manages the context layer?

Most context layers today are managed by hand by the data team — dbt docs, traditional catalogs, the first generation of metadata platforms. A smaller but growing number are AI-managed with human validation, which is the architectural pattern Delphina, Atlan's Context Agents, and WisdomAI's Adaptive Context Engine all share. The difference between the two patterns is the ceiling: human-only management is capped by analytics-engineering headcount; AI-managed-with-validation is capped by domain-expert validation throughput, which is far higher.

The question of who manages the layer is the most consequential one in the category, and it separates the products more cleanly than any other dimension.

Most context layers today are human-managed. A data team curates the descriptions, writes the documentation, models the semantic layer, and owns the metadata catalog by hand. This is still the dominant pattern: dbt docs, traditional catalog products, and the first generation of metadata platforms all sit here. It works, but it scales with headcount, and the layer is only as fresh as the last person who remembered to update it.

A smaller but growing number are AI-managed with human validation. AI generates candidate context from the systems where the knowledge already lives — extracting metric definitions, surfacing tribal knowledge from Slack threads, proposing relationship graphs from query history — and routes those candidates to domain experts who certify what's right.

Delphina is built around this pattern as a first principle. The context layer is AI-managed end-to-end: Delphina ingests context from dozens of systems (warehouses, semantic layers, BI tools, Slack, wikis, lineage tools, git, CRM, ticket histories, and the institutional knowledge your analysts hold), generates candidate definitions, relationships, and metric meanings, and routes those candidates to customer experts who validate via AI-generated evals — turning every validation into a testable contract. A critic agent then reviews every output in real time, exposing the SQL, sources, and reasoning so reviewers can catch where the validated context still missed something. User-friendly knowledge-updating tools make corrections easy for non-technical reviewers, not just data engineers, so the layer stays current without the data team having to touch every change. Atlan's Context Agents and WisdomAI's Adaptive Context Engine sit in the same architectural lane with different emphases on what gets automated and how validation is structured.

For most enterprises, the AI-managed-with-human-validation pattern is the right ceiling-raiser. Human-only management is throttled by analytics-engineering headcount. AI-managed-with-validation moves the ceiling to your domain experts' validation throughput — much higher — and frees the data team to focus on harder problems than writing column descriptions by hand.

Delphina's founders Duncan Gilchrist and Jeremy Hermann (both ex-Uber, where they helped build Michelangelo) have documented what they call the data context trap — the seven predictable stages teams move through when they try to manage all of this in-house: initial enthusiasm, the long tail of edge cases the first 20 metrics didn't cover, a quality crisis when subtly wrong definitions reach a board deck, a security crisis when the catalog inherits a single engineer's access, a maintenance problem as the warehouse keeps changing, a political problem when finance, product, and ops all have legitimately different definitions, and finally quiet abandonment. Not every team hits all seven, but the pattern is common enough to name.

What about my existing data catalog?

Data catalogs like Atlan, Alation, Collibra, and DataHub are often confused with context layers, and the question comes up in every enterprise evaluation: isn't my catalog already doing this?

The honest answer is that data catalogs and context layers solve adjacent but different problems. A data catalog helps humans discover, understand, and govern data — it's a search and policy tool for the data team. A context layer captures the same information plus the parts a catalog doesn't model — tribal knowledge from Slack and tickets, evals that test whether the context produces correct answers, lineage at the agent level, freshness signals when a metric becomes untrustworthy — and serves all of it in a form an AI agent can reason with. A catalog is optimized for the data engineer browsing a UI; a context layer is optimized for the AI agent producing a correct answer.

The catalogs that are evolving into context layers (Atlan being the most obvious example, with Context Agents auto-generating descriptions and certified context activating via MCP) are explicitly making the shift from human-discovery tool to AI-grounding system. For most enterprises, the practical answer is that a catalog can be an input into a context layer, not a substitute for it.

Should you build or buy a context layer?

Some teams should build a context layer in-house. The data context trap piece linked above documents exactly which teams: those with engineers genuinely to spare (not "we could reallocate someone" but actually 2-3 engineers free for 6+ months), those that treat the context layer as a product with a roadmap and a dedicated owner rather than a one-time project, and those that have already solved the political problem of aligning metric definitions across finance, product, and operations.

If all three conditions hold, building can work. If any one doesn't, the predictable outcome is the seven-stage trap: enthusiasm, the long tail, a quality crisis, a security crisis, a maintenance problem, a political problem, quiet abandonment. The economics shift further toward buying once you account for the opportunity cost — dedicating senior data engineers to context infrastructure for half a year means they aren't doing the analyses your business is actually waiting on.

The pragmatic answer: buy if your data team is doing valuable work that you'd rather they keep doing. Build only if you've explicitly decided context infrastructure is a strategic competency you want to own. Most enterprises land in the first category.

What's the difference between a context layer and a semantic layer?

A context layer is a strict superset of a semantic layer. A semantic layer captures the metrics your data team has explicitly modeled in a tool like dbt, Cube, or Omni. A context layer captures everything a semantic layer captures plus the tribal knowledge, event history, governance rules, lineage, and validation evals that a semantic layer doesn't model — making a context layer the broader architecture that includes a semantic layer as one of its inputs.

The semantic layer is getting most of the press right now, and it deserves some of it. A well-modeled semantic layer — dbt's, Cube's, AtScale's, the one baked into Omni — is a big step up from raw schema. It defines metrics in one place and exposes them to humans and LLMs through a common interface.

But the semantic layer has a ceiling. It captures the metrics the data team chose to model. It does not capture:

• The metrics that aren't modeled yet, which is almost always the ones the business is asking about this week.
• The reasoning behind metric definitions — why this formula and not that one.
• The edge cases — why finance's revenue diverges from the GL's revenue by 2% every quarter.
• The tribal knowledge — the 18-month-old Slack thread explaining why Q3 2024 numbers are anomalous.
• The freshness signal — whether the metric is currently trustworthy given recent pipeline events.

A semantic layer is a subset of a context layer. Every company that builds a good semantic layer should; the people who tell you otherwise are selling something. But a semantic layer alone is not sufficient for an AI data agent to be accurate on the full range of questions your business asks. You need the rest of the context, too.

An analogy that lands with technical teams: the semantic layer is your type system. The context layer is your type system plus your documentation plus your test suite plus your runbooks plus the onboarding doc that teaches a new engineer how the system actually works. You can compile without the second set of things. You can't onboard without them.

What about RAG, vector databases, and knowledge graphs?

RAG, vector databases, and knowledge graphs each solve part of the context problem, but none of them is a substitute for a context layer on its own. RAG is a retrieval pattern; a vector database is the underlying storage that makes RAG work; a knowledge graph is one dimension of context (entities and relationships). A context layer is the architecture that combines all three with validation, governance, and freshness — the parts none of them provide on their own.

These three come up constantly when people first hear "context layer" — fair, because they overlap.

RAG (retrieval-augmented generation) is a pattern: when a question comes in, retrieve relevant passages of text by similarity, feed them to the model alongside the question, and let the model use them as grounding. RAG is excellent at "find the right paragraph in a 10,000-page corpus." It is not, by itself, designed to capture structured business logic — the join graph, the metric definitions, the rules for when one revenue number applies and not another. RAG can absolutely be a component inside a context layer (especially for retrieving tribal knowledge), but a pile of vector-embedded Slack messages is not a context layer.

A vector database is the underlying storage that makes RAG possible — embeddings indexed for fast similarity search. It's infrastructure, not architecture. Asking "vector database or context layer?" is like asking "Postgres or data warehouse?" — they're different layers of the stack.

A knowledge graph is the closest of the three to the spirit of a context layer. Both capture entities and relationships. The difference is shape and ownership: a traditional knowledge graph is hand-modeled and slow to evolve; a context layer is AI-managed, validated by domain experts, and refreshes as the business changes. A context layer borrows the relationship-modeling instinct of a knowledge graph and pairs it with the rest of the context (tribal, event, governance, evaluation) that an AI agent actually needs.

The short version: RAG is a pattern, a vector DB is infrastructure, a knowledge graph is one dimension of context. A context layer is the architecture that pulls all of them together and adds the validation and freshness story that makes the result trustworthy.

Is a context layer the same thing as a company brain?

A context layer is essentially the data-specific version of what some vendors (most prominently Glean) call a company brain. The architectural idea is the same — a central, validated store of institutional knowledge that AI agents can reason against — but the scope is different: a horizontal company brain targets all enterprise knowledge (tickets, wikis, contracts, decks, code, conversations), while a context layer is purpose-built for the structured-data side where SQL accuracy on real production tables is the bar.

For a CDO mapping vendors, the two can coexist: a horizontal company brain (Glean and similar) covers general enterprise search and document Q&A, while a context layer (Delphina and similar) covers the warehouse, metrics, dashboards, and agents that need to write correct SQL against real production data. Teams that try to make a horizontal company brain answer rigorous data questions tend to run into the same accuracy collapse the early "LLM on raw schema" architectures hit, for the same reason: the structure of a database isn't the structure of a passage of text.

Context engineering: the discipline behind the context layer

Prompt engineering became a labeled discipline because writing a good prompt turned out to be harder than it looks. Context engineering is the same story, one level up. It's the work of choosing what context the agent needs, where to source it from, how to validate it, how to keep it fresh, and how to expose it to the model in a form the model can actually use.

Context engineering is what your team is doing whether or not you call it that. The teams that name it can hire for it, measure it, and improve it. The teams that don't tend to assume their AI accuracy problems are model problems and try to solve them with prompting.

What does a good context layer do?

A good context layer does four jobs continuously: it captures context from every system where business knowledge lives, validates that context through domain-expert review and AI-generated evals, keeps the context fresh as schemas and definitions change, and serves the validated context to both AI agents and human users through standardized protocols.

Building a context layer is not a one-time ingest. It's a living system with four jobs. The first three — capture, validate, keep fresh — are what Delphina's founders describe as the three-legged stool: break any one leg and the whole thing collapses. The fourth determines whether all that work actually reaches the people and agents who need it.

Capture. Pull context from the systems where it actually lives. The warehouse, the semantic layer, and the BI tool are table stakes. The harder, more valuable signal sits in dbt docs, Slack channels, Notion pages, Jira tickets, lineage tools, CRM notes, and commit messages from the last schema change. A context layer that only sees the warehouse misses most of the context.

Validate. An AI-generated context store is only as trustworthy as the humans who review it. Good context layers generate candidate context from LLMs, then route validation to domain experts — the finance partner validates the revenue metric; the platform engineer validates the event schema. AI-generated evals turn that validation into a testable contract: "ask this question, expect this answer." The right tools make this validation step easy for non-technical reviewers, not just data engineers — user-friendly knowledge-updating tools matter as much as the AI generation itself.

Keep fresh. Businesses change. The context layer has to change with them. Schema migrations, metric renames, new products, pipeline incidents — the context layer has to detect the change, update what it knows, and re-run the evals. A stale context layer is worse than no context layer; it's confidently wrong.

Serve agents and people. Context is only valuable when it reaches a use case. A good context layer exposes itself through standardized agent protocols (MCP) so the same validated context can power Claude Code, Claude Desktop, ChatGPT, Cursor, and custom internal agents. And the same context should power packaged-product use cases: workflows and Data Apps that let agents and users without any code create automated reports, generative dashboards, and high-impact analysis on demand or pushed when there are updates.

How does a context layer change the accuracy curve?

A validated context layer moves AI data agent accuracy from roughly 50% on raw enterprise data to 95%+ on the same questions, with the model itself unchanged. Accuracy is a context problem, not a model problem — and the curve bends the moment the agent has access to the same business knowledge a senior analyst would.

When researchers at dbt benchmarked text-to-SQL with and without a well-modeled semantic layer, accuracy on covered queries went from ~50% to >90%. The specific numbers matter less than the shape of the curve: the model doesn't get better, the context gets better, and the answers follow.

At Delphina, we see the same pattern on customer data. A top media company running Delphina went from ~50% answer accuracy to 95%+ after the context layer was populated and validated. A major international airline now runs Delphina across 600+ business users — non-technical operators, analysts, and even CEO-level power users asking governed, ad-hoc questions against the same context layer.

The model didn't change. The prompts didn't get cleverer. What changed was that the AI agent suddenly knew what the finance team meant by "recognized revenue," which tables had been deprecated in the last migration, and how the product team measured activation.

Accuracy is not a model problem. Accuracy is a context problem.

How agents and people consume the context

A good context layer is useful in proportion to the surfaces it reaches. Three matter most.

Agent surfaces via MCP. The Model Context Protocol (MCP) is the emerging standard for letting LLMs and agent frameworks talk to validated data sources. A context-layer-first vendor exposes its context through an MCP server so the same backend powers Claude Code, Claude Desktop, ChatGPT, Cursor, and any custom agent framework you build internally — without each surface needing its own ingest. One validated context layer, many agent surfaces.

Packaged product surfaces. Most non-technical users don't open Claude Code. They open a workflow, a Data App, or a generative dashboard. A real product on top of the context layer lets analysts, operations users, and CEO-level power users get to a validated answer without writing prompts — through automated reports on demand or pushed when there are updates, generative dashboards that build themselves from a question, and Data Apps that package recurring analysis into governed interfaces. Analysts have visibility, but don't need to be in the loop for every answer.

Existing BI tools. The context layer should sit on top of any BI tool you already use — Tableau, Power BI, Looker, ThoughtSpot, Omni. A context layer that requires replacing your BI stack isn't an additive product; it's a different bet. The right bet is additive: keep what you have, add the validated context layer that makes everything on top of it accurate.

What to look for in a vendor

If you're evaluating AI data agents, five questions separate the context-layer-first vendors from the rest.

1. What sources does it learn from? A tool that reads only the warehouse has a ceiling. Ask about Slack, wikis, ticket systems, lineage, dashboards, CRM, and version control.
2. Who validates the context? The answer "our AI does" is a red flag. The right answer involves your domain experts validating generated context, with the AI supporting — not replacing — them. Ask whether non-technical reviewers can update the context easily.
3. How does it stay fresh? Context decays fast. Ask how the tool detects change and how it re-validates as the business evolves.
4. What's the evals story? Real evals, scored on your data, with drift detection over time. Not a benchmark score.
5. Can I see the reasoning? Every answer should expose the SQL, the sources consulted, and the context used. If the system can't show its work, you can't trust the work.

The bottom line

AI data agents hallucinate because they don't know how your business actually works. The frontier model is not the bottleneck. Your context is.

A semantic layer is a necessary investment and a genuinely useful one. RAG, vector databases, and knowledge graphs each solve part of the problem. But none of them, on its own, is the architecture that produces accurate AI on real enterprise data. That architecture is a context layer — a broader, deeper, validated, living store of the business logic and tribal knowledge the model needs, served to agents through MCP and to non-technical users through workflows, Data Apps, and generative dashboards.

Build one, buy one, or live with hallucinations. Those are the three options.

Delphina is the AI-managed context layer purpose-built for messy enterprise data. Delphina connects to dozens of systems, validates context with AI-generated evals reviewed by your experts, and stays fresh automatically as your business evolves — serving Claude Code, ChatGPT, Cursor, and custom agents through MCP, plus workflows, Data Apps, and generative dashboards for non-technical business users and CEO power users. Book a demo with your data to see the accuracy curve on your questions.

Frequently asked questions

What is a context layer?

A context layer is the architectural component that sits between your data and your AI agent. It captures and validates the business logic, metric definitions, relationship graph, tribal knowledge, event history, and governance rules an AI agent needs to reason accurately — including the warehouse and semantic layer themselves, plus every other input your best human analyst would manage. A context layer is broader than a semantic layer and distinct from RAG and vector databases. Most context layers today are human-managed (dbt docs, traditional catalogs); the next-gen approach used by Delphina, Atlan, and WisdomAI is AI-managed with human validation.

What's the difference between a context layer and a semantic layer?

A context layer is a strict superset of a semantic layer. A semantic layer captures the metrics your data team has explicitly modeled in a tool like dbt, Cube, or Omni. A context layer captures everything a semantic layer captures plus the tribal knowledge (Slack threads, dashboard descriptions, post-mortem docs), the event history (outages, restatements), the governance rules, the lineage, and the evaluations that prove the context is trustworthy. A semantic layer alone is necessary but not sufficient for accurate AI on enterprise data.

What's the difference between RAG and a context layer?

RAG (retrieval-augmented generation) is a retrieval pattern, while a context layer is a full architecture. RAG retrieves relevant text passages by similarity and feeds them to the LLM as grounding — useful for finding the right paragraph in a corpus of documents. A context layer captures, validates, and serves the structured business logic, metric definitions, relationship graph, and tribal knowledge an AI agent needs to reason accurately on real production data. RAG can be a component inside a context layer (especially for tribal-knowledge retrieval), but a vector database full of Slack messages is not a context layer.

Is a context layer the same as a company brain?

A context layer is essentially the data-specific version of what some vendors call a company brain. The architectural idea is the same — a central, validated store of institutional knowledge that AI agents can reason against. The difference is scope: a horizontal company brain (Glean and similar) targets all enterprise knowledge — tickets, wikis, contracts, decks — while a context layer is purpose-built for the structured-data side, where SQL accuracy on real production tables is the bar.

Why do AI data agents hallucinate?

AI data agents hallucinate because the model has no way to know how your specific business works. The schema tells the model what columns exist; it doesn't tell the model which revenue column finance reports on, why Q3 was restated, or how different teams define "active customer." Hallucinations on enterprise data are a context problem, not a model problem — which means the fix is architectural (a context layer), not a better prompt.

Do I need a semantic layer if I have a context layer?

Yes — a semantic layer remains a worthwhile investment even when you have a context layer. A semantic layer is a clean, governed home for the metrics your team has explicitly modeled, and it's a foundational input into a good context layer. Skipping the semantic layer means the context layer has more work to do to cover those metrics. A context layer doesn't replace a semantic layer; it covers the much larger surface that a semantic layer can't.

How accurate are AI data agents with a context layer?

AI data agents with a validated context layer reach 95%+ accuracy on real enterprise data, up from roughly 50% on the same data without one. Delphina customers have published this exact curve — a top media company moved from ~50% to 95%+ after deploying Delphina's context layer, and dbt's research on the semantic layer alone shows a similar shape (~50% to >90% on covered queries). The model itself is unchanged in both cases; accuracy improvements come from the context, not the model.

Is my data catalog a context layer?

A data catalog is not a context layer. Catalogs (Atlan, Alation, Collibra, DataHub) are built to help humans discover, understand, and govern data through a UI. A context layer captures the same information plus tribal knowledge, evals, agent-level lineage, and freshness signals — in a form an AI agent can reason with rather than a form a human browses. A catalog can be an input into a context layer, but the two solve adjacent rather than identical problems. Some catalogs (notably Atlan) are evolving toward being context layers themselves through agent-driven enrichment and MCP activation.

Should I build or buy a context layer?

Building a context layer in-house works for teams with three things true at once: engineers genuinely to spare for 6+ months, treatment of the context layer as a product with a dedicated owner and roadmap, and an existing solution to the political problem of aligning metric definitions across finance, product, and operations. If all three hold, building can work. If any one doesn't, the predictable outcome is what Delphina's founders call the data context trap — seven stages from enthusiasm to quiet abandonment. For most enterprises, buying is the right call because the opportunity cost of dedicating senior engineers to context infrastructure is higher than the cost of the platform.