BigQuery Data Engineering Agent vs the Data-Agents Swarm: One Agent in Dataform, or Specialists Across the Estate
Google's Data Engineering Agent drafts Dataform pipelines in BigQuery. The Data-Agents Swarm owns the work across dbt, Airflow, Snowflake and BigQuery, with approvals and receipts.
If your transformations live in BigQuery, the Data Engineering Agent is probably already in your Dataform workspace. It went GA on April 22, 2026. An engineer types "dedupe the orders feed and load it into clean_orders," and the agent writes the SQLX, adds assertions, proposes the change and waits for someone to click Apply. Google has shipped updates to it almost every month since: BigQuery Graph context for schema mapping in September, Knowledge Catalog scorecards on October 1 and a new Gemini model on October 2.
Most estates don't end at the Dataform repository. An Airflow DAG exports a BigQuery table to Snowflake every night. The finance team's dbt project builds revenue models on top of it. A Tableau dashboard goes to the CFO every morning. The agent sees the Dataform graph and the Knowledge Catalog metadata for BigQuery. The rest of the estate belongs to other tools, other owners and other reviews.
The Data Engineering Agent is the pipeline author in your Dataform workspace. The [Data-Agents Swarm](/product/data-agents-swarm/) is the crew that owns the work across BigQuery, dbt, Airflow and every target outside Google Cloud. Data Workers is the agentic data platform: 20+ specialist agents, one governed context graph and one approval flow that run the whole data lifecycle. Google Cloud is where your analytics run, and the Data Engineering Agent is a strong way to write pipelines there. Keep it. This page is about the work that starts once the SQLX leaves the workspace.
This is the choosing page. For the wiring on a Google Cloud stack, read Data Workers on Google Cloud. For the catalog question, read Knowledge Catalog vs Spellbook Data Catalog. For the executive version, read the Google Cloud data leader's guide.
Key takeaways
- •One agent in one workspace, or specialists across the estate. The Data Engineering Agent drafts and changes Dataform pipelines that load and process data in BigQuery. The Data-Agents Swarm runs 20+ specialist agents across BigQuery, dbt, Airflow, Snowflake, Databricks and BI.
- •The agent proposes and a person runs. Google's docs say it "cannot execute pipelines. You must review and run or schedule pipelines." Its root cause analysis on failed runs is in preview and needs Premium Support.
- •The swarm checks a change everywhere it lands. The Data Change Review agent walks lineage from the changed BigQuery table into Airflow, Snowflake, dbt and BI before merge, and the right agent opens the paired fix.
- •Every Data Workers change is approved or reversible and leaves a tamper-evident receipt, with autonomy set per domain from L1 observe to L4 autonomous.
- •Data Workers runs the rest of the back office too: incidents, data quality, access requests, cost cleanup, schema changes and migrations.
- •Use both. The Data Engineering Agent for Dataform pipelines in BigQuery. Data Workers for owning the outcome across the estate. Nothing migrates.
Six things the Data-Agents Swarm adds on top of the Data Engineering Agent
1. Pipelines in the tools you already run. The agent works in Dataform workspaces and the BigQuery pipelines interface. The Pipeline Building agent and the Orchestration agent work in dbt projects and Airflow DAGs, and deploy to Airflow, Dagster and Prefect. If your team chose dbt for portability across warehouses (our dbt vs Dataform guide covers that choice), nothing has to move to Dataform to get agent help.
2. Blast radius past the BigQuery edge. The Data Change Review agent takes the table a change touches and walks lineage beyond Google Cloud: into the Airflow DAG that exports it, the dbt model in Snowflake that reads it and the dashboard that shows it. It posts schema, value and lineage diffs before the change merges.
3. Fixes that get run and verified. The Data Engineering Agent stops at a reviewed draft, and running it is your job. The Autonomous Data-Conductor takes a failure through detect, diagnose, fix, review, verify and remember. It triggers the rerun after approval and only closes the incident once downstream checks pass.
4. One governed context graph. Data Context Wizard joins BigQuery schemas and job history with dbt manifests, Airflow DAG and task state, Snowflake query history and BI metadata, through 50+ connectors. Every fact carries its source, author and the time it was observed.
5. Receipts and rollback for every change. Every change Data Workers executes records who or what made it, why, what it touched, who approved it and how to undo it. No agent can approve its own work, and that rule is enforced in code.
6. The jobs a pipeline agent isn't built to own. Incident response across systems, least-privilege access requests, BigQuery spend tracking with fixes drafted for the owner, cross-system schema changes, and migrations in either direction in approved waves. These compete for the same engineers the Data Engineering Agent is helping.
Behind all six is the coding agent your team already uses as the way in, such as Claude Code, Codex or Cursor. Every Data Workers agent is an MCP server.
One change, six systems
Here is a change most BigQuery teams will recognize. It's an illustration, not a customer case.
- •Monday 10:05. A data engineer asks the Data Engineering Agent in Dataform to convert
order_tsinstg_ordersfrom Eastern time to UTC, to match a new event source. - •10:15. The agent drafts the SQLX and an assertion. The data preview looks right. Inside BigQuery, the change is correct.
- •10:30. The engineer applies the draft and opens the pull request on the GitHub repository behind the Dataform workspace.
- •18:00. After merge, the Dataform workflow runs with UTC timestamps.
- •01:00 Tuesday. The nightly Airflow DAG exports
stg_ordersto Snowflake. - •02:10. The finance team's dbt Cloud job builds
fct_daily_revenue, which castsorder_tsto a date and assumes Eastern time. Late-evening Eastern orders now land on the next day. The not-null and uniqueness tests pass. - •08:30. The Tableau daily revenue tile goes to finance, and revenue has shifted between days right before month-end close.
| Step | What the Data Engineering Agent sees | What Data Workers does |
|---|---|---|
| SQLX change in Dataform | The pipeline code, the assertion and the data preview, all passing | Nothing yet. Data Workers watches the change, not the prompt. |
| Pull request in GitHub | Outside its loop; a person reviews and merges | The Data Change Review agent takes stg_orders and walks lineage: the Airflow export, fct_daily_revenue in Snowflake and the revenue tile all read order_ts. It posts the blast radius before merge. |
| dbt model in Snowflake | Outside Google Cloud; not described in its docs | The Schema Evolution agent proposes a paired dbt diff that converts UTC to Eastern before the date cast, with its own blast radius. |
| Airflow export | Not visible | Merge order is pinned so the dbt change ships with the Dataform change. The Orchestration agent can rerun the DAG after approval. |
| Tableau tile | Not visible | After the 02:10 run, a value check compares daily revenue to source totals. It passes, and the receipt records both changes, the approver and the rollback path. |
The Data Engineering Agent did its job well. The SQLX was right. The problem was four systems downstream that nobody in that workspace could see.
What the Data Engineering Agent covers, as of October 2026
Google now presents its data portfolio as the Agentic Data Cloud, and the Data Engineering Agent is its pipeline agent. It ships as part of Gemini in BigQuery. Here is what Google's documentation and release notes say ships today.
| Area | What Google ships | Status (Oct 2026) |
|---|---|---|
| Data Engineering Agent | Builds, modifies and troubleshoots data pipelines that load and process data in BigQuery | GA since April 22, 2026 (preview from October 27, 2025) |
| Surfaces | Dataform workspaces and the BigQuery pipelines interface; VS Code through an extension | GA; the VS Code extension is preview. Not supported in notebooks or data preparation files |
| Code it writes | SQLX, dimension tables, aggregations, data quality assertions and UDFs; targets are BigQuery tables, views and Iceberg tables | GA |
| Review and run | Proposes a draft that a person applies; "cannot execute pipelines. You must review and run or schedule pipelines" | Current |
| Troubleshooting | Root cause analysis on failed pipeline runs through Gemini Cloud Assist investigations | Preview; requires Premium Support |
| Knowledge Catalog | Reads glossaries and data profiles; publishes data quality scorecards; generates semantic metadata for pipeline assets | GA since October 1, 2026 |
| BigQuery Graph | Context between source and destination schemas for schema mapping | GA since September 10, 2026 |
| Migration | Translates legacy tool formats into native BigQuery pipelines, per Google's launch post | Described in Google's blog |
| Instructions | Team conventions in GEMINI.MD context files | Current |
| Compliance | HIPAA compliant | Since August 27, 2026 |
| Related Google agents | Data Science Agent (GA May 26, 2026); conversational analytics (GA on BigQuery and Looker); Database Observability Agent (preview); Data Agent Kit for IDEs and coding agents (announced in preview April 22; plugin 1.0 on Sept 29) | Mixed |
| MCP | Managed MCP servers for BigQuery, Knowledge Catalog, Dataform and Managed Service for Apache Airflow (formerly Cloud Composer) | Listed on Google's supported products page |
Every row describes a person building pipelines faster inside Google Cloud. None of them describes a standing owner for a class of work across the estate. That's the job the swarm does.
One platform, not one more tool
Writing pipelines is one job on a data team's list. The same team also keeps the catalog honest, answers questions, runs quality checks, closes incidents, runs schema changes and migrations, handles access, protects sensitive data, cuts spend and keeps models fed with good data. Each point tool covers one or two of those, and each one adds another console, another contract and another handoff.
Data Workers covers the whole data lifecycle with one context graph, one approval flow and one audit trail. We score the same ten stages on every comparison page, so you can compare tools across pages. The Data Engineering Agent leads on its home stage, Pipelines & Ingestion, which is exactly what it was built for.
| Stage | Data Workers | Data Engineering Agent | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 5 | The agent reads Knowledge Catalog glossaries and data profiles and writes semantic metadata for the pipelines it builds. Data Workers keeps one context graph across BigQuery, dbt, Airflow, Snowflake and BI. |
| Analytics & Insights | 8 | 3 | Questions and analysis belong to other Gemini in BigQuery features, such as conversational analytics. Data Workers answers across platforms from governed context. |
| Data Quality | 8 | 6 | The agent writes Dataform assertions and publishes data quality scorecards to Knowledge Catalog. Data Workers writes, runs and repairs checks and dbt tests across platforms. |
| Observability & Incidents | 8.5 | 4 | Root cause analysis on failed pipeline runs is in preview and needs Premium Support. Data Workers traces incidents across systems, fixes them and verifies the result. |
| Pipelines & Ingestion | 8.5 | 9 | The agent's home stage: it builds and changes Dataform pipelines from a prompt, GA since April 2026. Data Workers works across dbt, Airflow, Dagster, Prefect and ingestion tools. |
| Schema & Migration | 8 | 6 | The agent translates legacy pipelines into BigQuery pipelines and uses BigQuery Graph for schema mapping. Data Workers drafts schema changes across systems with rollback SQL for the owner to apply, and plans migrations in any direction. |
| Governance & Access | 8.5 | 3 | The agent works with the signed-in user's IAM roles; it doesn't run access requests. Data Workers proposes least-privilege grants on BigQuery and every other platform behind approvals. |
| Security & Privacy | 8 | 5 | The agent encrypts columns flagged as PII and is HIPAA compliant. Data Workers flags sensitive column names in pull request review on every platform and leaves a receipt on every change. |
| Cost / FinOps | 8 | 2 | The agent doesn't work on your BigQuery bill. Data Workers reads BigQuery spend from the Jobs API and drafts each fix for its owner. |
| MLOps & Models | 7.5 | 2 | Model work is the separate Data Science Agent. Data Workers keeps the data under models healthy and connects to MLflow and W&B. |
The Data Engineering Agent vs the Data-Agents Swarm on the outcomes you buy
The ten-stage view shows breadth. This view scores eight outcomes a data leader pays for. The Data Engineering Agent leads on two, both on its own ground: writing Dataform pipelines from a prompt, and moving legacy pipelines into BigQuery. Data Workers leads on the six that decide whether work lands safely across the estate.
| Outcome | Data Workers | Data Engineering Agent | Why we scored it this way |
|---|---|---|---|
| Dataform pipelines written from a prompt | 6 | 9 | The agent leads on its own surface. It writes SQLX, assertions and UDFs in a Dataform workspace and proposes edits to existing pipelines. Data Workers works through the coding agent your team already uses. |
| Legacy pipelines moved into BigQuery | 7 | 8 | Google says the agent translates legacy tool formats into native BigQuery pipelines. Data Workers translates SQL dialects and plans moves in approved, parity-checked waves, in any direction. |
| Pipelines built and changed in dbt and Airflow | 9 | 2 | The agent's docs describe Dataform and BigQuery pipelines only. Data Workers agents read and change dbt projects and Airflow DAGs through each system's own API. |
| Changes carried to targets outside Google Cloud | 9 | 2 | The agent writes to BigQuery tables, views and Iceberg tables. Data Workers works on Snowflake, Databricks and BigQuery as full control planes. |
| Blast radius checked across systems before merge | 9 | 4 | The agent sees the Dataform graph and Knowledge Catalog metadata. The Data Change Review agent walks lineage past BigQuery into Airflow, Snowflake, dbt and BI before the change ships. |
| Failed runs fixed, rerun and verified | 8.5 | 4 | Google's docs say the agent 'cannot execute pipelines', and its root cause analysis is in preview. Data Workers fixes the cause, triggers the rerun after approval and verifies downstream. |
| Every change approved or reversible, with a receipt | 9 | 5 | A person reviews and applies the agent's draft, and Dataform keeps Git history. Every Data Workers change carries a tamper-evident receipt and a rollback path. |
| Access, cost and audit work owned | 8 | 2 | Access requests, cost cleanup and audit evidence are outside the agent's job. Data Workers runs each of them behind approvals. |
These are directional scores of scope, not benchmarks. We've shown the reasoning so you can check every line against the Google docs linked below.
Why doesn't the Data Engineering Agent just do this itself?
Because Google built it for a different job, and built it well for that job.
The Data Engineering Agent is a Gemini in BigQuery feature. It runs in one engineer's Dataform workspace, with that engineer's IAM roles (Dataform Code Editor, BigQuery Job User and a Gemini chat role), and it stops at a draft. Google's docs are direct: the agent "cannot execute pipelines," and you "review and run or schedule" them. For an authoring assistant that's the right design. The agent can never do more than the person in the seat, and nothing reaches production until a person applies it and runs it.
Owning work across production systems is a different product category. It needs standing, scoped identities instead of a person's session. It needs blast radius computed across systems Google doesn't run, approvals that vary by domain, rollback paths and a receipt an auditor can read. And it means taking responsibility for changes inside a dbt project, a self-managed Airflow deployment, a Snowflake warehouse or a Tableau workbook. Google's own launch post pitches the agent for consolidating processing engines onto BigQuery pipelines, which makes sense for Google. An agent that rewrites your Snowflake dbt project would cut against it. That's the product Data Workers is.
Where the Data Engineering Agent stops
Each limit below comes from Google's own documentation. None of them is a flaw. They follow from building an authoring agent for BigQuery.
It drafts, and a person runs. The agent proposes; you apply the draft, then run or schedule the pipeline. When a run fails, root cause analysis through Gemini Cloud Assist is in preview, requires Premium Support and ends at a suggested fix.
Its world is Dataform and BigQuery. Targets are BigQuery tables, views and Iceberg tables. It reads sources through BigQuery connections, such as Cloud SQL, Spanner, S3 and Azure Blob Storage. The documentation page doesn't mention dbt, Airflow, Snowflake or Databricks.
It works for one person at a time. The agent works in the workspace of the person who asked, with their IAM roles. There's no team queue of work the agent owns, and no named approver per domain.
It writes what the prompt says. Practitioners who have tested it report clean, consistent boilerplate, and also SQL that misses unwritten business rules such as time zones, soft deletes and late-arriving data. The model isn't at fault here. Those rules live in systems the agent can't see, such as the dbt model in Snowflake in the example above.
The back office sits outside it. Access requests, cost cleanup, cross-system schema changes, migrations off BigQuery and audit evidence are not what the agent is for. Data Workers runs every one of them.
Where the two overlap
"Both" means the engineer keeps the Data Engineering Agent, and Data Workers owns what happens after the change leaves the workspace.
| Job to be done | Data Engineering Agent | Data Workers | What we recommend |
|---|---|---|---|
| Writing Dataform pipelines from a prompt | SQLX, assertions, UDFs (GA) | Through your coding agent | Data Engineering Agent |
| Pipelines in dbt and Airflow | Not described in its docs | Pipeline Building and Orchestration agents | Data Workers |
| Moving legacy pipelines into BigQuery | Translates legacy formats | Data Migration agent, parity-checked in waves | Data Engineering Agent for Dataform-bound moves; Data Workers for any other direction |
| Reviewing a change before merge | A person reviews the draft | Data Change Review agent, across systems | Data Workers |
| Failed pipeline runs | Root cause in preview; you rerun | Conductor fixes, reruns after approval and verifies | Data Workers, starting from Google's diagnosis when you have it |
| Data quality | Assertions and Knowledge Catalog scorecards | Checks and dbt tests across platforms | Both |
| Access and governance | Works with the user's IAM roles | Access & Governance and Identity agents propose grants behind approvals | Data Workers |
| Cost cleanup | Outside its job | BigQuery spend from the Jobs API; each fix drafted for its owner | Data Workers |
| Audit evidence | Dataform Git history | Receipt on every change, in Spellbook | Data Workers |
What it costs
Google lists the Data Engineering Agent as a Gemini in BigQuery feature. Gemini's pricing page says the core Gemini in BigQuery features (SQL and Python code assist, data canvas and data preparation) come at no additional cost in every BigQuery edition. The pipelines the agent writes run on your BigQuery compute, and its root cause investigations need Premium Support. Check Google's Gemini pricing page for how your edition packages the agent.
Data Workers is a flat platform fee. The Apache 2.0 core is free. A pilot is $7,500 one-time. Scale starts at $1,000 a month and Enterprise at $3,000 a month (billed annually). Seats are unlimited, there's no usage meter, and there's no markup on model spend because you bring your own model. See pricing.
You don't trade one for the other. The agent stays the way your engineers write Dataform pipelines. Data Workers owns the work across the estate, so the hours senior engineers spend on cross-system review, reruns, access tickets and cost cleanup go back to building.
The case for your CFO
The outcome. Pipeline changes your engineers ship in BigQuery land correctly in every system downstream, including the dbt models, Snowflake tables and dashboards finance reads. The recurring work that eats senior engineering time (cross-system review, reruns, access tickets, cost cleanup) runs without a person driving it.
The risk story. Every Data Workers agent starts observe-only (L1). At propose (L2), every change is a draft a person approves. At act reversibly (L3), agents run only changes they can undo, in the domains you've moved up. Autonomous (L4) is a per-domain choice, never a default. Every write is scoped before it runs, no agent approves its own work, and every receipt records what changed, why, who approved it and how to undo it. Zero migration: your data stays in BigQuery and everywhere else it lives today.
Why now. The Data Engineering Agent raises the number of pipeline changes each engineer ships. More changes into a multi-system estate means more chances for one to break something nobody in the workspace can see. Review and ownership have to scale with authoring.
The first win. Cross-system blast radius on every Dataform change to a table read outside BigQuery, in observe mode, from the first week.
What stays the same. BigQuery stays where your analytics run. Dataform and the Data Engineering Agent stay in your engineers' hands. Knowledge Catalog and IAM stay authoritative, and your CI and code review stay where they are.
The pilot path. Start with a pilot on one domain, usually review for tables that leave BigQuery. See pricing; the pilot is credited in full against the first year.
The sentence to repeat upstairs: "Google's agent writes our BigQuery pipelines faster; Data Workers makes sure every change lands safely in dbt, Airflow, Snowflake and our dashboards, and runs the recurring work nobody should do by hand, with an approval and a receipt for each change."
The fastest first win: review every change that leaves BigQuery
Start with the changes that hurt in the example above. Connect Data Workers to BigQuery, the GitHub repository behind your Dataform workspace, and the dbt project and Airflow deployment downstream, all in observe mode. When a pull request changes a BigQuery table that something outside Google Cloud reads, the Data Change Review agent posts the blast radius: which Airflow DAGs, dbt models and dashboards read the changed columns, with a risk rating for the code change. Nothing is written yet. Our guide to BigQuery schema changes and downstream dashboards shows the same pattern for schema changes.
When your reviewers have agreed with those reports for a few weeks, move the domain up to propose: the agents propose the paired dbt diff and the rerun plan for approval. Engineers keep the Data Engineering Agent exactly as they use it today.
What each Data Workers product does
Data-Agents Swarm. 20+ specialist agents that own classes of work: Pipeline Building, Orchestration, Data Change Review, Schema Evolution, Incident Debugging, Quality Monitoring, Access & Governance, Security, Identity, Cost Savings & Data Cleanup, Data Migration, Streaming, MLOps and more. Each is an MCP server. On BigQuery, the governance agents list privileges and propose time-boxed grants, the cost agent reads spend from the Jobs API, and the migration agent translates BigQuery SQL in either direction.
[Autonomous Data-Conductor](/product/autonomous-data-conductor/). The orchestrator that owns an outcome rather than a step. It runs detect, diagnose, fix, review, verify and remember across the estate, routes work to the right agents and scopes the blast radius before anything changes.
Data Context Wizard. One governed graph across BigQuery, Snowflake, dbt, Airflow and BI, with 50+ connectors. BigQuery connects as a full control plane, including permissions and policy. Knowledge Catalog entries reach it through your coding agent over MCP.
[Spellbook Data Catalog](/product/spellbook-data-catalog/). The control plane for agent work, in preview. Every proposed change lands in one inbox to approve, steer, send back or roll back, and an authority guard in code stops any agent approving its own work.
Autonomy guardrails and security
The Data Engineering Agent manages risk by keeping a person in the workspace and leaving execution to them. Data Workers manages risk for work nobody is watching live, with graded, reversible control.
- •New deployments start observe-only. You raise autonomy one domain at a time, as the receipts earn trust.
- •Autonomy is set per domain, from L1 observe through L2 propose and L3 act reversibly to L4 autonomous. Review of BigQuery changes can propose fixes while access grants stay at observe.
- •Every write is scoped before it runs, with blast radius computed across platforms.
- •Every change is approved or reversible and leaves a tamper-evident receipt: what changed, why, who approved it and how to undo it.
- •No agent can approve or promote its own work. This is enforced in code.
- •Least privilege. Data Workers acts with the grants you give it, through each platform's own permission system, including BigQuery IAM.
- •Zero migration. Data Workers stores metadata and scrubbed facts about your data, not copies of your tables.
"Google has MCP servers and a Data Agent Kit. Doesn't that cover dbt and Airflow?"
It covers part of it. Google lists managed MCP servers for BigQuery, Knowledge Catalog, Dataform and Managed Service for Apache Airflow, and the Data Agent Kit brings Google Cloud skills into VS Code, Gemini CLI, Codex and Claude Code. Google's announcement says the kit can pick frameworks such as dbt, Spark or Airflow, and its pipeline docs deploy to Managed Airflow and Managed Service for Apache Spark, with automated deployment through GitHub Actions. That's useful for an engineer building on Google Cloud.
It's still one engineer, one session and one change at a time, aimed at Google Cloud services. MCP gives an agent one more tool. It doesn't give your team an owner for a class of work, a blast radius across Snowflake and Tableau, a named approver per domain, a rollback path or a shared record of what happened. Data Workers gives you that operating model. Every Data Workers agent is itself an MCP server, so the same coding agent that loads Google's kit can call the Change Review agent before it opens a pull request.
How it fits together
Getting started takes no migration. Connect Data Workers to BigQuery, your Git repositories, the dbt project, Airflow and your BI tool. Knowledge Catalog and Dataform connect over their APIs or MCP servers today. The Context Wizard builds the graph, every agent starts observe-only, and the first thing you see is the cross-system blast radius of the pull requests your team is already opening.
When the Data Engineering Agent alone is enough
The Data Engineering Agent alone can be enough if your whole estate lives in Google Cloud: ingestion into BigQuery, transformations in Dataform, dashboards in Looker, models in Vertex AI, with no dbt project, no second warehouse and no outside BI tool. If that's you, the agent plus Google's other agents covers a lot of ground.
Most teams don't look like that. If a BigQuery table feeds Snowflake, dbt, Airflow or a BI tool outside Google Cloud, or if your engineers spend their weeks on reruns, access tickets and cost cleanup, the SQLX was never the expensive part. Owning the outcome is, and that's the job of the Data-Agents Swarm.
FAQ
What is the BigQuery Data Engineering Agent? It's Google's AI agent for building, modifying and troubleshooting data pipelines in BigQuery, part of Gemini in BigQuery. It writes SQLX in Dataform workspaces and the BigQuery pipelines interface from natural-language prompts, and a person reviews, applies and runs the result. It went GA on April 22, 2026.
Does the Data Engineering Agent work with dbt or Airflow? Its documentation describes Dataform workspaces and the BigQuery pipelines interface, with BigQuery tables, views and Iceberg tables as targets. It doesn't describe dbt or Airflow. Google's separate Data Agent Kit works in IDEs and coding agents and deploys to Google Cloud services. Data Workers agents work in dbt projects and Airflow DAGs directly.
Can the Data Engineering Agent run or fix pipelines on its own? No. Google's docs say it "cannot execute pipelines" and that you review and run or schedule them. Its root cause analysis for failed runs is in preview and needs Premium Support. Data Workers fixes the cause, reruns after approval and verifies downstream, at the autonomy level you set.
How is it different from the Data Science Agent and conversational analytics? They're separate Gemini features. The Data Science Agent (GA since May 26, 2026) works on the model lifecycle in notebooks. Conversational analytics answers business questions over BigQuery and Looker. The Data Engineering Agent builds pipelines.
Should we move our dbt project into Dataform to use the agent? Only if you want to standardize on BigQuery for other reasons. If dbt is how you stay portable across warehouses, keep it. Data Workers works on dbt and on BigQuery, so you get agent help without a migration.
Does Data Workers work with the Data Engineering Agent? Yes. Data Workers reviews the changes the agent helps produce like any other change to BigQuery, reads BigQuery directly, and connects to Knowledge Catalog and Dataform over their APIs or MCP servers today. Every Data Workers agent is an MCP server your coding agent can call.
How much does Data Workers cost? A free Apache 2.0 core, a $7,500 one-time pilot, Scale from $1,000 a month and Enterprise from $3,000 a month (billed annually), with unlimited seats and no usage meter. See pricing.
Sources
Sources for Google Cloud capabilities and statuses: Google Cloud documentation, release notes and blog posts current as of October 2, 2026, including the Data Engineering Agent overview (updated September 30, 2026), the BigQuery release notes (entries for October 27, 2025, April 22, May 26, August 27, September 10, October 1 and October 2, 2026), Exploring the Data Engineering Agent in BigQuery (November 3, 2025, updated April 22, 2026), What's new in the Agentic Data Cloud, the Gemini in BigQuery overview (updated September 30, 2026), Gemini for Google Cloud pricing, the Data Agent Kit overview and pipelines guide (updated September 30, 2026), supported MCP products (updated October 2, 2026) and the Managed Service for Apache Airflow docs. Product names and statuses change quickly; if we've got something wrong, tell us and we'll fix it.