We gave everyone at Clay their own data scientist

Over the past decade, most data teams have converged on a common “modern data stack” approach to data collection and storage: pull data from every corner of the business, centralize it in a warehouse, transform it into well-defined models, test it for quality, and make it available for analysis. The result is a reliable source of truth, governed by a highly technical data team, with enormous potential value.

Yet despite these advances, insight extraction from this well-organized warehouse remains astonishingly slow, and in some organizations actual value from data is only rarely realized. This is because with this tech stack, traveling from data (no matter how tidy) to business insight requires a specialized data skillset: SQL knowledge, a mental map of the warehouse, business context, and analytical judgement. In building a well-maintained data warehouse, we have built a fortress only accessible by a few.

As a result, data teams have a never-ending queue of requests. In most organizations, this means only questions deemed “top priority” or popular are answered in a timely fashion. A long tail of questions remains, most of which will never be answered.

At Clay, we know that when "non-data people" get their hands on data, they ask new questions and bring new perspectives, informed by their diverse domain expertise: there can be real value in the long tail. And when everyone can use data like a data scientist, a healthy data culture is born organically rather than mandated and enforced. The data team becomes enablers rather than blockers.

So we built monty: an in-house analytics agent to power self-serve analytics at scale.

Meet monty, Clay’s self-serve analytics agent

monty is an analytics agent, built on Vercel’s eve framework, running Opus for inference. It can query Snowflake directly, through permissions intentionally limited to approved data models. monty does not provide unrestricted warehouse access. Instead, it operates within the same governed analytical layer our data team maintains. It has a Python environment for data visualization and statistical inference. And to actually put those tools to use, it leans on a library of skills and a context layer that tells it how everything fits together.

We built it to live where people already work: Slack. Teammates ask a question in plain English by simply typing @monty in our #ask-monty channel, and an answer is delivered to the thread in a minute or two.

Our guiding core principles

Before any building, we established a core set of principles for monty:

1. The agent should reason, analyze, and respond like a trusted member of the data team; any user should feel like they’re talking directly to one of us.
2. The agent should know the difference between the questions it should attempt to answer and those it shouldn’t. When it can’t answer a question, it should escalate.
3. The agent should use only data the team has modeled, validated, and documented properly.
4. The agent should grow its knowledge as the data team does: as more data models and skills are built, the agent should automatically inherit them.

Using these principles as a guide, we got to work.

How we built monty

At the highest level, we wanted monty to reason, analyze, and respond like a trusted member of the data team. An LLM gives an agent the ability to reason, but making it operate like a member of the data team requires more than just raw intelligence; it requires providing the agent with vetted data models, reusable skills, and a context layer. This was the toughest challenge and ultimately the work that brought monty from a mildly helpful bot to an indispensable problem-solver. Below we share the ingredients all teams can use to build their own monty.

Ingredient 1: a pristine data modeling layer

For an analytics agent to work reliably, a pristine data modeling layer is required. Without clean, modeled data, the LLM must make sense of a sea of raw tables on every single question it's asked. A proper data modeling layer is the difference between one or two steps to an answer and 100, between a few JOIN and WHERE statements with almost no assumptions, and hundreds of CTEs full of them.

Because an LLM is probabilistic, the fewer paths you give it, the less likely it is to provide an incorrect response. Clean data models cut down the routes it can take to a wrong answer, and cut down the decisions it has to make in the first place.

For Clay's data team, a data modeling layer has meant that anything and everything used for analytical purposes goes through dbt in a clean, scalable way. Every metric, every entity, every fact and dimension table lives in dbt. Even the data powering our dashboards is predominantly just "select all" statements from dbt models. No foundational business logic sits outside the dbt modeling layer.

This foundation lets monty shine. It meant the context layer, which we'll cover next, was simply a matter of teaching monty about those models.

Ingredient 2: code as the context layer

At Clay, the data team is code-first. Our dbt models, Dagster implementation, agent skills, Streamlit dashboards, notebook analyses, and documentation all live in a monolithic codebase that everyone is expected to contribute to.

This means our codebase is incredibly context rich in itself, which is why we made the decision to build our context layer around it. At the beginning of every session, monty copies our codebase into its filesystem. This approach has two core benefits:

1. We don't maintain a context layer separate from our codebase. Developing the codebase is developing the context layer. Any time a PR is pushed with new dbt models and documentation or skills, new context is automatically available for monty.
2. The context can be ported to any agent environment. The harnesses obviously differ, but anyone in tools like Cursor, Codex, or Claude Code can build and analyze with the same core context monty uses.

Ingredient 3: guided, hierarchical context navigation

By copying our entire codebase into monty's filesystem, we give monty a huge amount of potential context to work with. None of this context is loaded into the context window unless it's relevant to the question at hand.

To do this, we taught monty to navigate the system with progressive disclosure in mind. Every folder in our codebase has a catalog.yml file. This file is a lightweight index of what lives inside of that folder and which files might contain relevant, detailed information for the question at hand. For any question, monty reads the catalog, identifies potentially relevant information, opens the file with that relevant information, and synthesizes it.

