The scarce resource is consensus (Ian Macomber)
When building data artifacts is fast and cheap, the scarce resource is company-wide consensus. Ramp's Ian Macomber returns to talk about post-AI data teams.
Ian Macomber leads data at Ramp, and he is one of the sharpest data leaders around. He was last on the show in August 2023, for an episode called Ramp’s $8 billion data strategy. Tristan gave me the feedback then that the headline was clickbait. Fair enough. Ramp is worth $44 billion now. As Ian puts it, all of us are relearning how to do our jobs.
We had Ian back because of a note Ian sent Tristan in dbt Slack. As building data artifacts gets faster and cheaper, Ian wrote, the scarce resource is company-wide consensus. It is a deceptively big idea. If anyone can spin up a dashboard or ask a question in natural language and get an answer, the hard part is no longer producing the analysis. The hard part is getting everyone to agree on a single version of reality, and keeping them there.
Ian frames the post-AI data team as having two jobs. Job one is to enable every employee to use data accurately, powerfully, and independently. Job two is to build and champion the singular reality the company operates on. Over the last year, Ramp made enormous progress on job one, partly at the expense of job two, and this conversation is about both: how they got self-serve to 50x scale with an internal tool called Ramp Research, and why the next frontier is manufacturing consensus for humans and agents alike.
Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.
The agenda for dbt Summit 2026 is live. Dozens of sessions across analytics engineering, AI-ready data, agentic workflows, and enterprise scale, September 15-18 at The Cosmopolitan in Las Vegas. dbt Summit is the world's largest gathering of dbt users. Level up and start building your schedule: Explore the sessions.
Listen now: Spotify · Apple Podcasts · YouTube · Amazon Music · RSS
Three ideas from the episode
1. When building is cheap, consensus is the scarce resource. Analysis and dashboard building have never been cheaper. But your metrics are only your metrics because everyone agrees they are, and maintaining that shared reality is now the data team’s highest-value work. As Ian puts it, a 7-out-of-10 dashboard is dangerous precisely because bad data fails quietly, where bad design fails loudly.
2. Route agents through an abstraction layer, not the raw data lake. Ramp Research has effectively become the API to Ramp’s data lake. A finance analyst can build a stateful app on top of it, and it comes with the evals, permissions, and telemetry that let the team trust the answers. When teams instead wired agents straight to a source like Gong, they burned tokens fast and got noisier results; pulling that data through the lake and summarizing it cut the size roughly 20x.
3. Optimize for your fastest movers, not the median employee. Ian’s biggest do-over: the team was too empathetic. Rather than protecting the median employee from the terminal, they should have backed the most resourceful people early, made them champions, and let the rest follow. That, plus retiring the token leaderboard once everyone was on board, is how Ramp moved from a “token maxing era” to what Ian calls value on intelligence.
Key takeaways
Lightly edited for clarity.
Tristan Handy: It has been about two years since your last appearance. What has changed?
Ian Macomber: I lead Ramp’s data team, and I have been here four and a half years. When we spoke in August 2023, the episode was called “Ramp’s $8 billion data strategy.” It is now a $44 billion data strategy. And I can tell you that in 2023 I felt like I knew how to do my job. It has entirely changed since then. All of us are relearning how to do our jobs.
A lot of the hard work we did early on is having its moment now. We had people who were really particular about best practices with dbt, with data modeling, with semantic layers and single sources of truth. Much of what we have been able to unlock with AI internally is because of that work. Our CTO knows it. Four years ago I did not have a sense that being opinionated about Kimball versus Data Vault would ever be in the public consciousness, but it turns out those decisions are what let you unlock really cool experiences.
Is there a higher ceiling now on what a great data team can produce?
Completely agree, and it is compounding exponentially. All the decisions we made to set up our stack for text-to-SQL now work for longer-duration, more powerful use cases. All we have had to do is put in more powerful models, give them more powerful tools, and let them run in loops. We no longer have just a junior analyst running in a loop, we have a staff-level applied scientist running in a loop. Our finance team does a roll-forward of their financial model and we can close the books. The scaffolding was there the whole time. It was a little past the frontier of a 3.5 model, then it was inside the frontier of a 4. Now we will see what happens with Fable 5.
You wrote that Ramp’s data team has two jobs. What are they?
In the post-AI world, Ramp’s data team has two jobs. Job one is to enable every employee at Ramp to use data accurately, powerfully, and independently. Job two is to build and champion the singular reality for Ramp to operate on. Over the last year we made substantial progress on one at the expense of two. We have sprawling data products that are locally coherent but globally inconsistent. As data questions become more personalized, and as analysis and dashboard building become cheaper, the scarce resource is company-wide consensus.
Start with job one. What did you build?
Ever since ChatGPT came out, companies kept asking when they would get text-to-SQL. Early on the vendors were not there and our internal attempts were not there. What got us there was better context, more powerful agents, and tools running in loops. The first product was a Slack bot called Ramp Research, which Tristan wrote a blog post about.
The most eye-opening part was how many questions were going unasked. A lot of them were not groundbreaking, like “how many dentists are on Ramp?” Someone asked because they were about to meet with a dentist in five minutes. They could have pulled it in Looker, but it would have taken too long and it was not worth the bother. Once we launched, the number of questions asked per day went up about 10x, then about 50x, within six months.
We also went in thinking everything had to be right 100% of the time or people would lose trust. I do not think that is true. The fastest way to the best end state is to put something out, watch people engage with it, and study the failure modes. Our CFO asked questions that ended up in the board deck and we got them wrong, but we figured it out quickly. We do pay extra attention when execs are asking board-deck questions.
How did Ramp Research go from a Slack bot to something people build on?
The Slack bot was ephemeral and only really worked on SQL. (Ramp wrote about how Ramp Research works on its engineering blog: Meet Ramp Research.) When coding agents arrived, we asked how we could give someone in Cursor or Claude Code or Codex access to it. So we increasingly built Ramp Research as a repo, a tool, and an interface you can put wherever you want.
Here is a specific example. When a business joins Ramp, we often look at their credit card statements to parse out the interchange rate. That used to be a heavy manual matching process we only did for big businesses. Someone on the finance team built an app for that exact use case on top of Snowflake, a semantic model, and a bit of stateful logic. Now, anytime someone gives us three credit card statements, we calculate it in 30 seconds instead of three hours. No other company needs this app, and no one else at Ramp needs it, but that person could build it.
So Ramp Research has become the API to your data lake?
That is right. That finance app takes a dependency on the general MCP we have for answering questions with Ramp data. You would not want someone building this without the abstraction layer Ramp Research provides, because that is how you feel confident they are getting good answers. And we want to bundle “ask a question of the data” as a Lego block that other tasks can use. Someone preparing for a sales call does not arrive with 15 discrete questions, they arrive with a need, so we help people think about what to ask.
At Snowflake Summit, every vendor booth used the word “agent.” How far along are we really?
Coding agents are consuming a tremendous number of tokens, and there are real production use cases in customer support and in the original kind of Ramp Research tool. But beyond those, the tail gets long fast. Our approach is to give teams primitives and trust them to be creative, rather than run an internal forward-deployed team that goes out collecting agent ideas.
An analogy: the first time we installed Claude Cowork on the finance team’s computers, a lot of the connectors did not work well. It works much better now. Cowork did not necessarily get better; the tools and the context got better, and that made the whole experience better. I would loosely call it harness engineering. One thing we are proud of, and hope is a moat, is that we hold money transmitter licenses in 50 states, so agentic experiences built on Ramp can move money in all 50 states.
How does the analytics engineer’s job change in this world?
Barry McCardel at Hex has talked about this. If the old expectation of an analytics engineer was that you could model your world well, understand dim and fact tables, curate a single source of truth, test it, and bring software engineering best practices to data transformation, then the new expectation is that you also make everything you touch readable by agents. How do you show up in queries, in code search, how do you write context files, how do you build tools for other people to use? That is where our focus has shifted, giving people primitives and assuming they will be creative and entrepreneurial in how they assemble them.
A lot of agents are not being built on the data lake. What are you seeing?
We had people building agents that connected directly to Gong to understand customer feedback, and they burned through tokens incredibly quickly, because a single Gong call is somewhere between 10,000 and 50,000 tokens and you usually need several. We now ingest that into the data lake and run summarization on top, and it turns out a lot of a Gong call is not much signal, so you can shrink it about 20x. Sourcing it through the data lake is more efficient than pulling it straight from Gong over MCP. But most of the time that is not what is happening. People still just connect the MCP server. I think there is a generalized anxiety about connecting agents to data lakes, and part of it is fear of the unknown.
What about permissions? Does connecting agents create new risk?
We were very buttoned up before large language models, and that helps. We have a talented data platform engineering team, and we have genuinely sensitive data: the results of KYC and KYB checks, Social Security numbers, full credit cards, and the shipping addresses and phone numbers of very famous people. We have thought about this the whole time, so we are tightly principled about it. The unit is still the human being. If your warehouse permissions were buttoned up before, an agent accessing data on a user’s behalf is fundamentally not that different from the human accessing it. I would state it a little more softly than “no new risk,” because there is surely a risk we do not know about yet, but it lets us move faster and experiment with confidence.
Where we want to get smarter is on judgment. A prospective partner once asked for our exact revenue growth numbers, and our CFO’s reaction was that they do not need that to evaluate Ramp, we can give them a proxy. That is the question behind the question. In a previous era someone might have been stymied because they could not self-serve. Now they could just ask a coding agent. So this is less about the data itself and more about strategic matters of taste, which is maybe a 20% tooling problem and an 80% people and enablement problem.
Does the security team’s relationship with the data team change?
It is different in fintech than in e-commerce. We never had credit card numbers, Social Security numbers, or KYC and KYB data in Snowflake, because you cannot do analysis on those. They are operational, one-at-a-time values; you are never going to take a sum of Social Security numbers. So the security team has always been opinionated about what lands in the warehouse, and we have even pushed the other way, telling them to get rid of something like CVVs and make sure it never happens again. Knowing exactly what is and is not in Snowflake is a big part of what lets us go faster.
Looking back on job one, what would you do differently?
We were too empathetic. People said non-engineers would hate the terminal and get confused. But nothing is like coding agents, and coding agents let you debug the terminal from the terminal. We assumed the finance team, the only team on Windows, could not figure it out. Then the woman who wrote the finance team’s onboarding docs, who was on the finance team herself, just hacked at it with ChatGPT and Claude Code and set everyone up. Three people started using a ton of tokens and building incredible things, others got jealous because their work got faster, and we rewarded that at all-hands and in perf reviews. Before long it was 50% of the team. In retrospect we should have optimized for the fastest-moving people, made them champions, and doubled down there.
Tell me about the token maxing era.
We had a leaderboard, and a leaderboard really matters when not everyone is using the tools yet. The data team was the first at Ramp to hit 100% coding-agent usage in a week. We were blunt: if you are not using these tools, that is an existential threat to your job. We generated some AI slop along the way, but that is how you get good at painting, you start by being bad at it. Eventually the bill came due, it was expensive, and we retired the board. Now the message is that tokens are a resource like headcount or AWS. Setting your token budget to a million is not a good proxy for anything. Talk to me about the outcomes you are going to drive. That is how we moved from token maxing to value on intelligence.
On job two, do you really not have a shared reality?
Think about how there used to be three channels on television and everyone roughly agreed on what was going on, and now everyone watches something different on Netflix. That is where we are. For over a year, 1,500 people could ask “how many trips were taken on Ramp Travel” slightly differently and get 1,500 slightly different answers. What we lacked was a way to say what the travel team actually looks at every day, what their North Star is.
Our chief product officer built a dashboard for one of our pods, and it was a 7 out of 10. That is dangerous, because 7-out-of-10 design fails loudly, the pixels are off, but 7-out-of-10 data fails quietly, because people just ask the wrong questions. At first we were defensive, wondering why we were debugging the CPO’s dashboard. But he had searched for a dashboard, could not find one that had been touched in five months with a low view count, so he knew no team was obsessing over it, and he built his own. We had a vacuum of data leadership, and it got filled with a 7-out-of-10 dashboard.
So how do you build consensus, for humans and for agents?
It is almost an answer-engine-optimization mindset. What are the questions you want to show up for, and what work do you need to do to define the consensus answer? The best way to command attention is to build something incredible and then distribute it very loudly, going to the channel, beating the drum, populating your section of the sprint-planning slides with a strong opinion. People asking slop questions are mostly just looking for consensus, and if you provide it they would rather use yours than do the analysis themselves.
For agents, we have had PRs this week describing our canonical dashboards and metrics. A lot of that used to live in a Notion database, and we are pulling it back into our dbt repo. When you get exposed to any of our tables, code, or context, it should tell you this is the vendor management product team, here is the PM, the data scientist, the North Star, and the North Star dashboard. So the same way you can ask “how many vendors are managed on Ramp” and get an answer from SQL against Snowflake, you also get pointed to the North Star. We have not landed that work yet, but that is the goal.
Have you found you can give agents context without overwhelming them?
Yes, and the way to solve it is to have evals in place. If one skill is good and two is better, at some point you have a thousand and have to pare it back. We know all the questions asked of Ramp Research, so we know when too many skills get invoked, when a skill is missing, and when it makes sense to add one, all through telemetry. We are basically becoming product managers of an internal product. We also test accuracy by asking several different models the same question with the same context and comparing. Some questions get the same correct answer 10 out of 10 times, others hit 7 out of 10 or 4 out of 10, and then we go inspect the tool calls. You do not need 10 humans to ask a question 10 ways, you can have 10 models do it and find the inconsistency yourself.
The biggest accelerant for someone like me, with lots of ideas and few hours and limited coding skills, has been log parsing. When you evaluate your agent, it raises the seriousness of the project. Agents are unreasonably effective when you give them something to verify, so a big chunk of the data team’s work is building that factory: the right loop, the right metric, and translating it back to product and operations teams.
How is the data team itself changing?
We consolidated a lot of job families. We used to separate analytics engineers, product data scientists, applied AI engineers, and machine learning engineers by the skills they used. But interns and new grads were contributing to every codebase in their first six weeks, so we decided everyone is just a data scientist. We changed how we interview too. Four years ago we would ask what XGBoost is and how it differs from a linear regression. Now we test just-in-time coding ability. A take-home looks like real work: here is $100 of AI tokens, see how far you get, then tell me how you would solve it with two months and a team. The number one thing is that you deliver customer outcomes and make your team feel you are indispensable.
We brought in a woman who had done investment banking, private equity, and strategic finance, and joined to pivot into data. It took her about six weeks to learn our stack and about three months to be good at it. Now she is in our CFO’s ear because she anticipates what the finance team needs better than anyone else could. That is the scarce thing, influence. Her data science skill set is not her limiting factor, business context is, and she is the best at it. I will add one caveat: our economists and statistically trained people still do exceptionally well, because these models are bad at reasoning about causality. Bringing an applied-scientist mindset, asking how you would express a problem and know if you are right, is a skill set we are doubling down on.
You publish a monthly AI Index. Any tidbits that are not written up yet?
The big thing we are watching is that SaaS vendors who built AI features are starting to hit product-market fit, and it is getting expensive at inference time. For the first time they have meaningful variable costs to serve their software, and they are passing those through to customers. Procurement cycles for SaaS usually take a year, but we are seeing vendors that were never AI companies introduce AI pricing, AI credits, and tokens mid-contract. A lot of businesses think this does not apply to them, and then their Salesforce, Notion, and Zendesk bills show line items they never contracted for at the start of the year. We can see and benchmark this because people pay their invoices on Ramp and we get line-item detail, so we want to give companies helpful insight into all pockets of AI spend, which is changing faster than almost anything.
Chapters
Timestamps are approximate.
00:00 — Cold open: consensus is the scarce resource
01:33 — Welcome back: reintroducing Ian and Ramp
02:06 — From an $8 billion data strategy to a $44 billion one
02:41 — How the team grew, and why the early best practices pay off now
03:49 — A higher ceiling for great data teams
04:26 — Setting up the stack for text-to-SQL
05:34 — The two jobs of a post-AI data team
07:02 — Job one: Ramp Research and the questions that went unasked
08:20 — From 10x to 50x questions in six months
09:15 — Ramp Research as a repo, tool, and interface
10:00 — A finance app built on top of Ramp Research
12:09 — Ramp Research as the API to the data lake
13:29 — Asking questions of data as a Lego block
13:46 — Snowflake Summit and the word “agent”
15:23 — Primitives, not a forward-deployed team
15:41 — Harness engineering and the fintech moat
16:36 — The analytics engineer, now building for agents
17:37 — Why agents are not built on the data lake
18:06 — The Gong tokens problem, solved through the lake
19:14 — Anxiety about connecting agents to data lakes
19:37 — Permissions: the unit is still the human
21:08 — Judgment, taste, and the question behind the question
22:29 — If the warehouse was buttoned up, agents do not add new risk
23:11 — The data team and the security team, working together
24:07 — Fintech vs. e-commerce: what lands in the warehouse
25:43 — “We were too empathetic”
26:39 — The finance team’s self-taught champion
27:18 — AI-win case studies and hackathons
27:33 — The token maxing era and the leaderboard
28:37 — From token maxing to value on intelligence
28:54 — Job two: building a singular reality
29:27 — Three TV channels vs. Netflix
30:22 — The 7-out-of-10 dashboard problem
31:01 — Three failure modes of a bad dashboard
32:20 — A vacuum of data leadership
32:51 — An answer-engine-optimization mindset for data teams
33:08 — Chasing slop vs. creating meaning
34:11 — Commanding attention when analysis is cheap
35:44 — Building consensus in a world of agents
36:22 — Canonical metrics moving into the dbt repo
37:34 — Context without overwhelming the agent
38:29 — Evals, skills, and paring back
39:09 — Becoming product managers of an internal product
39:44 — Testing accuracy with multiple models
40:21 — Log parsing and telemetry for agents
41:32 — Consolidating the data team’s job families
42:08 — Interviewing for just-in-time skills
43:22 — The strategic finance hire who out-anticipates everyone
44:09 — Organizational change and durable skills
45:21 — Why economists and causal thinkers still win
45:55 — The AI Index and what Ramp is watching
46:57 — SaaS vendors passing through AI costs
49:27 — Wrap-up
This newsletter is sponsored by dbt Labs. Discover why more than 80,000 data teams use dbt to accelerate their data development.