If you work on a modern data team, you have almost certainly encountered dbt by dbt Labs. Short for "data build tool," dbt has become the standard for transforming raw data into clean, analysis-ready datasets inside your warehouse. You write transformations as SQL SELECT statements, and dbt brings software-engineering discipline to your analytics code: version control, modularity, testing, documentation, and CI/CD. In practice, dbt is where an organization defines what its data means, including its metrics, lineage, tests, and governance.
That structured context is what makes dbt's newest capability worth a closer look. At the dbt Labs 2025 conference, they introduced dbt Agents, a suite of native AI agents that turn a dbt project's context into auditable, governed actions across the analytics lifecycle. People tend to use agent, chatbot, and coding assistant interchangeably, but the difference is exactly what makes dbt Agents worth your attention. A chatbot or general coding assistant is reactive: you prompt it, it answers. An agent is proactive: it takes a goal, plans the steps, uses tools to carry them out, and checks its own work before delivering a result.
A general chatbot or coding assistant:
- Is a general-purpose tool, not honed on the specific task you're working on. Its knowledge comes from training that may lag behind current best practices, so its suggestions don't always apply them.
- Lives outside your project, so you have to break out of your workflow to gather context and copy-paste it back and forth.
- Has no inherent view of your data, so it guesses metric definitions and can produce code that looks right but isn't.
- Leaves the security and privacy of your data for you to configure externally.
dbt Agents:
- Are tuned and augmented with best practices specific to the task at hand — in this case, building quality data pipelines — and apply them on the fly, so the models they build hold up to real quality standards.
- Are embedded in the platform, so they can make changes directly, you can track the diffs, and they'll even help draft your commit messages.
- Work from your own data and context, grounded in your semantic layer, metadata, and governance policies, which makes their output traceable and far more reliable.
- Evaluate outputs as they go, catching and solving complex problems even when you didn't explicitly ask.
In short, dbt Agents bring the expert knowledge and expertise of an analytics engineer to your project. A general assistant can connect to dbt, but without the same context, repo access, or embedding, it takes more back-and-forth to get to the same place.
At least, that's the promise, and we wanted to see how it holds up. So, we spent time with the agents hands-on across the modeling lifecycle: designing data models and transformations, writing supporting documentation, defining standards in code and enforcing them automatically, and validating the quality of outputs while keeping humans in the loop where trust matters. Here's what we found.
The Four Agents We Set Out to Evaluate
When we began this evaluation, dbt Labs had a vision for four agents that were introduced during their conference in 2025, and each pointed at a different stage of the analytics development lifecycle:
- Analyst Agent: This agent is aimed at business users; ask a question of governed data in plain English and get an answer back. It generates SQL from your models, resolves dbt Semantic Layer metrics wherever they're defined, runs the query, and returns governed results.
- Developer Agent: This agent is the one for building models. It describes, builds, and validates models against your warehouse, compiling and building each change before you review it.
- Discovery Agent: This agent answers "which dataset should I trust?" It helps you find the right approved dataset and surfaces its definitions, freshness, tests, owners, and lineage to help you make the best decisions.
- Observability Agent: This agent targets the run side of the lifecycle: continuous pipeline monitoring, root-cause surfacing, and guided fixes, with the goal of faster resolution, higher reliability, and fewer tickets stuck in the queue.
Two of the four were usable when we tested: the Analyst agent and the Developer agent. Discovery was in beta and Observability hadn't shipped, so our hands-on findings center on the two agents we could run. Please note our findings were accurate at the time of publishing, but the dbt agents’ landscape is evolving rapidly.
dbt Wizard: What the Developer Agent has Evolved into
The agent we started evaluating as the Developer agent is now delivered as dbt Wizard, which dbt calls "the new and recommended AI agent for governed data development." This, however, isn't just a simple rename. Wizard is a broader, more capable tool, and the differences between the two are the clearest signal of how much dbt is focusing on making agents a core part of the developer’s experience. Three main changes stand out.
First, dbt Wizard covers a larger portion of the lifecycle. While the Developer agent focused on individual, isolated tasks inside the IDE — creating a model, adding tests, writing documentation — Wizard approaches a task holistically. It investigates the issue that was raised, plans an end-to-end solution, and implements it iteratively, validating its own work along the way. One agent carries a change from investigation through building, validation, and shipping, rather than offering help on a single step.
Second, it runs in more places. The Developer agent lived solely in the dbt Studio IDE. Wizard runs in the Studio IDE, in a dedicated workspace on the dbt platform, and as a terminal-native CLI you can point at a local Fusion or dbt Core project. That last point is particularly powerful: it brings the governed agent to analytics engineers working locally, not just to people in the dbt Platform UI.
Third, it behaves like an agent, not an autocomplete. Wizard plans and executes multi-step work, and can spin up focused subagents to explore, change, and review in parallel. It also comes pre-baked with dbt's own Agent Skills — state-of-the-art analytics engineering knowledge, both conceptual and technical, recommended by dbt themselves. So, the guidance you're working with reflects how the people who built dbt operate.
Where dbt Agents Are Strong
dbt’s agents are purpose-built for analytics engineering; not general coding assistants pointed at a dbt project. Wizard handles semantic-layer development, unit-test generation, debugging, migrations, and running dbt commands, and it reads a project the way an analytics engineer would.
That awareness runs deep. Wizard works from a pre-built index of the whole project: lineage, model health, tests, contracts, run results, and semantic definitions. It starts each task already knowing how the project fits together.
Think of dbt Wizard as working from a map of the city. It knows how everything connects before it starts, instead of reading every file to reconstruct context each time. That changes the end-to-end experience of making a change. Here's what the loop actually looks like:
You describe what you want. Wizard lays out a plan, then makes the edits to your models. Before it shows you anything, it validates its own work against your live project: it confirms downstream refs still resolve, compiles the change, and builds it to a development schema against the warehouse. If something fails, it explains the problem, adjusts, and retries on its own; you don't see a diff until the change has actually passed. This validation runs automatically; it isn't a mode you switch on.
What you get back is a set of interactive diffs, with added and removed lines marked, plus a summary of what changed and the evidence that it runs. You review it and decide to accept the changes or reject them. Because Wizard edits your working files rather than committing for you, nothing reaches Git until you take that step yourself — so even after accepting, you can keep reviewing, make further edits, or discard the work entirely before it's ever committed.
You also control how much latitude Wizard has up front. An "Ask for approval" mode has it pause before running commands or editing files, for more cautious work; "Edit files automatically" gives it room to move on a task you trust. Even in the more autonomous setting, it won't run destructive commands, a full refresh, a hard reset, without explicit approval.
The practical payoff across all of this is impact awareness: because Wizard checks the blast radius before it writes, you see what a change will affect up front, rather than discovering it when a run breaks.
Agent Skills, MCP and Making the Agent Your Own
Generalist AI struggles in specialized settings. Every team has its own vocabulary, constraints, quality bar, and modeling patterns, and a general model has a hard time learning those skills. Agent Skills are how you close that gap. A skill packages domain knowledge into a repeatable, testable workflow, so the agent works to your standards and produces output that fits your delivery and governance process.
A custom skill is a SKILL.md file in your project with a name, description, and markdown instructions. The Wizard loads it automatically when its description matches the task, or you can also configure to call it up directly. For standing context, it reads project instruction files like AGENTS.md and CLAUDE.md out of the box, and an @-mention lets you scope a change to a single model, so the agent touches only what you intend. Agent Skills customize how an agent behaves.
The most strategic piece is the remote dbt MCP (Model Context Protocol) server. To understand why it matters, it's important to distinguish between dbt Wizard's native access to your project and the remote MCP server that exposes governed context to external agents. dbt Wizard, dbt's own agent, already has privileged native access to your project — a built-in metadata engine covering lineage, tests, contracts, and semantic definitions, with no MCP setup required. The MCP server is how you extend a governed slice of that same context to external agents: it exposes your dbt project's models, metrics, tests, and lineage through one secure endpoint per environment, reachable by any MCP-compatible client such as Claude, Cursor, or VS Code. The remote dbt MCP server determines what trusted context an agent can access.
That distinction reframes from the build-or-adopt question for teams already running a coding agent. It stops being "Wizard or our agent" and becomes "Wizard and our agent, grounded in the same dbt context." Your existing agent gets trustworthy, governed answers about your data through the MCP, while Wizard — with its deeper native access — does the dbt-native lifecycle work. It's also a reason to reach for Wizard where you can: it isn't consuming a context layer bolted on from outside; it's built on the fullest version of that context from the inside. dbt is positioning itself as the governed context layer other agents run on, and that's a strong place to be.
Things That Could've Been Better
No new product is without rough edges and naming them fairly is part of an honest evaluation. A few stood out.
Discoverability and Navigation: The agents are spread across different locations on the UI, which makes them hard to find on first use. Wizard itself is now easy to reach, with its own sidebar entry, a standalone tab, and a CLI. But the rest of the suite still takes some hunting, and a new user has to learn where each agent lives.
Naming and scope: The "Copilot" label covers more than one experience. In dbt Insights you can reach the Analyst agent through a panel branded Copilot, but the older Copilot experience can also be found in the Catalog. So even with the Wizard enabled, you can encounter "Copilot" in two places doing two different jobs, neither of which is the Wizard. It is easy to ask the wrong agent the right question.
Gating and Security: These features exist but are still early. The agent reliably checks before it acts, which is solid gating, but it's approval-based rather than policy-based. We found no native way to set rules by environment or asset tier, so you can't yet warn on one and block on another. Authentication is the stronger part: the Wizard CLI is bring-your-own-key for the model provider, and both the local and remote MCP servers support OAuth login, with access tokens as the alternative.
As we mentioned earlier, agents within dbt are rapidly evolving, and we’re confident these niggles will be ironed out in the near future.
How Fast This Is Changing
The pace at which dbt has been iterating on and deploying these features over the past 12 months is breathtaking. dbt announced four agents in October 2025. Within about seven months, the developer-side agent had been rebuilt and rebranded, given a standalone CLI, and is the recommended path for governed development.
For a team choosing tools, that cuts both ways. The capabilities are real and improving quickly, but the labels, UI, and recommended entry points are still settling. An evaluation written on a recent release will likely be dated within a release or two, which is why we anchor our assessment on what the agents do and how they're governed, since that outlasts the names and labels attached to them. That said, we are very thrilled about how quickly the changes are coming and we’re very optimistic about the future of agents in dbt.
What We Expect Next
We read the current state as a dynamic, rapidly evolving scene rather than a fully settled one. But we are expecting it to mature along a few predictable fronts. Discovery and Observability should graduate from beta and roadmap into agents that teams can actually run as part of their daily workflows. Wizard should harden toward general availability, with the local CLI closing the gap to the dbt platform CLI. And the naming should settle as dbt consolidates its AI offerings around fewer entry points.
When it does, the four-stage lifecycle dbt Labs sketched out at their conference in 2025— analyze, build, discover, observe — really starts to come fully to life. We’re excited to continue testing these features as they land, and we’re looking forward to the fully built-out agent ecosystem in dbt.
Who are we at Aimpoint Digital
As a dbt Labs partner, Aimpoint Digital helps data teams turn well-governed dbt projects into production-grade analytics. If your team is weighing how dbt Agents and dbt Wizard fit into your stack, or how to ground the coding agents you already use in a governed dbt context, we would be glad to help.
.png)