Taipei dbt Meetup: Trustworthy AI Agents Depend on Data Infrastructure

Talk by Toshitaka Ito, Staff Solutions Architect at dbt Labs, barely three weeks after the Fivetran + dbt Labs merger closed (June 2026, ~$600M combined ARR). The topic: 可信賴的 AI Agent 取決於資料基礎架構 — trustworthy AI agents depend on data infrastructure.

The core problem

The comparison that structures the whole talk:

人類能夠補足缺失的脈絡，但 Agent 只會放大這些缺失 — humans compensate for missing context; agents only amplify those gaps.

That’s where the “star” layer of the combined architecture comes from: Governed Context — lineage, a semantic layer (“revenue” means the same thing to every agent), and metadata. Without that layer, putting agents on top of your data just accelerates how fast errors propagate.

Fusion engine: compile locally, run remotely

Of June’s three announcements (dbt Core v2.0, dbt State, dbt Wizard), the most significant is the Fusion engine, rewritten in Rust. The paradigm shift: before, every error required a round-trip to the warehouse; now the query gets compiled and validated locally (with DuckDB underneath) and only touches the warehouse once it’s valid.

I saw it in the demo: dbt run processed 31 models in 2.3 seconds — impossible if every query had to hit Snowflake. It even caught a configuration error locally (MERGE strategy requires unique_key) without touching the warehouse. As a Java developer, the analogy is direct: it’s the move from “compiling in production” to IntelliJ’s compiler + LSP — immediate feedback.

dbt State: don’t rebuild what didn’t change

dbt State detects which models changed and only rebuilds what’s affected — dbt Labs reports a ~30% reduction in compute costs. In the demo: the first run built 32 models; the second, with no changes, built only 2 (30 reused).

The Deferral strategy struck me as the killer feature for development: your DEV environment can be completely empty, and upstream models are referenced directly from PROD. In the demo, after a full DROP CASCADE, it built the modified model in 17 seconds using PROD as the upstream. Clone is the isolated variant: upstream copied into DEV with zero-copy clones (pointers, not real copies).

dbt Wizard: promising, but beta is beta

The agent specialized in analytics engineering, connected via MCP to the local dbt_index — instead of sending the whole schema in the prompt, it queries only what’s needed (“zero token waste”). In the demo… it failed: MCP client for dbt_index failed to start, a corrupted Fusion index. The system suggested “ask the wizard” — but the wizard was the thing that was broken. 😄

The architecture, to its credit, is the same pattern as Claude Code: a CLI the extension launches as a background process, speaking MCP with a local context server.

From the Q&A

I asked him (among other things) for the best way to use dbt from a code agent: his recommendation is dbt Wizard if you’re already on the platform, or dbt-agent-skills + the dbt MCP server if you live in Cursor/Claude Code — viable, but more DIY.

Two more answers worth keeping:

• Semantic Layer instead of text-to-SQL? Yes, but as the first line of defense with a fallback to text-to-SQL: the semantic layer has high precision within its coverage, and when it can’t answer, it errors out instead of making something up. The real bottleneck isn’t the model’s capability — it’s whether the data is organized so the agent can use it safely.
• Does the analytics engineer disappear? The role shifts toward defining context, tests, metadata, and governance. And even if each team gets smaller, total demand can grow — the classic Jevons paradox argument applied to development: when an activity becomes more efficient, its total use tends to increase.

His best practices for agent coding wrap it up nicely: small tasks, compile/build/test after every change, and always review the diff — both the code and the data. Don’t blindly trust the agent’s output.