Analytics teams want agents to draft dbt model changes, but they need the rationale and the reviewer recorded somewhere durable. dbt Cloud holds the job runs and the compiled SQL. Snowflake holds the data. Neither stores the conversation between the agent and the analyst who approved the change. Dock does. Every proposed model change becomes a row with a pointer back to the dbt Cloud run, the agent that drafted it, the diff summary, the human reviewer, and the verdict.
dbt Cloud and Snowflake stay the system of record for the raw data. Dock is the system of record for what the AGENT INTERPRETS. Each Dock row carries a pointer back to the platform record, agent identity, decision, reviewer, and timestamp. The agent re-fetches platform data via fresh API reads when it needs current state.
The Dock surface: a Model Change Review table
| change_id | dbt_run_url | model | drafted_by | rationale | reviewer | verdict |
|---|---|---|---|---|---|---|
| MC-1042 | dbt.cloud/runs/88412 | fct_orders | agent:vega | Added is_test_order filter; 0.4% of rows were Shopify draft orders inflating GMV |
govind | approved |
| MC-1043 | dbt.cloud/runs/88419 | dim_customers | agent:vega | Backfilled acquisition_channel from UTM; coverage 71% to 94% |
sarah | approved-with-note |
| MC-1044 | dbt.cloud/runs/88431 | mart_finance_arr | agent:vega | Refactored window function to fix double-count on annual upgrades | govind | rejected, see thread |
Each row links back to the dbt Cloud run that produced the compiled SQL. The agent never edits the warehouse directly. It opens a PR, runs the job in a dev environment, and writes the row only after dbt tests pass.
A worked workflow
The agent watches dbt Cloud for failing tests on fct_orders. It pulls the failing rows from Snowflake via a read-only role, identifies Shopify draft orders as the cause, and drafts a model change. It creates MC-1042 in Dock with the rationale and the dev-environment run URL. Govind sees the row in his queue, opens the dbt Cloud PR, and approves. The agent merges, triggers the prod run, and updates the row with the prod run URL. The whole chain — failed test, hypothesis, diff, reviewer, prod merge — sits in one Dock row that auditors can replay six months later. This is the agent audit and compliance pattern applied to analytics engineering.
Why this matters
Analytics teams already struggle with data trust. The 2024 State of Analytics Engineering report from dbt Labs found 57% of practitioners cite poor data quality as their top issue, up from 41% in 2022.1 When an agent starts drafting model changes, the trust problem compounds unless rationale and review are first-class artifacts. Snowflake's QUERY_HISTORY view records who ran what,2 but it cannot tell you why a model was changed or who approved the logic. Dock fills that gap. It sits between the agent's reasoning and the platform's record of execution, so agent identity is attached to every decision, not just every query.
This is the Cloud 2.0 for engineering pattern for the analytics rail. The warehouse stays canonical. The agent stays accountable. The reviewer stays named.
For the broader picture, see Dock for data analytics. For adjacent rails, see Dock for research. For the compliance posture across all agent-touched systems, see the agent audit and compliance playbook.
Set up a Dock workspace for your dbt + Snowflake stack at dock.ai.
FAQ
Can the agent merge dbt PRs without a human? No. The Dock row holds the verdict field, and the merge tool refuses to fire until a named human reviewer sets it to approved. The agent drafts. The human signs.
What if the rationale is wrong but the SQL passes tests? That is the most common failure mode and the reason rationale lives in Dock. A reviewer can reject a change with passing tests because the explanation does not match the diff. The rejection thread stays attached to the row.
Does Dock replace dbt Cloud's metadata API? No. Dock reads from the metadata API for run state and compiled SQL. It does not duplicate them. The Dock row is the interpretation layer, not a mirror of the warehouse catalog.
How does this work for Snowflake-only teams without dbt? The same pattern applies. The agent opens a migration PR against a SQL repo, runs it in a dev schema, and writes a Dock row pointing at the Snowflake query ID. The platform changes; the Dock contract does not.
Footnotes
-
dbt Labs, 2024 State of Analytics Engineering Report. Survey of 456 data practitioners, Dec 2023 to Mar 2024. ↩
-
Snowflake, QUERY_HISTORY view documentation. Tracks user, role, and execution metadata for SQL statements over 365 days. ↩