How to set up AI analytics: five approaches compared
LLM direct, build in-house, semantic layer tools, warehouse-native AI, or a purpose-built layer. What each one costs you after the demo is over, and which problem each one is actually for.
Every one of these five approaches demos well. They diverge in month three, when someone leaves, the schema changes, and a number turns out to have been wrong for six weeks.
We have helped teams set up AI analytics across different stacks and company sizes. This is what we have seen each approach cost after the demo, judged on the things that only show up in production: setup effort, access control, lock-in, audit trail, knowing when the context is wrong, and who maintains it.
1. Use an LLM directly
Point Claude, ChatGPT or Gemini at your database and start asking. Fastest possible start, and genuinely the right answer for one technical person exploring their own data.
It stops working as a team approach for reasons that are all the same reason: there is no layer holding shared state.
Everyone sees everything the connection can reach. Two people asking "what's our revenue?" get different numbers, because nothing defines revenue except each person's phrasing. Nobody can see what questions are being asked, what SQL ran, or where the answers went wrong — and that last one is the expensive part, because wrong answers do not announce themselves.
2. Build it in-house
Full control, exactly your requirements, no vendor. For a platform team with the people and the opinions, this can be the right call.
The mistake is almost always the same one: estimating the build and not the maintenance. The initial version takes about a quarter. Then context management, access controls, query validation, usage monitoring and gap detection all become something you own indefinitely. Every new data source, every new person, every renamed column is now your team's ticket.
For a one or two person data team, this reliably ends with more time spent maintaining the tool than doing analysis. That is not a failure of skill, it is just what internal products cost.
3. Semantic layer tools (Cube, dbt, AtScale)
These are good at what they are for: standardising metric definitions and feeding structured reporting. If you have analytics engineers who will maintain the YAML, and your questions fit the metrics you defined, they work well.
The gap is everything outside the predefined layer. New metrics, new sources, and people asking questions nobody anticipated. The layer falls behind, and you find out it fell behind when somebody acts on a wrong answer. There is no signal that tells you the definitions have drifted from reality.
The other thing to know going in is that they are definitions only. You still need a tool on top to query and visualise, so this is rarely the last purchase.
4. Warehouse-native AI (Cortex, Genie, Amazon Q)
Snowflake has Cortex Analyst, Databricks has AI/BI Genie, AWS has Amazon Q for Redshift. They live in the warehouse and use the permissions model you already have, which is a real advantage and not a small one.
The upside is that everything stays inside your warehouse ecosystem. The downside is the same sentence. Your context, definitions and saved queries do not come with you if you move. You still write and maintain semantic models by hand, or configure Genie spaces manually. And your team asks questions in the warehouse's interface rather than the AI tool they already have open, which is a rollout.
If your entire company lives in one warehouse and you have people to maintain the semantic model, these are a sensible default. If your data is spread across sources, or the people asking questions are non-technical, they are a harder sell.
5. Contextflo
Built for teams that want this running in production without owning it as an internal product.
Connect a data source, start with a handful of tables, and let context accumulate from real usage. Business concepts, metrics and reference queries grow out of the questions people actually ask rather than a modelling project you have to finish before anyone gets value. Access controls exist from day one: scope tables per user and per group, so marketing sees marketing data.
It is model-agnostic. Claude, ChatGPT, or whatever your team moves to next; the context stays put. Every question, every query and every step the agent took is logged and attributable.
The part that is hardest to build yourself, and the reason we think this is the right shape, is the feedback loop: the system flags where definitions are missing and where queries are failing, so the data team fixes what is actually breaking instead of guessing. Every other approach on this list leaves you to discover that by hearing about a wrong number secondhand.
Side by side
| LLM directly | Build in-house | Semantic layer | Warehouse AI | Contextflo | |
|---|---|---|---|---|---|
| Setup | Minutes | A quarter | Weeks | Hours to days | ~15 minutes |
| Access control | None | You build it | Varies by tool | Warehouse roles | Per-table, per-user |
| Model lock-in | One provider | You choose | Some | The warehouse's model | Any MCP client |
| Audit trail | None | You build it | Varies by tool | Warehouse query logs | Every question, attributed |
| Knowing context is wrong | No signal | You build it | No signal | No signal | Flagged automatically |
| Token visibility | None | You build it | n/a | None | Per-step |
| Who maintains it | Nobody | Your data team | Your analytics engineer | Your data team | Reviewed, not authored |
Where we are not the answer
Worth being direct about this. If your data is strictly on-prem with regulatory requirements that rule out a cloud connection, we do not fit today.
If you are a platform team at a large company with engineers who want to own this, building it is defensible and you will end up with something shaped exactly like your organisation. The build-versus-buy line is genuinely about whether this is a good use of the quarter, not about whether it is possible.
And if you are one person exploring your own data, use an MCP server directly. All five gaps above are team problems.
Where we are the answer is the middle: a team where the data platform is one or two people who are already at capacity, data in more than one place, and non-technical people who need answers without filing a ticket. That is most of the companies we work with, and it is the setup the product is shaped around.