Operationalize analytics agents: dbt AI updates + Mammoth’s AE agent in action

In conversations with customers of all sizes - from small startups to some of the largest enterprises in the world - three themes consistently surface when it comes to AI and analytics workflows.

The first is conversational analytics. Business users want to ask questions of their data, but in a governed, reliable way. The answers they get need to be consistent, predictable, and above all, accurate.

Accuracy itself exists on a spectrum. Sometimes, you need precision every single time. Sometimes, a well-reasoned ballpark is enough. The challenge is building agents and experiences that can navigate that spectrum for your end users.

The second is development acceleration. This is one of the biggest use cases we see across the industry: How do you accelerate the speed at which you ship data products with agents?

Modern LLMs are powerful and very good at generating code, But they don't necessarily understand the dependencies in your data. How do you make these agents effective? How do you help them understand what your data actually means, so they can generate code that makes sense for your codebase, your data architecture, and your schema?

The third is cost control. How do you get all these benefits - the magic, the speed, the accuracy - without your costs ballooning?

Token costs might be cheap in isolation. When there's a lot of usage, however, not all of it is equally productive. The challenge is balancing consistency, accuracy, and speed without letting costs spiral.

Giving agents the context they need

What we're trying to do at dbt is give AI tools, agents, and the experiences you build on top of LLMs the context they need about your data so they can make effective decisions. LLMs are good at generating code. But are they actually good at generating code that makes sense for your organization?

Take impact analysis as an example. When you give an agent a prompt to make a change to a dbt model because you've added a new schema upstream, how do you ensure the agent understands the downstream consequences of that change? It needs to know: if I make a change to this model, I'm affecting five tables that depend on it - and those five tables are being used by fifteen dashboards downstream.

That's impact analysis. It's one of the most important capabilities an agent needs to operate effectively in a real data environment.

The same logic applies to migration scenarios. Whether you're moving from a legacy system, a stored procedure, or simply modernizing your stack into dbt, agents need to guarantee that the logic of the old system matches the dbt models they generate.

The agent may be good at writing code. But can it guarantee the logic stays the same? For relatively simple cases, probably. For complex ones with many dependencies, probably not. That's the gap we're working to close.

The same pattern applies when you look across your dbt models at scale. If you have hundreds or thousands of models - and some teams have tens of thousands - you will have redundant logic. That redundancy drives complexity and cost. The tools we're building help you understand where that duplication exists and address it proactively, not just reactively.

Operationalizing is where the real work is

Once you've built a data product, deploying it into production and keeping it running is where a lot of your time and cost actually go. Operationalizing your data is one of the hardest things you do.

One of the most critical metrics here is mean time to resolution. When a dbt pipeline fails, for whatever reason, the goal is to troubleshoot it as fast as possible and get back into production. Agents can help dramatically - but only if they have the context to diagnose what actually went wrong.

Schema evolution is another persistent pain point. A source schema changes and breaks things downstream. The challenge isn't just detecting schema evolution automatically - it's ensuring the agent has the context to understand exactly what changed, and then make the right fixes across your dbt directed acyclic graph (DAG) so that the end dashboard isn't affected.

Cost optimization follows the same pattern. Most of us have at least one dbt model that's large, slow, and expensive. If you give an agent a one-shot prompt to optimize it, it can do a decent job when the model is relatively simple.

However, for complex models with many dependencies, you need the agent to have enough context to preserve the same logic while making the necessary performance and cost improvements. That's where the tooling matters.

Injecting dbt context into any AI tool

As your data architecture evolves and you adopt more AI tools, the goal should be a consistent layer of context that works regardless of which data platform you run on or which AI client you use. Whether your teams are using Claude, ChatGPT, a BI tool with an embedded agent, or something you've built internally, they should be getting the same consistent, accurate answers about your data.

What will stay consistent - regardless of how the AI stack evolves - are your tables, your data logic, and the context you've built into that logic.

