The post-AI data stack vs. the post-data AI stack
A lot of teams now wire Claude straight into HubSpot, Stripe and Zendesk, and that’s the data stack. It works for today’s questions but often not for last quarter’s, and this post covers why and what to add.
Adrian Brudaru
Co-Founder & CDO
6 min read
The post AI data stack
Now that the AI capabilities have reached generally useful levels for coding and retrieval, the modern data stack is evolving into a post-AI data stack. It looks a lot like the stack from only a few years ago, with a few extra components:
- Unstructured data sources such as emails, calls, tickets, turbopuffer for storing this data.
- Docs and codebases no longer optional: Agents need to read them, so code is moving from managed tools to repositories.
- Company context like semantic layers and notion docs.
- Agent harness that can read through the above and funnel into below.
- Chat interfaces and new AI native interfaces.
Building such a stack is becoming the new mandate for data teams, but the pathway to do it is still unclear - many things kind of work, and it’s not always clear what’s important or durable or leading to excellent results. Do you really need all these tools or can you get away with just 10 markdown files and claude?
The post data AI stack
Luckily, LLMs are the new Excel of data stacks - anyone can work with them and so everyone does, and in the process they discover and highlight what is possible without the tool-forward approach.
I’ll call these stacks the “post data AI stack” because they look like a data stack, they answer questions like a data stack, but usually no data person was consulted during the process. And because LLMs can code full stack now, this isn’t just excel, it’s a fully connected, live application with access to application data via MCPs.
It’s just another pre-warehouse stack; and it’s useful to a degree
Most companies start their data efforts with some small data setup - google sheets, a saas dashboard, and nowadays a claude dashboard and MCP that can pull data in for you.
Connect Claude to HubSpot, Stripe, Zendesk and the product database, and you have a stack. There's no warehouse, no data model and no schedule. But in a small team that’s growing their company, this data stack gives a single operator superpowers. With such a stack they can:
- Check each individual connected system and get data from it. Examples:
- How much did we spend on ads last month?
- How many fraud cases do we have on Stripe?
- How many new tickets we have this week in Zendesk?
- Push data to connected systems (so like putting leads in a CRM for example)
- find me top 20 known companies from this conference attendee list and put them in my CRM
- Please summarize the call recording and attach it to Jim Jimson in the CRM
Most of the people building it aren't data people. Founders, RevOps leads, PMs and GTM engineers wire up a renewal brief, a refund workflow or a pipeline review in an afternoon, work that used to wait for a data person to be hired.
None of this makes MCP-only wrong. It’s strong for current-state lookups, for actions that need live state, for exploration in the first hour, and for the long tail of questions nobody would justify a pipeline for. The useful split is that MCP handles “what is true right now about this one thing” well and “what happened over time across many things, defined consistently” badly.
The part we have a data platform for
The post-data stack is good at questions that live in one system and touch a handful of records: look up the ticket, brief me on this account, update the deal. Everything else breaks in ways hard to predict.
Technical failure modes of the MCP stack
- All the records. One Stripe invoice is about 1,100–1,600 tokens, so a single page of 100 is four to six times what Claude Code puts into context from one MCP call by default. HubSpot search stops at 10,000 results per query.
- Several systems. The model joins three result sets in its head. Most models score under 50% on long-context aggregation.
- Time. APIs return current state. Stripe's events API goes back 30 days, and you probably didn’t keep snapshots anywhere.
- Twice. Ask again tomorrow and the agent may fetch different pages and return a different number.
The questions that need definition or joins
Teams also hit “question type” limits before AI. The fix always sounds about the same:
- Put data into a scalable, online data store so you can keep it somewhere and get it back later
- Define the business “source of truth”: Canonical entities, metrics and segments. What is a customer? How do you calculate net revenue? When do we flag an account as “inactive?”
Example questions that the MCP stack cannot answer:
| Question | Spans | What it needs |
|---|---|---|
| Who is an active customer? | Stripe, product events, HubSpot | One agreed rule across three systems |
| Net revenue retention last quarter | Stripe invoices, credits, plan changes | Two quarters of invoices and one agreed formula |
| Signup-to-paid funnel | Ads, product, Stripe, HubSpot | One person matched across four IDs |
| CAC by channel | Google, Meta and LinkedIn ads, signups, Stripe | Spend and new customers matched by channel |
| Support cost vs. revenue per account | Zendesk, HubSpot, Stripe | Accounts matched across tools that name them differently |
| Pipeline coverage | HubSpot deals, quota goals in Google Sheets/Notion | Quotas and deals on the same reps and quarters |
The post-AI data stack doesn’t need to be a research project.
One of the common teams we see when building these stacks is a lack of hollistic understanding around the problem. This type of understanding takes time and research to develop, just like a senior engineer.
For example, everyone agrees we need context and semantics, but beyond that there’s plenty of disagreement as to what a semantic layer should do and what belongs in its scope and what not. Similar with context - folks just throw all they have and let the machine figure it out - and then it kinda works but also kinda fails and you don’t know why.
At the same time, old data models that were built by humans for humans sometimes prove to be unreliable for agents, particularly in larger organisations that suffer from definition and data model sprawl. Humans have the unique ability to suffer from consequences, so they tend to take their time nailing down definitions that a LLM would hallucinate without hesitation.
The post-AI data stack is not an add-on that you strap to your old stack but an upgrade where some older components get replaced with fresh ones built for AI. Luckily, migrations are becoming fast and trivial thanks to LLMs, so upgrading isn’t the hassle it used to be.
Build it with dltHub!
We’ve been working on our version of an autonomous data platform that features a shared context between components, enabling the pathways to agentic data comprehension and agentic development.
These innovations enable users to prompt agents to do all the usual platform tasks:
- Build pipelines with coding agents
- Maintain pipelines with coding agents
- Deploy and operate pipelines with coding agents
- Model for agents: Generate canonical models, ontology and semantics for your data
- Explore and analyze data: Use the agent native model to answer simple and complex questions accurately.
- Use the insights to enrich application data (reverse ETL to back to transactional systems)
Book a demo or try it by telling your agent “Run uvx dlthub-start@latest to build my first pipeline and run it on dltHub”.
