Your Company Standardized on Fivetran and dbt. Now Let Data Workers Own Whether the Data Is Right: A Guide for Data Leaders

Fivetran moves the data in and dbt builds on it. Data Workers owns whether what landed and what was built is right: it diagnoses what a successful sync changed downstream, proposes the fix to its owner as a diff and verifies the number afterwards. Syncs stay with your team. This guide is for the CDO or VP of data whose company is standardizing on the merged Fivetran + dbt Labs stack.

Since June 1, 2026, Fivetran and dbt Labs have operated as one company, Fivetran + dbt Labs, so one vendor now sells most of the path your numbers take. Fivetran connections replicate SaaS apps, databases and SAP from more than 900 sources and destinations into Snowflake, BigQuery or Databricks, with HVR for high-volume replication and the Managed Data Lake Service for Iceberg and Delta. Fivetran Transformations, which schedules pre-built data models and Fivetran-hosted dbt runs, is still listed as its own Fivetran product. dbt turns the raw tables into models, now on dbt v2, generally available since September 16. SQLMesh came with the Tobiko Data acquisition in 2025 and is now a Linux Foundation project. Census ships inside Fivetran as Activations, sending warehouse data out to the CRM and ad platforms.

Then the estate grows to three hundred connections, eight hundred models and a dozen Activations syncs. Every sync reports success, because Fivetran is built to keep data flowing when a source changes shape. A retyped column is promoted to a type that holds old and new values; on many database connectors, a renamed column arrives as a new one beside the old. Whether the dbt model that casts that column, the metric on top and the sync that ships it to the CRM are still right is a question no tool answers by default.

Your team has become the glue between one vendor's products and every system around them. The expensive part is operating what lands: the triage, the fixing, the checking and the record of what changed.

What the Fivetran + dbt stack solved, and what it didn't

The stack solved movement and building. Fivetran turned extraction code into configuration, with schema change handling set per connection (Allow all, Allow columns or Block all) and a log of every alter_table event. dbt turned transformation into reviewed code with tests and contracts, and Fivetran now stewards GX Core, the open source Great Expectations project. The AI arriving across the stack serves each product's own job. dbt Wizard, in preview, builds and refactors models inside the project with per-file approvals. The Fivetran Context Layer, announced in private beta on September 16 and now listed as a public preview in Fivetran's docs, gives AI agents data and metadata through the open Agents Schema standard and its own MCP server. The official Fivetran MCP server is read-only by default, with writes opt-in.

What the stack doesn't own is the outcome across the systems around it. A source team retypes a field, Fivetran lands it faithfully, a dbt model quietly returns a wrong number, a board metric shifts and an Activations sync writes the value into the CRM. Tracing that across five systems, getting the right owner to approve a fix, proving the number against the source and keeping a receipt an auditor can read is not a job any one of those products was built for, and rightly so: their promise is to move every row and build every model.

Fivetran moves the data and dbt builds on it. Data Workers is the agentic data platform that owns whether what landed and what was built is right, and runs the rest of your data back office.

Or, in one sentence for your team: Fivetran and dbt land and build the data; Data Workers catches what a successful sync changed, gets the fix approved by its owner and proves the number is right again.

What goes on autopilot

Each row is a queue your team works by hand today, behind signals the stack already produces: the Fivetran log, warehouse checks and the dbt manifest.

Nothing is replaced. Data Workers reads the destination schemas Fivetran lands, compares each with its baseline on the schedule you set around your syncs and classifies each change as breaking or safe. It reads the dbt project natively, so every landed column maps to the models and metrics that read it, and it connects to Fivetran and Activations over Fivetran's REST API or official MCP server today. Model fixes are proposed as diffs the owner merges. Data Workers does not trigger, pause or re-sync anything in Fivetran, by design: it proposes the step with the reason and the tables involved, and your team runs it. The wiring is in Data Workers + Fivetran.

What changes for your organization

Access and migrations follow the same pattern: the change is drafted for its owner, approved and recorded.

• •Schema drift becomes a list. Every change from overnight syncs that your team's alert on Fivetran's log hands over arrives classified, with the models, dashboards and outbound syncs it reaches, before the next dbt job builds on it.
• •Green syncs get checked. A sync that succeeds on duplicated, null-filled, stale or short data is caught on the landed table, on Snowflake and BigQuery, and handled like any other incident.
• •Outbound data gets a gate. Before an Activations sync reads a broken model, its owner sees the reach and a proposed pause, and decides.
• •The bill gets a cause. On Snowflake, Data Workers traces credits through query tags to the dbt model and run behind them, so a rebuild storm after a schema change shows up with its cause.

