The Connector Is the Easy Part. Business Context Is the Hard One.

TL;DR

An analyst wired Claude to Snowflake over MCP and wrote up the experience on r/analytics. The setup took hours. "Permissions alone took forever," they wrote, because Snowflake's role and access model needs groundwork before MCP will work at all.

Then came the part nobody sells you. "Your revenue definitions, your customer logic, your metric nuances. That stuff does not live in a schema and there is no clean way to encode it yet."

The top reply cut through every other comment in the thread. "You nailed the actual problem and most of the replies are dancing around it. The connection is a solved problem. The business context isn't."

What business context means here

Business context is the layer of meaning that sits between your schema and your questions. Column names tell an agent that a revenue field exists. They do not tell it whether revenue excludes refunds, includes tax, or recognizes annual contracts monthly.

That knowledge lives in your team's heads, in a Notion doc nobody updates, and in the WHERE clauses of queries an analyst wrote two years ago.

An agent with a perfect connection and no context will answer anyway. That is the problem.

Revenue means three different things

The same commenter gave the cleanest one-line diagnosis of why this is hard: "What kills these setups is that 'revenue' means three different things depending on who's asking."

Finance means recognized revenue. Sales means booked contract value. The growth team means what hit the payment processor this month. All three are correct. All three are different numbers. None of them is labelled in the schema.

An agent asked "what was revenue last quarter" picks one. It does not tell you which, because it does not know there was a choice to make.

This compounds quietly. A separate r/analytics thread on agentic analytics, with 23 points and 55 comments, described the drift: "every new report quietly forks the metric definitions a little. Nothing dramatic. Just enough that revenue on the dashboard and revenue in the weekly export don't quite match if you squint."

The same thread put the effort split in one sentence. "The agent is great at SQL. The slow part is teaching it what anything actually means."

A better model does not fix this

The instinct is to reach for a stronger model or a longer system prompt. Both miss the mechanism.

A commenter in that thread described the outcome precisely: "the model just makes the SQL prettier on the way to the wrong answer." Query quality was never the bottleneck. Modern models write competent SQL. They cannot know that your team stopped counting trial signups as users in March.

This is a different failure from the one people expect. It is not that the agent breaks. It is that it succeeds at the wrong task, fluently. We covered the analytics version of this in why your GA4 MCP server returns confident, wrong numbers, and the general case in how accurate text-to-SQL really is.

Here is where the time actually goes.

The first three are engineering. The last two are organizational, which is why tooling alone never closes them.

Three weeks for the semantic layer

One commenter in the Snowflake thread had made it work, and volunteered the cost. Building the layer that gave the agent reliable context "took 3 weeks to develop just that."

Their warning about what happens outside that layer is worth reading twice. "The moment you ask something out of context, it will hallucinate, manufacture numbers and assumptions, define its own rudimentary tools and use them as absolute source of truth."

That last clause is the dangerous one. The agent does not just guess. It commits to the guess and reasons forward from it.

The prescription from the agentic analytics thread is simple and correct. "You just need one place where 'active user' is defined that the agent treats as gospel, not as a thing to re-derive."

One definition. Stored, not re-derived. That is the whole idea, and it is the thing most setups skip.

The integration mess underneath

There is a harder version of this problem for teams whose data has not been consolidated.

An r/analytics thread on semantic layers, with 23 points and 27 comments, opened with the shape of it: "Our source data comes in from 25+ saas apps and each one has its own naming conventions, data types, and structural quirks."

Twenty-five sources means twenty-five vocabularies. HubSpot's idea of a contact is not Stripe's idea of a customer, which is not GA4's idea of a user. Joining them requires deciding which identity wins, and that decision is a business rule, not a technical one.

One reply captured the organizational comedy of the moment. "I personally find it funny that we've wanted leadership to give us resources for better data quality for years, but now that Mr. AI needs it of course it's super important and critical."

Another put it more bluntly. "Data shows how sloppy businesses are, AI shows how sloppy data practices are."

There is a design warning buried in that thread too. "Semantic layers fail when they try to also DO the integration." Meaning and movement are separate jobs. A layer that tries to be both usually does neither well.

You are paying tokens to re-explain yourself

The cost of missing context is not only accuracy. It is money.

A thread on r/analyticsengineering about semantic layer tooling named both symptoms at once. "First one is consistency, the same question asked in different way gives different answers. Second is cost, the token usage is way higher than expected because the model gets our entire schema dumped on it before it can answer anything."

Read that second half carefully. Every question pays for the full schema again. On a wide warehouse, that is a meaningful bill for information the agent already saw yesterday.

Stored context is cheaper than repeated context. An agent that looks up a definition spends a fraction of what an agent that infers one from two hundred table descriptions does.

What actually works

The teams that get this right converge on a similar sequence. None of it requires a new warehouse.

1. Pick the ten numbers you argue about. Not every metric. The ones that come up in meetings and get challenged. Revenue, active users, churn, CAC, qualified lead.
2. Write one definition each, in plain English. Include the exclusions. "Revenue excludes refunds and test accounts, recognized monthly."
3. Store them where the agent reads them, not where humans forget them. A wiki page the tool cannot see is worth nothing at query time.
4. Correct the agent once and make the correction stick. If you fix the same misunderstanding weekly, the tool is not learning, and you are the semantic layer.
5. Keep access read-only while you calibrate. Getting definitions wrong should cost you a bad answer, never a bad write. See how to securely connect your data to AI agents.
6. Expand only after the first ten are stable. Breadth before consistency produces more surface area to be wrong across.

Notice that none of these steps is about the model. The work is agreement, written down, in a place the machine can reach.

How Sequel handles context

Sequel is built around the assumption that the connection is the easy part.

It connects to Postgres, MySQL, ClickHouse, BigQuery, Google Analytics, Search Console, HubSpot, Stripe, PostHog, Mixpanel, Amplitude, and more from one workspace. That part takes minutes. The part we spend our engineering on is what happens after.

Sequel stores your metric definitions in plain English and applies them on every query. When someone corrects an answer, the correction persists into the next session rather than evaporating with the chat history. Definitions live in the workspace, so the whole team inherits them instead of each person teaching the agent privately.

Every generated query is shown before you act on it, so a wrong definition surfaces as a visible WHERE clause rather than a mystery number. Access is read-only, and results come back as conversation context.

Because it reads across sources in a single answer, the identity problem gets handled in one place too. You define what links a Stripe customer to a HubSpot contact once, not per report. We wrote about that pattern in MCP for databases, and the strategic version in why marketing has a decision problem, not a data problem.

If you want the setup path, start with connecting your database to AI agents securely or the Sequel MCP server guide.

Start with the arguments

The fastest way to find your missing context is to notice where your team already disagrees. Every metric two people define differently is a metric your agent will define a third way.

Write those down first. Get started free and give the agent the definitions before you give it the questions.