A context layer stores what your data means – metric definitions, relationships between systems, business rules – so an AI agent stops guessing. This post explains why agents fail without one, what Microsoft, Snowflake and Airbyte just shipped, and what to do if you don’t have a data platform team.
In June, Snowflake published a number that deserves more attention than it got. Their data team tested AI agents on internal analytics questions – real ones, with joins across tables, metric definitions and filter conventions. The agents got about 25% right. Anthropic ran an independent evaluation and measured 21%.
Two teams, different methods, same result: without help, an AI agent is wrong on 3 out of 4 questions about your business data.
This is not a model problem. The model writes correct SQL, the answer comes back in seconds, and it sounds confident.
The problem is what the model doesn’t know. It doesn’t know that “revenue” in your warehouse means recognized revenue, not bookings. It doesn’t know that churned customers are still sitting in the accounts table, marked by a status flag someone added in 2021. It doesn’t know which field joins deals to invoices, because nobody ever documented it.
Your analyst knows all of this – it took them two years of asking colleagues. The agent has to guess, on every question.
The fix has a name now: a context layer. Microsoft shipped Fabric IQ in June, Snowflake announced Cortex Sense the same month, and Airbyte launched a Context Store in May. Three vendors arriving at the same idea within eight weeks tells you something. Fivetran’s 2026 benchmark report tells you the rest: 85% of enterprises are already running agentic AI on a data foundation that isn’t ready for it.
In this post I’ll explain what a context layer actually does, why agents fail without one, and what your options are if you don’t have a data platform team. Also where you don’t need one – because not every company does.
What is a context layer?
A context layer is a store of meaning that sits between your data and your AI agents. It holds the things a database schema does not: what each metric means, how records relate across systems, which filters your company applies by convention, and which rules matter when.
Think of it as the notes a new analyst builds during their first year. Which tables to trust. Where revenue really comes from. What “active customer” means in this company, as opposed to the last one.
So the split is simple: the data warehouse stores your numbers, the context layer stores what the numbers mean. An agent needs both, because SQL access without meaning produces confident, wrong answers.
Why AI agents fail without context
Snowflake’s test questions needed three things: cross-table joins, metric formulas and filter conventions. Those map neatly onto the three ways agents go wrong.
1. Definitions are ambiguous
“Revenue” can mean bookings, billings, recognized revenue or MRR – and in most companies it means different things in different tables. The agent picks one. Nothing in the schema tells it whether it picked yours.
2. Tribal knowledge is invisible
Every warehouse carries history. Churned customers that never left the accounts table. Test rows everyone knows to exclude. A price column that switched from USD to EUR in 2023. None of this is written down where a model can see it, because it never had to be – people just knew.
3. Relationships are undocumented
Your CRM, your accounting package and your support desk all describe the same customer, but with different IDs and no documented mapping. A human analyst reconstructed those joins once and reuses them forever. The agent reconstructs them from scratch on every question – and often differently each time.
Each guess compounds. A question that needs one definition, one exclusion and one join gives the agent three chances to silently go wrong. That is how you get to 25%.
And this is expensive before it is wrong. A 2026 survey of more than 200 data and AI leaders found that 71% of AI teams spend over a quarter of their implementation time on data integration alone. Context work is where the time goes, whether you plan for it or not.
Three vendors, one idea, eight weeks
The speed of the response tells you how real the problem is. Here is what shipped, who each option fits – and how they differ from the MCP platforms that were already competing on AI-to-data access.
Microsoft Fabric IQ
Generally available since Build in early June. Fabric IQ adds ontologies on top of semantic models: business entities, relationships, rules and actions, connected to live signals. It is the deepest option if your estate already runs on Microsoft – and mostly irrelevant if it doesn’t.
Snowflake Cortex Sense
Announced at Snowflake Summit the same week. Instead of asking you to author context by hand, Cortex Sense mines it automatically from your data estate, then runs a self-correcting loop to catch gaps in its own knowledge. It is also the source of the 25% number – Snowflake measured its own agents before and after. A natural fit if Snowflake is already your warehouse. Note that it was announced, not shipped, so check availability before you plan around it.
Airbyte Context Store
Launched May 5, with a different architecture: Airbyte replicates data from your tools into a search-optimized index, so agents query a pre-assembled copy instead of chasing live APIs. Airbyte claims around 40% fewer tool calls and up to 80% fewer tokens. Those are their numbers, not independently verified, but the direction is plausible. It launched with 50 connectors, and the CEO is upfront that the product is early.
The last row is a category, not a vendor – we wrote a separate breakdown of how warehouse-first MCP servers compare across the market.
Do you actually need a context layer?
Honest answer: not always.
If your agent works on one system with a clean schema – say, a single Postgres database with well-named tables – a good prompt with a schema description gets you surprisingly far. The same goes for narrow, repeated tasks where you can hand the agent the exact query patterns it needs.
You need one when three things stack up: multiple source systems, questions that cross them, and users who ask in natural language rather than SQL. That combination is exactly where accuracy collapses, because it maximizes the guessing.
A 10-minute test
Write down your five most common business questions. For each one, ask: does answering it correctly require knowledge that is not in any schema – a definition, an exclusion, a mapping between systems? If yes for most of them, you have a context problem, whatever tool you end up using.
What to do without a data platform team
The launches above assume enterprise estates and dedicated teams. If that is not you, the good news is that most of a context layer is not technology. It is writing down what your company already knows.
Four steps, in order of value:
- Start with definitions, not tools. Write down your 20 core metrics: exact formula, source table, known exceptions. A one-page semantic model in a shared doc beats no model in any tool. This alone is most of the value.
- Curate what the agent sees. An agent pointed at 400 raw tables guesses more than one pointed at 15 clean, well-named ones. Fewer options, fewer wrong turns.
- Get your data into one queryable place. Cross-source questions need a single SQL surface. Whether that is a warehouse you run yourself or one built into a platform matters less than the fact that it exists.
- Log every question and answer. You cannot improve accuracy you do not measure. Keep the questions the agent got wrong – they show you exactly which context is missing.
Do these four things and you have a working context layer, even if nobody calls it that.
How we approach this at Peliqan
Peliqan is built around step three, with the other steps attached. Every connected app – 300+ connectors, from Exact Online and Odoo to HubSpot and Salesforce – syncs into a built-in Postgres warehouse.
AI agents query that warehouse over the Model Context Protocol with real SQL, cross-source joins included. Table and column metadata travels with the data, so the agent works from curated tables and their meaning rather than raw API responses.
You decide what each agent sees and does. Role-based permissions scope tables, columns and write access per agent, and every read and write is logged. That covers step four without extra tooling.
To be clear about fit: this does not replace Fabric IQ for a 50,000-person Microsoft estate, and it is not meant to. It is built for the mid-market team that wants the four steps above handled in one place, this quarter, without hiring a platform team. The architecture details are on our MCP page.
And if you want to go hands-on first, the docs walk through building AI agents on your own data step by step.
Start from 25%, not from the demo
The honest baseline for AI on business data in mid-2026 is roughly one right answer in four. That is not a reason to skip agents. It is a reason to do the context work first, because that number is not fixed – it reflects how much your agent has to guess.
The teams getting real value from AI right now are not the ones with the best model. They are the ones whose agents guess the least.
If you want to see what your own data looks like with context, book a demo: connect your systems, ask a real business question, and compare the answer against your own numbers. That is the whole test.