One quarter on a 300-connection estate

This is an illustration, not a customer case.

• •A company runs 300 Fivetran connections into Snowflake, an 800-model dbt project and twelve Activations syncs into Salesforce and Gainsight, under one new consolidated contract.
• •Over the quarter, sources change shape: retyped fields, renamed columns, an app that rebuilds a table on upgrade. Every sync succeeds. Four of those changes break a model quietly, and one reaches the CRM before anyone notices.
• •Each incident is found by a business user, traced by hand across Fivetran, Snowflake, dbt and the CRM, and patched in whichever model was closest.
• •At the quarterly review, the CFO asks which customer-facing numbers were wrong and for how long, and what happens to the operating record if one part of the stack changes. The first answer takes a week of Slack threads. Nobody has the second.

With Data Workers, each change is classified the morning it lands and traced to every model and sync it reaches, and the fix goes to its owner as a diff. At the review, the receipts answer the first question: what changed, where it reached, who approved each fix and how it was verified. The second has an answer too: the incident record, approvals and context graph live in your infrastructure and cover every system the same way, whichever vendor runs each slice.

You choose how far and how fast

You choose the altitude, one domain at a time.

L0 manual is the work your team does by hand today. Every domain starts at L1 observe: each landed change gets a classification and a blast radius, and nothing changes. At L2 propose, agents draft the model fix, the test and any re-sync or pause, and a named owner approves. At L3 act reversibly, change classes with a proven record, such as queuing the rerun of the affected dbt job after an approved fix, run on their own with the undo written down first and a receipt left behind. At L4 autonomous, a domain that has earned it runs end to end, and any domain can be dialled back. Fivetran and Activations syncs stay with your team at every level. An unanswered approval request expires and escalates, never auto-grants, and no agent can promote its own work.

More in autonomy levels L0 to L4 explained and how approvals work.

Why doesn't Fivetran just do this itself?

Focus and risk. Fivetran earns trust by never losing a row: it keeps the sync running when a source changes, promotes types losslessly and lets your team decide what new data to allow. A replication product that refused to land data whenever a downstream model might object would be a worse one. Its newer pieces keep that discipline: the Context Layer serves context, the MCP server is read-first, Wizard works inside the project and Activations sends what the warehouse holds. Owning whether a landed change broke a metric in BI or a field in the CRM means scoping its reach across systems the vendor doesn't run, getting the right owner to approve, proving the number and taking liability for changes in other people's tools. That is a different product, and the product we built.

How it fits with Fivetran and dbt

• •The stack keeps its job. Connections, schema change handling, Transformations, dbt, SQLMesh, Activations, the Context Layer and Wizard stay where they are.
• •Your team keeps the sync controls. Re-syncs, pauses, schema config, column blocking and hashing stay in Fivetran.
• •Your review stays the gate. Every model change is a diff your reviewers merge, behind your CI. Data Workers adds a blast-radius check to dbt pull requests that reaches past the project into dashboards and outbound syncs, and runs beside the Fivetran and dbt MCP servers in your engineers' coding agents.
• •Your data stays in your systems. The agents run in your infrastructure and hold the warehouse credentials, and the hosted coordination service sees workflow metadata only. Our security and deployment guide has the detail.

When you don't need Data Workers

• •Your sources rarely change shape, and when they do, the owner hears first.
• •One team owns every connection, model and outbound sync.
• •Nobody upstairs is asking which numbers were wrong last quarter or what a single-vendor stack means for your operating record.

If all three are true, keep your budget. If any isn't, read on.

The case for your CFO

The outcome. The company is consolidating ingestion, transformation and activation with one vendor. Data Workers makes that pay off where the business notices: what a successful sync changes is caught and fixed at the cause before a board metric moves or a wrong value reaches the CRM. Engineers' hours go to new sources and models instead of tracing drift.

The risk story. Autonomy is set per domain, and nothing changes at L2 until a named person approves. Data Workers never triggers or pauses a sync. Model changes go through your reviewers and CI. Every change carries a receipt: the cause, the diff, the approver, what it touched, how it was verified and how to undo it. An org-wide stop halts all autonomous dispatch. Our safety guide goes deeper, and who owns the agents covers accountability.

