Point of view

The post-AI data stack is right. Most companies shouldn't have to build it.

Ramp's Ian Macomber mapped the post-AI data stack. Here's what it means for data leaders who need trust at scale.

Shapor Naghibzadeh CEO & Co-Founder
Sep 3, 2026

Ian Macomber runs analytics at Ramp, and this week he published the best description I've read of what data work becomes after AI: The Shape and Feel of the Post-AI Data Stack. If you run a data team, read it before you read anything else — including the rest of this post.

His core claim is the one that matters: AI makes producing analysis cheap. It does not make agreeing on reality cheap. Dashboards cost nothing to make now. Every person can ask a slightly different question, use a slightly different definition, get a different number, and walk into the same meeting holding a different reality. The scarce resource is no longer analysis.

The scarce resource is consensus.

By consensus, I mean something very specific: a shared, defensible reality that survives the edit. Across teams. Across tools. And across time.

We arrived at the same diagnosis from a different direction. Security taught us that trust in the data is existential: a fast answer nobody can defend is worse than a slow one. Our launch essay made the same argument in different words: the goal isn't more answers, it's a story your whole company can act on. One reality, evidence attached. Ian just gave that idea its sharpest vocabulary yet. "Consensus divergence rate," the share of questions whose answer changes depending on where you asked, deserves to become an industry standard.


What the architecture asks for

Ian's post is worth reading for the specifics alone. He describes an internal BI tool designed hand-in-hand with a research agent. A harness that replays every question across each interface and model combination and flags when the traces differ. Practitioner-defined taxonomies over sales calls, running as versioned prompts on their own infrastructure. A failure taxonomy of evals, snapshotted with the model, prompt, tools, and knowledge hashes of every run. A data team whose job includes writing domain docs and evals.

And none of it is a one-time build. Businesses reorganize, acquire, redefine their segments, change what they sell. Every one of those moves invalidates a definition somewhere and sends the stack back for rework. That is a standing cost, and standing costs belong to whoever can amortize them.

The architecture is right. Keeping it right is the work.


Security ran this movie already

Before scalable security data platforms existed, security teams did what every team does when the tooling can't keep up: they shrank the question. High-volume sources like DNS, netflow, and endpoint telemetry were sampled, aged out in days, or shipped to cold storage that no investigation would ever touch. Nobody wrote a memo announcing it. The questions just quietly narrowed to fit what was hot.

Analytics shrinks the question the same way. Price sensitivity never gets measured. Account prioritization never gets built. Not because nobody wants the answer — because getting it is too hard inside the constraints of what the stack can hold today. The ad hoc spreadsheets, the call recordings, the immature sources that never earn a pipeline: none of it is refused outright, it just never becomes askable. When the stack can't hold something, the business learns not to ask about it.

A few engineering organizations refused to shrink the question and built their own systems, because nothing they could buy did the job. Google was one of them; that refusal is where Chronicle came from, and a product category followed it.

The pattern repeats: systems get built in-house first, and the description of what got built is the map everyone else navigates by.


The same architecture, as a product

QueryStory is what that architecture looks like when it arrives as a product instead of a project.

Ian's first requirement is that outputs be agent-readable: artifacts that agents can decompose and reassemble without losing the meaning. Every QueryStory output already carries its sources, definitions, assumptions, and the queries behind it. People read it as a brief, a deck, a dashboard. Agents read the same thing through MCP. He quotes a line from Ali Spittel: "i really don't want to use your agent, i want to use my agent to use your thing." Agreed. That's why the context lives in the platform, and any agent (ours, yours, your coding agent, your chat tool) gets the same governed answer.

On consensus, he wants it tested: ask the same question everywhere, count the distinct answers, chase every divergence. That loop is what our golden query sets do continuously: the questions your team actually asks, re-run as the data and context change and scored over time, so the moment an answer drifts, someone knows before it's raised in a meeting.

On corrections, he is blunt: "every correction a data scientist makes is accumulated learning, which only compounds if you build the infrastructure to catch the error, trace the process, and distribute the fix to your entire company." The context is curated by your domain experts, reviewed by your team, applied to every answer, and visible the whole way through. The judgment stays yours.


The part I'd add: consensus decays

One extension to his frame. His test loop catches divergence across interfaces — same question, different tool, different answer. The quieter failure is divergence across time.

A definition that was consensus in Q1 silently stops being consensus in Q3: the pipeline changed, the vertical mapping moved, the metric's owner left. Nobody re-asks the question, so nobody notices — until a board number gets challenged and the archaeology starts.

That's why verification can't be a launch-day exercise. Answers have to be re-checked continuously against the questions that matter, and the system has to tell you the moment an answer stops being right. Consensus isn't a state you reach. It's a state you keep.


The job, either way

Ian closes with a job description for the post-AI data scientist I'd adopt as written: make sure the meaning survives the edit, through every recombination and every interface you can't predict. That's exactly right, and it's bigger than any one team.

His is not the only published account. Several teams have written up the architecture they built for themselves, and the descriptions rhyme.

His post is a blueprint. The blueprint was never the hard part. Every company is about to run on agent-produced analysis. The meaning still has to survive the edit.

In the post-AI era, the winner isn't the team that generates the most insights. It's the team that can publish the most trusted decisions.

That's the job we're doing.