Every step in the evolution of data stacks leads to more opportunity for data scientists to drive outcomes. Here’s what I’ve seen so far, and where I think we’re going in the post-AI era.
TL;DR
The pre-modern data stack limited a data scientist’s perspective (data moats, small data, structured data). The transition to cloud data warehouses expanded the scope to “ALL company data.” The rise of the Modern Data Stack + Reverse ETL turned data scientists from reporters into operators. Each technological shift expanded the blast radius of what a data team could build and accomplish.
We’re now in the post-AI data stack era. Data teams have two jobs:
- Enable every employee to build with data and AI: accurately, powerfully, independently.
- Build and champion the singular reality their company operates on.
Coding agents, AI-native vendors, and Slackbot analysts have made it easy for anyone to answer their own question and generate their own narrative. As data questions get more personalized and dashboard building gets cheaper, the scarce resource becomes company-wide consensus.
These shifts yet again expand the blast radius of a data scientist: from a “producer of analysis” to the builder of a company’s reality on what’s true, what matters, and why. The job is now encoding data-science-grade judgment as infrastructure for agents.
If you’re well versed in the history of data stacks pre-2024, jump to Post-AI Data Stack.
Pre-Modern Data Stack
I’m positive database technology improved quite a bit from 1970 to 2013, but I wasn’t in the workforce yet. My career started at the tail end of the on-prem era: at Wayfair in 2013, business intelligence ran on top of SQL Server 2012 databases in Waltham, MA. Every once in a while a database administrator would drive 30 minutes down I-90 to add more servers or install an upgrade. Seriously! Their tech blog still has a great 2012 article on Lessons from a Datacenter Move.
Even Steve Conine, one of our co-founders, did an overnight stint at the datacenter helping with the physical move of servers.
There were three brutal sources of friction:
- Data moats: All of Wayfair’s data couldn’t fit on the same database. Querying across databases really didn’t work without a ton of massaging (linked server calls took forever, often failed, didn’t benefit from query optimization, required handholding from DBAs to even access).
- Web analytics: Earlier SQL dialects couldn’t handle semi-structured
VARIANT/JSONobjects and all the functions that go with them. Web traffic is the core of product analytics, and it’s almost always represented as JSON. Functionally, you couldn’t ask web analytics questions without putting rigid pipelines in place (to process famously flexible data). - Big data: Somewhere between 10m and 100m rows, analysis ground to a halt. SQL Server 2012 ran one node, had no ability to scale compute or storage, and was set up for OLTP row-store updates, not column-level analytics.
I worked on pricing and recommendation algorithms; we frequently ran experiments to estimate customer price elasticity. An extremely reasonable question to ask: is a customer’s card issuer a meaningful predictor of price sensitivity? Are BIN 3717 (AMEX Platinum) customers less price sensitive?
At Wayfair’s 2013 scale, this analysis was impossible. The payments data was on a different database than the order data. We didn’t have a semi-structured database, so we didn’t store clickstream, or even log it. And even if we had, querying the product pageviews from one Cyber Monday (100m+) would have failed, and taken down the rest of the reporting with it.
In retrospect, databases in 2013 kind of sucked, which limited the blast radius of the work a data scientist could do, which limited the blast radius of their career. Questions were limited to data that fit on one server, in the right shape.
Cloud Data Warehouse
This vacuum led to the meteoric and well-documented rise of Snowflake / Redshift / GCP. These tools solved three problems an on-prem OLTP SQL Server never could:
- They scaled storage infinitely, taking “all of a company’s data in one place” from a pipe dream to a solved problem.
- They scaled compute infinitely and horizontally, so a data scientist could analyze 100m+ Cyber Monday rows without touching the queries powering critical financial reports.
- They read semi-structured data natively, so web traffic became accessible and funnel analytics became mainstream.
Which in turn expanded the scope of a data scientist to all the data the business touches. You expect a great data scientist to tell the business what matters most, that’s only possible if they can use all of the data.
Modern Data Stack
The next step on the timeline is around 2020: the also-well-documented rise of ETL, Reverse ETL, and the Modern Data Stack. I’ll skip describing the technology and talk more about what it felt like.
When Wayfair rolled out Hadoop as a big data solution, it took a Cloudera implementation team on their end, three data engineers on our end, and four months to get up and running. The tool itself required learning a new language, aggressively managing Java virtual machines, and one big query could break it for everyone else (which happened all the time).
Compare that to the 2020 magic of the Modern Data Stack. If you were a CTO at a company with a Postgres database, a few SaaS apps, and product-market fit, you could hire a head of data, give them a credit card and API creds, and legitimately expect them to have reporting spun up by lunch. You just needed to know SQL.
ETL wasn’t a new concept, but (going back to friction), it had always required begging engineering to build it. The reality that a data scientist could just… have LinkedIn Ads data next to Zendesk data next to company app data expanded the scope yet again. This is especially true of “nice-to-have” analysis: noticing that customers who come in from “no founder credit checks” ads on Meta have worse LTV/CAC, or that customers who come in from referrals file fewer Zendesk tickets. Data teams can’t beg eng teams to build ETL for a nice-to-have. Managed ETL let you click a button and pay at the end of the month.
If ETL expanded what a data scientist could see, Reverse ETL expanded what they could do. Going back to the question of AMEX price sensitivity: previously, the conclusion of that work (“AMEX customers are X% less price sensitive”) would have been a slide in a presentation, with a hope that someone else picked up a follow-through that looked somewhat like the original insight. Reverse ETL moved data science from reporting to operating: all of a sudden data scientists could trigger lifecycle emails in Iterable, update customer segments in Salesforce, change how the core product looks and feels.
Again: a step in the data stack evolution expanded the blast radius.
Post-AI Data Stack
Which brings us to today: 44 months since ChatGPT, 15 months after Claude Code GA. The shape of the post-AI data stack is starting to show, and it will expand the blast radius of what a data scientist is capable of. Here are the requirements I’m seeing, how I think infrastructure will evolve to support them, and a bit on how we’ve solved for them at Ramp.
The five requirements below are the pieces of that diagram, one at a time.
Agent-Consumable Outputs
Data models, dashboards, and analyses are no longer end products, and they will not be primarily consumed by humans. Data team outputs will be consumed through agentic interfaces, on their way to human eyeballs and decisions. The dashboard stops being a destination you link to in sprint planning, and starts being a repository of facts, contracts, and explanations that agents can decompose and reassemble.
Saturday Night Live and podcasts have evolved analogously. The main thing used to be the main thing: you listened to podcasts, you watched SNL, you opened a Looker dashboard every Monday. You opted in. Today the primary unit of SNL shows up on a feed: full skits on YouTube, subsets of skits on TikTok. Same with podcasts: people discover and engage with podcasts through clips that are reviewed by LLMs and surfaced by algorithms, perhaps never watching the original. People might complain about how SNL has changed, but it’s certainly reinvented itself to be broken up and reassembled by agents and algorithms.
The same will happen to data work. By 2027, your CPO will learn how your team’s product launch performed through a subagent, deployed by an agent, that scans every product launch dashboard once a week. Marketers obsess over AEO/SEO, influencers hack recommendation algorithms, and data scientists are learning to do the same. This requires building data products legible to LLMs, the same way websites optimize for Google. What that looks like:
- Declaring a dashboard’s raw code, filters, owners, entry points, folder structure, visualizations, and rendered values in a format designed for LLM consumption: a per-data-product
llms.txtthat renders in markdown. - Provenance instructions on how to go deeper, how the dashboard queries relate to other data models and code, or how they relate to the business: projects, org charts, product roadmaps, company goals.
This is the data equivalent of chopping SNL clips for TikTok. A more favorable way to interpret it: if you design data artifacts to be machine readable and ready for decomposition and reassembly by agents, you ensure your work shows up to drive decisions. It’s your job to be the reason an agent surfaces the right data for the right question. Data outputs not accessible by agents will get as much traffic as websites not accessible by Google.
Make sure your work shows up when the CPO asks their agent how the product launch went.
Agent-Operable Tools
Sales teams spend meaningful fractions of their life in Salesforce, I’ve spent a regrettable meaningful fraction of the last five years in Looker. For a company to truly adopt a data tool, your junior data scientists must be excited to use that tool for hours every day. If you force your team to use a clunky UI in 2026, they will quit.
No data scientist wants to click around web UIs, and this will soon be true for all business stakeholders. OpenAI and Anthropic Chrome extensions are still slow and buggy: teams won’t automate the clicks they used to make. Instead, teams will push work down the stack until they hit something agents can operate on directly with code, and stop using vendors that aren’t agent-operable. It’s an easy call to churn off a tool when your data team and your finance team have both stopped using it.
Agent-operable tools must fit into existing workflows and connect with everything else a data team and company touches. There’s a new cohort of post-AI tools that want to be an end-to-end solution, and want you to use their agent. All you have to do is:
- Write your entire semantic layer and business context in their tool’s proprietary language.
- Keep all of your models, dashboards, and analyses in their tool (and their tool only).
- Send all of your business stakeholders to their tool (and their tool only).
- Let them leverage user activity to improve their understanding of your data and company.
This makes sense for a vendor hoping to become indispensable. But the tools that get adopted will be the ones capable of plugging into platform-agnostic workflows, connected to all of the context and tools an employee has access to. If an agent can only work in one tool, it’s not a helpful agent. That forces a data team into a call:
- Pick one vendor and put all of the context and users of your business into their tool, locking you into a bet on the future of that vendor and interface.
or
- Make your context and connectors as headless as possible, and do your best to ensure that whether someone is using a coworker, a coding agent, a BI tool, or a Slack bot, your data question gets the same answer.
Don’t lock your intelligence into someone else’s interface. Models, harnesses, and interfaces are moving fast enough that whatever user preferences your company has now will look different in a quarter. So the question becomes: how do you ensure consistency across interfaces?
Agent-Consumable Consensus
Pre-AI, data teams created consensus through organization and scarcity. Dashboards were organized in nested folders that matched the org chart, using a combination of verified tags and aggressive curation. If you wanted to know how a company worked, you started by looking through a folder structure. And creating dashboards took a long time! Business stakeholders famously complained about week-long data team delays for basic insights on a product launch. Meanwhile, data teams needed to build new instrumentation, ETL pipelines, dbt models, LookML PRs, and painstakingly handcrafted dashboards, constructed click by click.
Thus the hierarchy of the BI tool implicitly conveyed everything the company cared about enough to both build and maintain a dashboard on. Today, the bottleneck for data work is no longer writing code and making dashboards, and humans navigate data products through agentic interfaces, not by clicking through folder structures.
It’s easier than ever for a product-domain-expert data scientist to run an analysis and spin up a dashboard about an area they understand deeply. It’s also just as easy for everyone else. As Lulu Meservey wrote: “Easier than ever to build, harder than ever to make people care.” Every person can ask a slightly different question, look at a different slice of customer, use a different metric definition, and end up with a different number, and potentially a different conclusion.
Going back to the top: data teams have two jobs in the post-AI era.
- Enable every employee to build with data and AI: accurately, powerfully, independently.
- Build and champion the singular reality their company operates on.
Consensus is not an LLM-generated markdown file, a Slack + Notion MCP, and a bunch of documents stuffed into a context window. Deterministic knowledge (metrics, filters, conventions, table relationships) should be coded deterministically. A trustworthy data agent knows which relationships are valid, which metrics the data is authorized to see, and when a question should be clarified or redefined.
The agent also must inherit the same fine-grained user and data access permissions that a Snowflake grant would. Consensus is what a number means, and who is allowed to see it.
Answer All Questions, Not SQL Questions
Data stakeholders with years of suffering through Looker and Tableau UIs have developed an intuition for what a “SQL-shaped question” looks like. BI tools run on Snowflake under the hood, Snowflake is SQL, and SQL is great at numbers: aggregating, filtering, grouping. SQL is not at all the right tool for answering “Check Gong calls, why are we losing deals in the construction vertical?” or even “What’s the Travel pod’s north star metric?”
As companies move to chat- and agent-first workflows to engage with data, you will increasingly see stakeholders ask every shape of question. Don’t train stakeholders to limit themselves to SQL-shaped questions. Instead, set up your stack to support structured and unstructured flexibly, through the same entry point.
This is possible, but it requires some design in advance. It’s trivial and cheap to aggregate 100m+ rows in a raw transaction table in Snowflake, it is non-trivial and quite expensive to parse 100k raw Gong call transcripts via LLM.
The fix we’ve adopted at Ramp looks a lot like pre-modeling data, but for meaning instead of shape. We run an AI tagger over the entire unstructured dataset, once, offline, and write the output back with the structure we observe in the questions people ask. For Gong: loss_reason, objection_type, mentioned_competitor, the same way a card transaction data model would have normalized vendor and merchant category columns that any future analysis can GROUP BY. You learn how to parse unstructured data by observing the types of questions people ask, then making that ask cheaper and extensible for future questions.
Semantic Layers and Ontologies Are Mainstream
(Being a little self-aggrandizing… bear with me.)
Over the last year, Ramp’s founders, CFO, and Head of IR have talked about how one of the reasons Ramp has been effective at leveraging AI internally is that we have a tremendous semantic layer and well-modeled data. This is true: we’ve worked hard on it for a long time. It’s my second time rolling out a data stack, and so much of the craft of dbt, analytics engineering, and Kimball modeling is about naming things correctly, at the right grain, once, and what goes wrong if you mess it up.
But frankly, if you’d told me two years ago “your CEO will bring up Ramp’s semantic layer on podcasts, your IR team will bring it up on investor calls,” I would have been shocked. Semantic layer opinions are supposed to be for post-conference cocktails after Snowflake Summit and spicy comment sections on dbt Coalesce videos.
There are two reasons semantic layers have cracked the consciousness of the C-suite.
First: companies without data teams and Snowflake/Fivetran bills (the vast majority of America’s 6m companies) are plugging coworking tools and agents directly into their SaaS vendors. This functionally skips the ETL and data modeling step. It lets individuals work fast, but it leads to reproducibility crises, where nothing is correct across the org.
Second: as Satya wrote about in The Reverse Information Paradox, there is value in every question, every “hey, this looks off,” every metric clarification. That is either context compounding within your four walls, or within someone else’s. A company’s semantic layer, and the ontology sitting on top of it, are the guts of internal AI productivity: every correction a data scientist makes is accumulated learning, which compounds only if you build the infrastructure to catch the error, trace the process, and distribute the fix to your entire company.
This is the best argument against connecting agentic vendors directly to your raw data without a semantic layer in between. It’s not just that the answers might be wrong, it’s that every correction and piece of metadata goes toward teaching the vendor about your business instead of fixing your own stack. That’s why the C-suite and the board care: if you’re going to spend mind-boggling and unprecedented amounts on tokens and internal productivity, you better make sure your company’s institutional knowledge compounds as your own asset, not training data for a foundation lab or SaaS vendor.
A good semantic layer encodes all the tribal knowledge (“actually, cleared TPV excludes refunds after day 45,” “the construction vertical mapping changed in Q2-2025”), every judgment call around a metric, every north star metric, drumbeat, and product pod, and pushes them into every system an employee touches, starting from their first day.
This unlocks massive productivity gains at scale. Time-to-ramp shrinks for new grad SWE interns, sales leaders, and everyone in between. ICs learning a new product area don’t start from a blank slate, they inherit the judgment of everyone who came before.
This is leverage, and the expanded blast radius for a data team in the post-AI era: every future question, agent, and hire starts smarter than the one before.
Landing the Plane
Here’s a Stratechery-inspired value chain of the data science lifecycle:
Reality → Data capture → Context/modeling → Analysis → Distribution → Decision/action
Each era removed one constraint, expanded the blast radius of a data scientist, and created a new scarce resource. The cloud data warehouse era let a data scientist store and compute across all of a company’s data. The modern data stack era expanded the data sources even further, and turned data teams into operators.
The post-AI era reduces the cost to build a dashboard or ask a data question to near-zero. This is true for every company hire, on their first day of work. As data output becomes abundant, data output becomes commoditized. The scarce resource is now judgment, influence, and consensus. Pre-AI, consensus emerged through scarcity (expensive dashboards, nested in org chart folders). Post-AI, you engineer it.
The differentiator between an okay data scientist and a great one is their ability to encode judgment, influence, and consensus into infrastructure. The job is now to:
- Frame the right question.
- Correct faulty data, add proper instrumentation.
- Define their pod’s facts-on-the-field reality and north star goals.
- Connect structured and unstructured evidence.
- Drive causal conclusions and operational outcomes.
- Create the LLM-first distribution such that every agent benefits.
- Create the feedback loop such that every interaction and correction compounds.
The highest-value work of a data scientist is no longer to answer one question exceptionally well. It’s to scale their knowledge and ability, such that every future agent, application, decision, and employee begins from the data scientist’s best representation of what’s true, what matters, and why.