One of the most effective ways we've seen customers achieve this is through the dbt MCP server. The dbt MCP server takes core dbt concepts - the metadata API, the dbt CLI commands, the admin API - and exposes them to any agent as specific tools it can call.

What we're seeing with customers who use it is striking: their agents are significantly more effective at completing specific tasks. They have better context to operate with, which means lower token usage and better cost efficiency. They're faster. And the results are more accurate and more consistent, especially for natural language queries.

Bottom line: If you're using any AI tools with your dbt projects today, I'd strongly recommend checking out the dbt MCP server.

Agents across the dbt lifecycle

For dbt platform customers, we're also investing in AI-native experiences across the dbt product lifecycle in the form of dbt agents.

One example is the developer agent we're building into dbt Studio and Canvas. We want to bring the same capabilities you see in frontier coding agents like Claude Code or Cursor directly into dbt Studio. That way, you can develop and ship data products more productively without leaving your environment.

We also have the analyst agent and the catalog agent, both of which are currently in private beta. If you're already using dbt Catalog, you can ask natural language questions and get answers about your data.

The agent acts on behalf of the user, writes SQL, and uses a set of dbt tools under the hood. It's fully secured based on the role-based access control (RBAC) privileges you've granted to that user in your warehouse and within dbt.

Similarly, within dbt Catalog, you can ask questions about what data is available. This makes it a genuinely useful tool for data discovery, not just a documentation repository.

A new data analyst who joins a team and needs to understand what's been built, what's available, and how models interconnect can now get that context directly through the catalog. It spares them from digging through code or waiting for someone on the data team to walk them through it.

What production-grade agentic development actually looks like

One pattern we're seeing from teams building with agents effectively is that the quality of the output is directly proportional to the quality of the context you provide. This is a make-or-break difference that determines whether your projects even make it out of development.

Agents that operate without rich context - documentation, business logic, schema definitions, best practices - produce code that you'd never push to production. Agents with that context produce code that looks like it was written by your best engineer.

The teams seeing the most success are investing in codifying their standards. That means using documented best practices, defined schemas, and clear technical specs.

A big caveat: this requires having the discipline to build those artifacts before asking an agent to implement anything. The agent then follows those standards every single time. This includes writing the documentation that engineers often skip.

The combination of rich context, the dbt MCP server for data access and model validation, and structured workflows for review and deployment is what makes the difference between AI that's impressive in a demo and AI that actually ships production-grade data products.

Mammoth’s Analytics Engineering Agents

Mammoth Growth is one example of a company that successfully leveraged dbt MCP servers to operationalize AI agents.

Their attempts at AI integration before MCP always stumbled over dbt code quality because the agents were only using their baseline capabilities. This meant their code style, architecture, and accuracy were far below production standards.

Bringing on an MCP server gave their agents the context necessary to recognize common coding tasks and column names, replicate repository styles, and provide correct formatting for outputs. This meant that code generated by the agent fits within the framework of Mammoth’s projects.

Access to these agents lets Mammoth’s data teams match the speed of business, so they don’t have to compromise between keeping pace and project quality. See how they did it in this demo.

The combination of rich context, the dbt MCP server for data access and model validation, and structured workflows for review and deployment is what makes the difference between AI that's impressive in a demo and AI that actually ships production-grade data products.

What's ahead

The near-term investment at dbt is in making it easier to inject dbt context into whatever AI tools you're using. That can be through the dbt MCP server, the analyst and developer agents we're building natively into the platform, or the integrations that enable self-serve analytics for business users.

The longer-term vision is a world where agents can proactively surface issues, manage schema evolution, optimize costs, and respond to incidents. Ideally, they’ll do this, not just when prompted, but as persistent, always-on participants in your analytics workflow.

We're early in that journey. But the foundation is being built now, and the teams that invest in getting the context layer right today will be the ones best positioned to take advantage of it.

If you want to explore this further - the agents beta, a demo of the dbt platform, or just a conversation about how to get started - reach out to the dbt team.