Why now. The merger is done, contracts are being consolidated and agents are arriving in every product of the stack. The choice is one approval flow and one record across the estate, or each product's agent plus each engineer's own wiring: see build it ourselves with Claude Code and MCP servers.

The first win. Read-only: every schema change landed by the connections behind one domain, such as finance, arrives classified with its owner and its reach into dbt, BI and Activations.

What stays the same. Fivetran, dbt, your repositories, reviewers, CI, schedules and warehouse permissions. The path is a pilot on your own connections; the ROI guide shows how to size it.

The sentence to repeat upstairs: Fivetran and dbt move and build our data; Data Workers makes sure what lands and what gets built is right, under our owners' approvals, with a receipt for every change.

Where to start

Pick one domain whose data reaches money: the connections behind billing and the board deck, or the Activations syncs your customer teams act on.

Start with a pilot. A forward-deployed engineer connects Data Workers read-only to the schemas Fivetran lands, your dbt project and the syncs downstream, and runs the first domain with your team. See pricing for how the pilot works.

For the detail, send your engineers you're on Fivetran, the practitioner version of this guide, Data Workers + Fivetran, you're on Census, you're on SQLMesh and Airbyte vs Fivetran. The dbt leaders guide and Airflow leaders guide make the same move for transformation and orchestration. They cover the four products: the Autonomous Data-Conductor runs each fix from detection to a verified result, the Data-Agents Swarm does the work, Data Context Wizard keeps one governed graph of definitions, lineage and owners across every platform, with your dbt project as a first-class source, and Spellbook Data Catalog (in preview) is where your team approves, audits and rolls back. The thinking behind them is in our thesis.

Sources

• •Fivetran, homepage ("The data foundation for AI"; "900+ sources and destinations"; Transformations, Activations, Managed Data Lake Service), checked Oct 3, 2026: https://www.fivetran.com/
• •Fivetran press, Fivetran + dbt Labs complete merger (Jun 1, 2026; initially operating as Fivetran + dbt Labs), checked Oct 3, 2026: https://www.fivetran.com/press/fivetran-dbt-labs-complete-merger-to-create-the-data-infrastructure-for-trusted-ai-agents
• •Fivetran press, dbt Summit 2026 (dbt v2 and dbt State GA; Fivetran Context Layer private beta; Sep 16, 2026), checked Oct 3, 2026: https://www.fivetran.com/press/fivetran-dbt-labs-announces-new-capabilities-to-make-enterprise-data-agent-ready-at-dbt-summit-2026
• •Fivetran Docs, Context Layer (Public Preview; Agents Schema; Agent Context MCP), checked Oct 3, 2026: https://fivetran.com/docs/context-layer
• •Fivetran press, Fivetran acquires Tobiko Data (SQLMesh; Sep 3, 2025), checked Oct 3, 2026: https://www.fivetran.com/press/fivetran-acquires-tobiko-data-to-power-the-next-generation-of-advanced-ai-ready-data-transformation
• •SQLMesh on GitHub ("a project of the Linux Foundation"), checked Oct 3, 2026: https://github.com/SQLMesh/sqlmesh
• •Fivetran press, Fivetran to become steward of GX Core (May 13, 2026), checked Oct 3, 2026: https://www.fivetran.com/press/fivetran-to-become-steward-of-the-great-expectations-open-source-community-and-gx-core-project
• •Fivetran Docs, Transformations (pre-built data models; Fivetran-hosted dbt), checked Oct 3, 2026: https://fivetran.com/docs/transformations
• •Fivetran Docs, Schema Change Handling (Allow all, Allow columns, Block all; see core concepts for lossless type promotion), checked Oct 3, 2026: https://fivetran.com/docs/core-concepts/features/data-blocking-column-hashing/config
• •Fivetran Docs, PostgreSQL connector (a renamed column lands as a new column; the old one remains), checked Oct 3, 2026: https://fivetran.com/docs/connectors/databases/postgresql
• •Fivetran Docs, log events (alter_table), checked Oct 3, 2026: https://fivetran.com/docs/logs
• •Fivetran Docs, Census migration FAQ (Activations), checked Oct 3, 2026: https://fivetran.com/docs/activations/census-migration-faq
• •Fivetran MCP server README (read-only by default; write scope opt-in), checked Oct 3, 2026: https://github.com/fivetran/fivetran-mcp
• •dbt Docs, dbt Wizard in Studio IDE (preview; per-file approvals), checked Oct 3, 2026: https://docs.getdbt.com/docs/dbt-ai/developer-agent