Ramp Research: The Analyst Agent That Answers 1,800 Questions a Month
They built an AI analyst in Slack. Now 300 employees ask it questions instead of waiting for the data team.

Ramp published a detailed breakdown of Ramp Research, their internal AI analyst. The numbers: 1,800+ questions answered since August, 300 users, and 10-20x more questions than their legacy help channel. The most interesting part is not the metrics. It is the philosophy behind the build.
The Problem They Solved
Every data team knows the pattern. Questions queue up. Analysts triage. Decisions wait. In Ramp's words: "Data questions don't exactly crash the system, but they quietly slow every decision."
Ramp's team was not drowning. They had a help channel and it worked. But asking cost enough that most questions never got asked. Ramp Research changed the economics:
| Metric | #help-data (legacy) | #ramp-research-beta |
|---|---|---|
| Questions (4 weeks) | 66 | 1,476 |
| Users | Limited | 300+ |
| Response time | Hours to days | Minutes |

When asking costs nothing, everyone asks. The data team went from gatekeeper to enabler.
The Architecture
Ramp Research runs on their existing stack: dbt, Looker, and Snowflake. No new infrastructure. No separate semantic layer. The context layer pulls metadata from all three:
- dbt: Table and column documentation, model relationships
- Looker: Explore definitions, measure calculations
- Snowflake: Schema information, sample values
Domain owners add business context as technical documentation inside the dbt project. That is the key insight: context lives where the data lives.
The agent gets a standard toolkit:
search_tables()for discoveryread_table_documentation()for schema detailsread_domain_document()for business contexttranslate_jargon()for terminologyrun_query()for direct SQL execution
When someone asks a question in Slack, the agent inspects column values, tests hypotheses, and backtracks when needed. Like a human analyst would.

Slack-First Distribution
Ramp Research lives in Slack. Not a separate web app. Not a dashboard. The channel has 500+ members, answers come with in-thread CSV previews, and conversations are multi-turn. The agent joins existing alert and project channels.

This matters more than the AI itself. They put the agent into workflows that already existed instead of asking users to adopt new behavior.
Jay Sobel's Take: dbt Is the Foundation
Jay Sobel, Senior Analytics Engineer at Ramp and a key builder of Ramp Research, explained the philosophy on his Substack: most of the implementation belongs in your dbt project. "dbt + Snowflake is my hammer. Internal agents look like a nail."
Jargon glossaries live as dbt seeds. Domain documents live as doc blocks in model YAML. Even the agent's tools are dbt models querying Snowflake. The advantage: context is code. It gets reviewed, tested, and versioned. When a metric definition changes, the agent's context changes with it.
In a separate post Sobel goes further: semantic layers do not make sense to him. "Creating comprehensive semantic metadata for this complexity is like bringing a label printer to a jungle." His alternative is good naming and plain written documentation. "Just. Write. Paragraphs." The agent then becomes a Trojan horse: frame the work as AI readiness, and suddenly everyone cares about metadata quality.
Ian Macomber's Philosophy
Ian Macomber, Ramp's Head of Analytics Engineering and Data Science, adds the organizational frame. Data teams should not be service organizations: "They're not data science support for the accounting pod. They are the accounting pod." Data people sit inside product teams, so they understand the questions before they are asked.
He is also contrarian on measurement: "Use a data science model or an A/B test as an absolute last resort. The phrase 'measure everything' is actually really lazy." Simple SQL gets you 80% of the insight. And on building versus buying: "Code isn't an asset, it's a liability." Build what is core to your business context. Buy the infrastructure.
What Makes This Work
Slack-native. The agent lives where work happens. No behavior change required.
Context as code. Versioned, reviewed, and deployed alongside the data models it describes.
Embedded data people. They understand the questions before they are asked.
Owned documentation. Domain owners own their context. Someone has to write those documents.
Tested behavior. A Python test framework in the dbt project validates how the agent behaves.
The Gap for Most Teams
Ramp is an $8 billion fintech with a world-class data team. They can build custom agents. Most companies cannot. The pattern transfers, but it requires engineers for the agent framework, analytics engineers for the context architecture, domain experts who maintain documentation, and infrastructure to run it all.

Teams without those resources need platforms that provide the same capabilities out of the box: Slack and Teams deployment, git-synced context, and connections to the data stack without custom engineering.
The Bottom Line
Distribution first. Slack is the difference between a tool people use and a tool people forget.
Documentation is the ceiling. Answer quality tracks documentation quality. For dbt shops, the model docs are already halfway to agent context.
Scoped right. Internal first, not customer-facing. The right place to learn what works.
Demand is the metric. A 10-20x increase in questions asked matters more than any benchmark score.
The future of data teams is not replacing analysts with AI. It is giving everyone analyst-quality answers, in Slack, in minutes instead of days.
Related reading:
- ClickHouse's AgentHouse: When a Database Company Bets on AI
- Uber's QueryGPT: Multi-Agent Architecture for Enterprise Scale
- LinkedIn's SQL Bot: 95% Satisfaction Despite 53% Accuracy
If this excites you, we'd love to hear from you. Get in touch.
Rick Radewagen
Rick is a co-founder of Dot, on a mission to make data accessible to everyone. When he's not building AI-powered analytics, you'll find him obsessing over well-arranged pixels and surprising himself by learning new languages.