On top of minimizing cost, our design also minimizes error. In its system prompt, monty is taught to work through three layers of context, starting with the most deterministic and falling back to less deterministic ones only as necessary:

• Skills: Skills are a predefined playbook to answer a specific question, including a prescribed methodology and clean description of which data models to use and how to use them. If monty chooses to use a relevant skill, it is very likely to answer the question correctly.
• Metrics: We pre-calculate key metrics across common dimensions and time grains. When asked about a metric, monty uses these pre-aggregations by default. If the question requires a dimension we haven’t pre-computed yet, it reads the metric’s context file, learns the correct definition, joins to our dimensions table, and computes the metric on the fly.

• Models: If monty can’t answer from skills or metrics, it falls back to writing ad-hoc queries against approved dbt models. Because it can read each model’s SQL, documentation, and lineage, it has proper context to choose the correct tables and joins.

Ingredient 4: a system prompt that emulates a data scientist

The system prompt ensures monty behaves in a consistent, predictable way every time it is asked a question. It is also where we encode the data team’s analytical standards into monty’s system. This means encoding how we frame analytical problems and how we communicate conclusions.

The three core features of our system prompt are:

1. Role Awareness: This shapes monty’s understanding of who it is and what it’s meant to do. Chiefly, it describes its role and scope as an analytics agent, while also defining its boundaries.
   1. If asked to do anything outside of analytical work, monty will let the user know it’s out of scope.
   2. Just as importantly, if it is asked to answer a question it isn’t capable of answering–due to the complexity or simply not having the data–it will say so and escalate to a data team member.
   3. If asked to answer a question with data that is available, but not in our dbt models, it will refuse to answer the question and escalate to the data team, suggesting we build new models for this specific use case.
2. Analytical Thinking: We provide monty an analytical constitution so it approaches every question with the same core principles any member of the data team would. As an example, if monty senses a question is implying the exploration of a causal relationship, it will describe the relationship with observational data and then remind the user that this is simply correlation, not causation.
3. Response Discipline: This provides monty with clear instructions on how each and every response should look and feel, providing a consistent, familiar experience.‍
   
   • Rules of Engagement: This teaches monty the three possible flavors of messages it can send the end-user. Anything outside of the following is strictly outside of monty’s rules of engagement:
     
     • A clarifying question it cannot proceed without
     • A refusal or escalation of the question to the data team
     • A final answer to a question‍
   • Reply shape: monty is taught to lead with the high-level story, followed by the nitty-gritty details, then caveats. It then provides a provenance footer, helping the end-user quickly intuit how it arrived at this answer and how much they should trust it.‍
   • Visualization: monty is nudged to visualize data by default when it would help the message land. When appropriate, it creates a graphic within its python environment and uploads the image to Slack, along with its write-up.

monty at work

The best way to understand monty is to watch it think. Below is a real question from #ask-monty, with the full agentic loop behind the answer. Click into monty's agentic loop to see each step it took between question and answer.

monty's reception

Because monty has access to analytical models across many parts of the business, monty has experienced organic adoption across a wide range of teams at Clay. Most people were curious about its capabilities, asked a few questions, and were provided helpful answers.

Enterprise Account Owners regularly ask it about account health and product usage patterns. Product Managers pull feature adoption metrics and debug funnels. Finance tracks revenue trends and analyzes metric performance. User Research uses it to segment users and understand behavior. Growth Marketing relies on it for campaign performance, website analytics, and self-serve funnel optimization. And they won’t stop talking about it.

And while folks internally won’t stop talking about it, they also won't stop talking with it. monty has been live for just over two months, and 30%-40% of the company is using it on a weekly basis. 84% of new users return to ask another question after their first. Users average roughly 2-3 questions per week. monty’s biggest power users ask upwards of 10+ per week.

Perhaps most surprising, even our data scientists love to use it. Although it doesn’t quite replace a notebook experience, being able to burn through a few pressing questions in a matter of minutes is powerful. Some data scientists even do lightweight statistical inference and regression modeling with monty.

The future of data teams

What does this all mean for data teams? We believe tools like monty empower data teams rather than threaten them.

In an organization with monty, Analytics Engineers’ jobs become even more essential. In a world where you’ve given anyone the ability to perform analytics on trusted data models, you need people who can (a) create and maintain the data universe for monty to query within and (b) guarantee that data’s accuracy today and tomorrow. Analytics Engineers are the folks best suited for this.

Data Scientists get to spend most of their time on the most difficult problems a company needs solved. This work is far more fulfilling than regularly answering basic analytical questions, and it drives more ROI for the company.

Finally, this setup increases a company’s demand for the data team’s work. Before monty, only a small fraction of people could get value from data. Now, nearly everyone can. People who previously never asked questions now do, and once they see the value, those questions beget more questions. Over time, those questions move from basic to more sophisticated as people think more deeply about their domain and the role data can play in it.

When more "non-data people" get their hands on data, an organization’s culture shifts, and the dream and promise of data teams become more likely to be a reality: an organization where every person uses data in their decision-making.

‍