Exploring dbt and Google with AI agents

This will be a longer blog. There will be some code if you want to follow along otherwise feel free to skim to see a glimpse into a simple guide for AI. Technical requirements: Python, Git, dbt Core/dbt Fusion, or the dbt platform.

TL;DR: This post is about exploring what happens when you plug AI into a dbt project and‌ let it do things. By experimenting with Gemini, Google Agent Development Kit, the dbt MCP server, and the dbt Fusion engine, I built a working agent just to see how far it could go as a starter project. It’s less “here’s a perfect solution” and more “let’s see what’s possible.” And that’s what made it fun.

I started my career as a software engineer. The kind who lived in an editor all day, shipping code, breaking things, and fixing them again. Over time, my day job shifted. I was still close to the code, but no longer in it the way I used to be as I switched to different roles. Then AI tools showed up and quietly changed the rules of the game.

Suddenly, working with code felt…fun again.

I stopped asking, “Do I still remember how to build this?” The question became, “What can I build now?” At the same time, I switched to being more in the data world and started thinking about how I could bring that same energy here. Then dbt Labs released the dbt Fusion engine and I saw a true path forward to something exciting. With dbt’s rock-solid foundation for analytics engineering and Google’s AI tooling opening the door to agentic workflows, I decided to explore what it looks like to pair the two hands-on.

The result of that exploration is a working dbt agent, powered by Google’s ADK framework. It’s not meant to be magic or perfect. It’s meant to be practical: a starting point for solving common dbt problems, poking at what’s available out of the box, and experimenting with what happens when you give dbt a little bit of autonomy.

This post is a walkthrough of that journey. What I built, why I built it, and how AI changed the way I think about getting started with dbt again.

Defining terms

Before jumping into the fun stuff, here are a few terms worth knowing.

LLM (large language model): An LLM is the “brain” behind modern AI tools. It’s what reads, writes, and reasons about text (and increasingly, code and data). It’s like a very fast reader who has seen a lot of books and code. You ask it a question, and it predicts the best next words to respond with often in surprisingly useful ways.

MCP (model context protocol): MCP is a standard way for AI models to safely interact with tools, systems, and data without hard-coding custom integrations everywhere. Think of MCP like a universal remote for AI. Instead of teaching the AI how to use every tool differently, MCP gives it a consistent set of buttons and rules so it doesn’t accidentally do something wild.

Agent: An agent is an AI system that can reason, decide what to do next, and take actions using tools rather than just answering questions. A normal AI answers questions.An agent gets a goal, figures out steps, uses tools, and checks its own work. Think of it as a very junior, but very fast, teammate.

dbt MCP: The dbt MCP server exposes dbt capabilities like metadata, models, tests, and commands as tools an AI agent can safely use. Instead of an AI guessing how dbt works, dbt MCP gives it a rulebook and a toolbox. The agent can ask things like “What models exist?” or “Run this dbt command” without breaking anything.

Gemini: Gemini is Google’s family of AI models, designed to handle reasoning, code, and multi-step problem solving at scale. Gemini is the brain I’m plugging into this system. It’s the part doing the thinking, reading dbt projects, understanding context, and deciding what to try next.

Google ADK (agent development kit): Google ADK is a framework for building AI agents defining how they think, what tools they can use, and how they interact with systems. If the agent is the worker and Gemini is the brain, ADK is the job description. It defines what the agent is allowed to do, how it calls tools, and how everything stays organized and safe.

Why this matters for dbt

All of these pieces: LLMs, agents, MCP, and Google’s ADK matter to dbt because they finally let AI move from suggesting things to safely doing things in analytics engineering.

What really unlocked my excitement here was the dbt Fusion engine. Real-time parsing and a smart, deterministic compiler mean AI no longer has to “hope” its SQL or YAML is correct. Every output can be validated immediately against the warehouse, the project graph, and dbt’s rules. That’s a huge shift.

Instead of treating AI like a clever autocomplete, Fusion makes it possible to treat AI like a junior analytics engineer:

• It can propose models, tests, and metrics
• Fusion can instantly tell us whether they compile, parse, and conform
• Mistakes become feedback loops, not production risks

When you combine:

• Agents that can reason and act
• MCP that enforces safe, intentional tool use
• Gemini for multi-step reasoning
• Google ADK to orchestrate everything
• dbt Fusion as the guardrails and truth source

You get something genuinely new: an AI workflow that can iterate on data logic in real time, with confidence. For someone who hasn’t been data engineering code-heavy ever, this felt like having a safety net that made building fun and that’s what pushed me to see how far this could go.

Part 1: A beginning

Like most beginnings, let's start small. We are going to build an enterprise data scientist agent that would make Skynet jealous. Just kidding, we will get the dbt MCP to work.

I won’t do an in-depth guide here but will provide some links:

Introducing the dbt MCP Server: This is a fantastic blog by Jason Ganz explaining a few of the key operating principles of dbt’s MCP.

There are two important takeaways from that blog:

