You Built on Google Cloud. Now Make Your Whole Estate Agentic & Autonomous with Data Workers
A guide for heads of data on Google Cloud: why your platform team is still the human control plane, and how to put the data back office on autopilot across GCP and everything else.
BigQuery, Looker and Knowledge Catalog give you one of the strongest analytics stacks there is. Google has added agents for data engineering, data science and business questions on top of it.
But your estate doesn't stop at Google's edge. Finance may still run on Snowflake. The ML team may have a Databricks workspace. Half your transformations may be dbt models that never moved to Dataform, scheduled by an Airflow you run yourself. When a Looker number goes wrong because of something upstream of BigQuery, a person still has to find it and fix it.
Your data platform has a control-plane problem, and the control plane is your team. People are the connective tissue between excellent tools that don't talk to each other, carrying context from one to the next by hand. The expensive part isn't knowing what needs doing. It's the doing: the building, the changing, the checking, the fixing.
What Google Cloud solved, and what it didn't
Google solved analytics on GCP. Knowledge Catalog understands what your GCP data means, and IAM and VPC Service Controls keep it safe. What Google doesn't do is operate the rest of your estate. Its agents act on GCP services, and its view of Snowflake, Databricks and dbt is read-only and in preview. That isn't a flaw. Google's agents exist to make GCP the center of gravity, and they do that well.
Google Cloud is where your analytics run. Data Workers is the agentic data platform that runs your whole data estate, inside GCP and beyond it.
Or, in one sentence for your team: Use Google's agents for your GCP data. Use Data Workers for everything that lives or breaks outside GCP, and for anything an AI writes that a person should approve.
What goes on autopilot
This is the part that changes your week. Each of these is a queue your platform team runs by hand today.

None of this requires replacing anything. Data Workers works inside the tools you already run, reasons across all of them, and leaves an auditable record of every change it makes. Your data stays in your infrastructure.
What changes for your organization
Here's what that looks like on a normal week.

- •Your platform team stops being the human control plane. The queues that used to wait for a platform engineer (access, schema changes, incidents, cleanup, catalog upkeep) move without them. Engineers spend their time on the work only they can do.
- •Incidents stop becoming meetings. A broken number is traced to its cause in whatever system it started in, fixed there and checked downstream, and the record is there when someone asks what happened.
- •Spend is managed continuously, not quarterly. Waste is found and cleaned up as it appears, across every platform you pay for, not only the one you standardized on.
- •Audits get easier. Every change has a receipt: who or what made it, why, what it touched, and how to undo it. Evidence builds up as a side effect of the work.
- •Big programs get smaller. Migrations that normally need a dedicated team become a series of approvals.
- •Everyone works from one shared understanding of your data. Definitions, owners and lineage across every platform live in one governed place, and nothing becomes official until a person approves it.
Side by side with Google Cloud
Google leads where it should: automatic metadata enrichment, self-serve answers and the security perimeter. On everything that lives outside GCP, and on getting a person's sign-off before AI-written metadata is trusted, Data Workers leads.

The reasoning behind every score, and the full technical comparison, is in Data Workers on Google Cloud.
Why teams choose Data Workers
- •It's an agentic data platform, not another tool. Most AI in data today is a copilot that helps one person do one task faster. Data Workers does the work: 20+ specialist agents that detect, fix, verify and remember across your whole estate.
- •It works where your team already works. People ask, delegate and approve from the coding agent they already use, whether that's Claude Code, Codex or Cursor. Spellbook is where you look: every asset, every change and every receipt.
- •It works with everything you already run. Google Cloud, your other platforms, dbt, Airflow and your BI tools stay exactly where they are. Nothing is migrated to get started.
- •It's governed from day one. Every change is scoped before it runs, approved at the level you set, recorded with a receipt and reversible in one click. No agent can approve its own work.
- •It gets better every time. Every fix is written back to one shared understanding of your data, so the next incident is caught earlier and fixed faster.
- •It's priced for ambition, not usage. Unlimited seats, no usage meter, and no markup on model spend. So more autonomy doesn't mean a bigger bill.
- •You're never locked in. The core is open source under Apache 2.0, and there's no notice period or exit fee.
One incident, start to finish
- •Finance's Snowflake team renames a column in a shared table.
- •A dbt model, run by your own Airflow, joins it into BigQuery and silently drops rows.
- •Knowledge Catalog's lineage stops at the edge of GCP, so nobody sees the connection.
- •The Looker revenue tile drops, and Google's agents can explain the drop but can't fix its cause.
Today that's a morning of Slack threads. Data Workers traces the drop past BigQuery to the Snowflake change, proposes the fix to the dbt model, confirms the Looker number is right again, and records what happened. Google Cloud's tools explain the symptom. Data Workers closes the ticket.
You choose how far and how fast
Our thesis is that data teams will climb from people working alongside a coding agent, to people governing a team of agents, to a largely self-running agentic enterprise. You don't have to jump. You choose the altitude, one area at a time.

Every area starts with agents watching and explaining. Then they propose changes for your team to approve. Then they make reversible changes on their own and leave a receipt. Only areas that have earned it run fully on their own, and any area can be dialled back at any time. No agent can approve its own work.
The detailed, stage-by-stage version is in our Google Cloud autonomy playbook.
How it fits with Google Cloud
- •IAM and VPC Service Controls stay the lock. Every change in GCP goes through the roles you grant, inside your perimeter.
- •Knowledge Catalog stays the governance plane for GCP. We read it and add what it can't see.
- •Looker and Conversational Analytics stay the front door for questions.
Nothing is migrated, and no data is copied out of your platforms. Data Workers stores metadata and scrubbed facts about your data, not your tables.
When you don't need Data Workers
Be honest with yourself about these:
- •Your estate is GCP-only, with pipelines in Dataform and no Snowflake or Databricks in the critical path.
- •Your main need is Q&A over BigQuery and Looker.
- •Your platform team isn't the bottleneck.
If all three are true, keep your budget. If any of them isn't, the rest of this guide is about you.
Where to start
Pick one area where your team is the bottleneck. Most GCP teams start with one of three: putting Snowflake, Databricks and dbt into one catalog next to Knowledge Catalog, access requests, or BigQuery spend. Each is easy to scope and easy to measure.
Start with a pilot. A forward-deployed engineer connects your estate and runs the first areas alongside your team, so you see results on your own data before you commit. Book a demo, join the pilot program or see pricing.
If your architects want the detail, send them Data Workers on Google Cloud. It covers what Google Cloud does, what Data Workers adds, and the four products that do the work: Data Context Wizard, the Data-Agents Swarm, the Autonomous Data-Conductor and Spellbook. The thinking behind them is in our thesis.