Building the agentic data stack: A practical dbt guide for the AI era

The AI readiness gap is bigger than it looks

Ali Ghodsi said earlier this year that over 80% of databases on Databricks' platform are now built by AI agents. AI-driven data engineering has arrived.

The headline left out the harder truth. Most of those databases run on foundations built for human-operated workflows, not for agents. Only 7% of enterprises say their data is completely ready for AI, according to the 2026 Data Readiness Index from Cloudera and Harvard Business Review Analytic Services. The tests, contracts, semantic definitions, and lineage that make AI-generated data trustworthy are still the exception.

Both facts describe the same gap. AI builds fast, and without a governed foundation underneath it, fast can also mean unreliable. Accuracy is where it shows: agents that look strong in a pilot slip the moment they meet real users and real edge cases.

This gap is exactly what the June 1 launches set out to close. Fivetran and dbt Labs are one company now, focused on open data infrastructure for trusted agents. dbt State, dbt Wizard, and dbt Core v2.0 all point at the same goal: a data foundation that's open, portable, and ready for what agents need.

That leaves you with one practical question. What does your dbt project need to support AI agents safely? Four things, working together.

Trust foundation: tests and contracts

Start here. Model contracts enforce schema constraints at the model level, so breaking changes get caught before they reach production. Data tests validate the data itself.

For AI-generated models, both matter more. An agent does not know which downstream model breaks when a column type changes. Contracts and tests catch what the agent never thought to check.

Query reliability: the dbt Semantic Layer

Without a semantic layer, agents write raw SQL against undecorated tables, and accuracy drops sharply. In an early dbt experiment, LLMs answered natural language questions correctly about 83% of the time when grounded in governed MetricFlow definitions, far above the accuracy of raw text-to-SQL on real-world schemas.

The dbt Semantic Layer turns a natural language question into a consistent, defensible answer. Without it, your agent guesses what your metrics mean, and it guesses with confidence.

The agent built for the work: dbt Wizard

General coding agents write plausible code, then hand you an hour of verification because they do not know your project. dbt Wizard is built for the way analytics engineers actually work: investigating, building, validating, and shipping.

It is grounded in your dbt project, so it knows your lineage, contracts, tests, and metric definitions before it writes a line. It knows which tool to call, validates its own work, and shows you what changed and why. You get it inside the dbt platform and as a terminal-native CLI, whether your team runs on the dbt platform or self-hosted. Under the hood, dbt Wizard draws on dbt Agent Skills, the open-source skills maintained by dbt Labs and the dbt community.

Efficiency at AI speed: dbt State

Point an agent at your pipelines and it will run them at machine speed. Rebuild everything on every run and your compute bill climbs fast. dbt State checks your metadata and model SQL on each run, builds what's changed, and skips what hasn't, for an average of 30% reduction in warehouse compute. It runs in the dbt platform and in the orchestrator you already use.

Build what's changed, skip what hasn't. For agentic workflows, that is the difference between automation that scales and a compute bill that punishes you for using it.

Audit your own project

Before you invest in new tooling, run this audit on the project you have. Each question maps to one of the four pillars.

Trust (contracts and tests)

• Are model contracts enforced on your most important models? If your revenue and customer models have no contract, an AI-generated change upstream can break them quietly.
• Do your critical models have data tests, and do breaking changes fail in CI? If a schema change passes CI without failing, your governance is misconfigured.

Query reliability (Semantic Layer)

• Are your MetricFlow metrics defined in the project? If your core metrics live only in a BI tool, agents cannot query them in a governed way.
• Can an external system reach your semantic layer through the dbt MCP server? If not, natural language queries are hitting raw tables.

The agent (dbt Wizard)

• Is your team using a dbt-native agent like dbt Wizard, or general coding agents that do not understand your project? Generic agents do not respect your contracts or see what breaks three models downstream.
• Do agents reach your project through a governed, auditable interface, dbt Wizard or the dbt MCP server, rather than raw warehouse credentials?

Efficiency (dbt State)

• Does every run rebuild everything, including models that have not changed? dbt State skips the work that hasn't changed.
• Before you connect agents that trigger runs, do you have cost controls in place? Machine speed and a per-query bill are a costly surprise to discover later.

What an agentic dbt workflow looks like in practice

A prompt or an automated trigger starts a task: write a new model, optimize an existing one, generate documentation. dbt Wizard reads the lineage graph, works out what the affected models do, and drafts the change, validating its own work against your contracts and tests before you see a diff. The PR runs through CI with contract checks. If it breaks a downstream contract, CI fails, and the agent either fixes the issue or routes it to a human. When the pipeline runs, dbt State builds only what changed, so the run stays cheap. Merged work feeds updated MetricFlow metrics and documentation. The next time an analyst asks a question in plain language, the semantic layer answers from the new model and cites its lineage.

Every step depends on at least one pillar. Remove one and the workflow breaks in a predictable place.

Common failure modes in agentic dbt workflows

Teams that build agentic workflows without these foundations hit the same failure modes repeatedly.

AI-generated models with no tests. The model runs. The numbers look plausible. Three months later a column gets renamed upstream, the model starts returning nulls, and nobody notices until finance flags a wrong number. Data tests catch this. Untested AI-generated models are technical debt at AI speed.

Plain-language queries against raw tables. An agent queries a table called orders. It cannot tell placed orders from fulfilled or cancelled ones, so it guesses, and the answer is wrong. A governed semantic layer removes the entire category of failure.

Agents with direct warehouse access. An agent holding database credentials is a liability. dbt Wizard and the dbt MCP server give agents scoped, auditable, governed access to your project. Use them.

Rebuilding everything on every run. Connect an agent that triggers pipelines and your compute bill climbs while you are looking elsewhere. dbt State pays only for new work.

Treating AI-generated documentation as final. AI-generated documentation is fast and usually close, and it is not authoritative. Build a human review step into your workflow before AI-generated descriptions publish.

Build trust before you build automation

Sequence matters. Contracts and tests first, the trust foundation. Then the semantic layer, for query reliability. Then the agent and the cost controls, dbt Wizard and dbt State. Teams that skip the foundation and jump straight to agents automate on ground they cannot trust, and all that earns them is faster data debt.

The companies reaching production-grade agentic data workflows are the ones that build the right infrastructure before they connect AI to it.