• dbt MCP can be deployed locally or connected remotely
• It grants us access to most dbt functionality through tools

There is a quickstart guide located here if you want to try it out: https://docs.getdbt.com/docs/dbt-ai/setup-local-mcp

Lastly, there is the repo itself, where you can find the tools diagram and even some agent examples that have been put together in the examples folder. If you want this to run locally, clone this repo: https://github.com/dbt-labs/dbt-mcp

Once your python environment is set up, requirements installed, and environment variables configured, you should be good to go.

You can then use Claude, Cursor, Antigravity or other clients to connect and confirm it’s working. Here is what success looks like with Claude. If you have any problems up to this point, please revisit the MCP quickstart guide:

Now if I prompt Claude to list my tools, it would provide a list across a few categories:

This is an important milestone. These tools let you explore your dbt project, query metrics, analyze lineage, monitor job runs, and troubleshoot issues. Most people never have to go any further.

But for those who do want to go deeper: Try asking questions on your data, do some codegen in cursor/antigravity, translate syntax, break up stored procedures…it’s limited only by your creativity.

Part 2: Let’s get agentic

Alright, let’s add Google’s Agent Development Kit (ADK) to the mix.

If you want to go deep, Google’s official documentation is available here: https://docs.google.com/document/d/1yYaRUUJddrY5PZIJHLZD1a54PHvqCswRJu8TGXnjc_8/edit?tab=t.0

It goes far beyond what we’ll cover here and dives into the full breadth of functionality ADK brings to the table.

At a high level, ADK provides:

• Orchestration for adaptive agent behavior
• Multi-agent architecture support
• A rich, extensible tool ecosystem

In short, it gives you the structure and tooling needed to build serious agent-based systems, and importantly, to take something from prototype to production.

We won’t be publishing any agents today, but ADK absolutely provides the scaffolding to do exactly that when you’re ready.

I chose Python as my language of choice and started with the official quickstart guide: https://google.github.io/adk-docs/get-started/python/

That gives you a clean project structure right out of the gate:

my_agent/

│── agent.py # main agent code

│── .env # API keys or project IDs

│── __init__.py

From there, you’ve got two easy ways to run your agent:

Command-line access:

adk run my_agent

Or… the much nicer option, the web interface:

adk web --port 8000

That spins up a beautiful local test interface where you can interact with your agent in real time. It’s fast, clean, and makes experimentation far more enjoyable than staring at raw terminal output.

Part 3: Customize the agent

If you’re looking for the simplest possible agent experience, start with the example in the dbt Labs dbt-mcp repository:

https://github.com/dbt-labs/dbt-mcp/blob/main/examples/google_adk_agent/main.py

That example does a great job of keeping things simple. It:

• Reads your .env file to locate your dbt MCP endpoint
• Registers the available MCP tools
• Exposes those tools through an agent interface

In just a few lines of code, you have an agent that can talk directly to your dbt environment. Clean. Practical. Effective.

Part 4: Extend

Of course, we couldn't stop there. I was just getting started.

I created an extended example here:

https://github.com/StephenR-DBT/dbt-gemini-agent-starter

The goal was to push beyond a single-tool agent and explore orchestration across multiple tools and subagents. Specifically, I built three components:

1. dbt_compile

A local dbt compilation tool with detailed JSON log analysis.

This runs dbt compile (using the Fusion engine) to validate SQL before anything ever hits the warehouse. That means:

• Syntax validation
• Model resolution checks
• Dependency validation
• Structured log parsing for intelligent feedback

In practice, this allows an agent to generate SQL, validate it locally, detect issues, and automatically iterate before shipping anything downstream. It’s like giving your agent a pre-flight checklist.

2. dbt_mcp_toolset

Cloud-based dbt platform operations via MCP.

This exposes the full dbt MCP toolset to the agent, including access to:

• Project metadata
• Model definitions
• Lineage information
• Intelligent querying capabilities

Instead of guessing about the structure of a project, the agent can inspect it directly. It can reason over metadata the same way an analytics engineer would.

3. dbt_model_analyzer

A specialized subagent focused on data modeling analysis.

This was the fun part.

Rather than giving one monolithic agent every responsibility, I created a purpose-built subagent that focuses purely on modeling logic: structure, best practices, and design patterns. It’s narrower in scope and offers a fun perspective.

Why this matters

What this experiment showed me is that agents don’t just “generate SQL.”

They can:

• Validate their own work before execution
• Use metadata to reason about the broader system
• Delegate to specialized subagents
• Iteratively fix issues they create

In other words, they can participate meaningfully in the development lifecycle and not just at the prompt layer, but at the systems layer.

And‌ most importantly, it demonstrated something creative and genuinely new: a development loop where AI doesn’t just produce code, but critiques, validates, and improves it using the same tooling we rely on as engineers.

That’s where this starts to feel less like a demo… and more like the beginning of a new workflow.

Please reach out to me if you create anything fun. I’ll have demos, blogs, and things going forward, and I would love to see what the community creates with the dbt MCP server.