AI Analytics

Can we replace our data warehouse with Claude connectors?

I built our whole marketing funnel report myself with AI connectors. Does it mean the warehouse is dead?

Date
Jun 11, 2026

Last week I built our entire top-of-funnel report by myself. No data team, no ticket in a queue, no month-long project. Two days, and well... it works.

I connected Claude to HubSpot, PostHog, and Common Room, asked questions in plain English, defined what each metric actually means, and ended up with a dashboard the whole team now uses. No warehouse and no pipeline.

As someone who lives and breathes the world of pipelines, semantic layers and data quality, all of this felt like a crime. So before I called the warehouse dead, I sat with it and worked out what actually makes sense here and what doesn't.

So you really didn't centralize anything?

No. And that's the part that actually changed.

The old rule was simple: centralize everything into a warehouse, model it, then ask your question. Connectors flip the order. Through MCP the model reaches into each source where the data already lives and answers across all of them, so there's nothing to centralize first.

That's a new starting point for analytics, and it's the one real shift here.

But didn't the AI do the hard part?

Less than you'd think. Once the connectors are wired up, the querying takes care of itself. The part I had to own and manage was what every number actually meant.

Almost every raw count in our CRM is wrong. Not broken, just misleading. A metric I figured would be trivial turned out to be full of existing-customer activity and duplicate logs, and meant nothing until I pinned it to one source. A field that looks like it tells you where a lead came from actually hides it. Count naively and you sweep in test addresses and bots that auto-add themselves to calls.

None of that is carelessness I cleaned up after. Raw data just looks like this until someone decides what to count.

Fine, but it's reproducible, right?

For me, yes. I turned the definitions into reusable skills, so next month I run the same report and get the same numbers.

But repeatable and reliable aren't the same thing. A skill is a copy of a definition, not the definition. It reproduces my report when I ask my question, my way. It does nothing for the question I didn't think to anticipate.

So just share the skill with everyone?

That makes it worse, not better.

Copy a skill to ten people and you have ten definitions. Someone edits theirs, someone's a version behind, someone writes a new one for a question mine never covered. There's no canonical number anymore, just the most recent one in the room.

And a skill can't tell you when it's wrong. The day HubSpot renames a field or a dbt model changes grain, it keeps running the old logic and hands back a confident, wrong number. Nobody gets alerted. You find out when someone notices the funnel looks off, if they notice.

A shared copy is still a copy. Hand it around and the drift spreads with it.

Then commit it to a repo and share it that way?

That solves distribution, not drift. Version control stops everyone keeping their own divergent copy, which is real. But the skill reaches straight into the raw systems, and it carries all the cleaning I did by hand: which rows to drop, which source to trust, what to exclude. Pinning that logic to sources that keep changing, and keeping it correct for every question the org throws at it, is the hard part. A repo hands everyone the same file. It doesn't keep the logic true as the data underneath moves. That's the work modeling and a semantic layer do.

So can you replace the warehouse with connectors, or not?

For my own questions, honestly, yes. It was fast, it was efficient, and I'd do it again tomorrow.

For the company's reporting, no. It worked because I knew the data cold, and it stays reliable only as long as I'm the one asking. The moment the answer has to serve someone who doesn't know the sources, the whole thing has to stand on more than a skill on my laptop. Two things a skill can't replace.

The first is the data foundation. Something still has to move the data, clean it, and land it somewhere built for querying, not your production database. I got away without a warehouse because I shaped how every source is modeled in the first place. At org scale you don't get that for free, and democratizing analytics doesn't retire data ownership, it leans on it harder.

There's also the bill. For my handful of questions, reaching into the raw sources each time costs almost nothing. For a whole org asking all day, and agents asking on everyone's behalf, paying to pull and re-interpret raw data on every query adds up fast. Model the data once and query that, and it's cheaper, not just cleaner.

The second is shared meaning. What counts as a lead, what to exclude, which source is the truth. Those definitions have to come out of my skills and into one place the whole org, and every agent, reads from. One person's shortcut isn't a shared answer until it lives in a semantic layer and a governance layer.

That's the design principle behind Elementary, and an agent needs two things before it answers.

  • Whether the data is trustworthy: is the table fresh, did its dbt models pass their tests, are there nulls where there shouldn't be.
  • And what the data means: which source is the truth, what counts as a lead, what to leave out, the business context that turns a raw column into the right number.

Elementary's context engine is the single place both of those live, for every person and every agent, so the answer doesn't depend on who's asking. Miss either half and you still get a confident wrong number, just faster.

So when would you actually use this?

Both, for different jobs. For the questions that carry weight, the ones a decision or a board number rests on, route them through the modeled, governed stack where the answer is owned and checked. For fast, low-stakes exploration, connectors are perfect: when you want to see whether a trend is even real before you invest in standardizing and cleaning the data behind it, a marginal mistake costs almost nothing, and you get the answer in minutes instead of a sprint.

Used this way, connectors are how you decide what's worth putting in the warehouse in the first place.

You can ask your data anything now. The real question is whether everyone else, and every agent, gets the same answer you did.

See Elementary in action

Book a Demo