You're on Google Antigravity. Here's how Data Workers builds on it
Your engineers direct agents in Google Antigravity. Add Data Workers to mcp_config.json and those agents plan from governed data context, while every data change goes through approvals and receipts.
Your engineers already direct agents in Google Antigravity. They open a project in Antigravity 2.0, the standalone command center that succeeded the Agent Manager in May 2026, and run several agents in parallel across Git worktrees. They start hard work in Planning mode, read the implementation plan artifact, leave inline comments, and approve it before a single file changes. Fast mode handles the quick renames. Scheduled tasks send a prompt to an agent every morning, the Antigravity CLI covers the terminal, and the IDE extensions bring the same agent into VS Code. If your company runs Antigravity through Gemini Enterprise, every session sits under your Google Cloud terms, VPC Service Controls and a regional endpoint. For directing agents that write and ship code, that setup is excellent. The open question for a data team is what happens when the plan an agent wrote changes a BigQuery table that a Looker Explore, a Composer DAG and a Vertex AI feature table all read.
That's where Data Workers comes in. Antigravity is where your engineers direct agents. Data Workers, the agentic data platform, is the data crew those agents call: it knows what a change touches and carries it into production, scoped, approved, verified and recorded. Connected over MCP, Antigravity's agents plan from Data Workers' governed context, and every change to data goes through Data Workers' approvals and receipts. Nothing about Antigravity changes. Your engineers keep the agent workbench they chose.
Key takeaways
- •Antigravity directs the agents; Data Workers carries the data change. Antigravity stays where engineers launch agents, review artifacts and approve plans. Data Workers supplies lineage, owners and blast radius, then applies the approved change and verifies it downstream.
- •The plan artifact gets the facts. With one rule in
.agents/rules/, an agent in Planning mode calls Data Workers before it plans, so the implementation plan you review already lists every downstream reader and the rollback path. - •Two locks on every write. Antigravity's permission engine puts every MCP tool in Ask mode until you allow it. Data Workers' per-domain guardrail gates the change to the warehouse. No agent approves its own work.
- •Scheduled tasks become a data morning check. A scheduled task can ask Data Workers for freshness, quality and cost findings every day, and wake a human only when a change needs approval.
- •Climb one domain at a time. Start at L1 observe (answers, lineage, impact in every plan), move to L2 propose, then L3 act reversibly where the record earns it.
Antigravity is the agent workbench. Data Workers is the data crew behind it.
Antigravity's agents know your code. They read rules, AGENTS.md and skills, work across multiple folders in a project, run commands in the terminal sandbox, and verify their work with diffs, walkthroughs and browser recordings. What they can't see from the repo alone is the live estate: which BigQuery tables a dbt model really feeds, which Looker Explore still reads a column, which Managed Service for Apache Airflow (formerly Cloud Composer) DAG builds a Vertex AI feature table from it, and who owns each one. Data Workers keeps that in one governed context graph and does the data side of the work through 20+ specialist agents.
Here is one change, end to end. This is an illustration, not a customer case.
| Time | System | What happens |
|---|---|---|
| 09:10 | Antigravity 2.0 | An engineer starts a Planning mode conversation in the analytics project: "Make fct_sessions incremental. It scans the whole events table every night." |
| 09:12 | Antigravity 2.0 | The Data Workers rule applies to dbt models, so the agent calls trace_cross_platform_lineage and blast_radius_analysis on the Data Workers MCP server while it plans. |
| 09:13 | dbt | Data Workers reports fct_sessions feeds four dbt models, the Engagement Explore in Looker and the ml_features_daily DAG in Cloud Composer. |
| 09:14 | Antigravity 2.0 | The implementation plan artifact lists the change, the blast radius from Data Workers and a 90-day backfill plan with rollback. |
| 09:20 | Antigravity 2.0 | The engineer leaves an inline comment ("keep a three-day window for late events") and approves the plan. |
| 09:41 | GitHub | The agent opens the pull request. Data Workers posts the impact report on it. |
| 09:58 | GitHub | dbt CI passes and the analytics lead approves the pull request. |
| 10:05 | Spellbook | The data platform owner approves the BigQuery backfill. |
| 10:07 | BigQuery | Data Workers starts the 90-partition backfill through the orchestrator, with the undo recorded first. |
| 10:52 | BigQuery | Row counts and session totals match the full-refresh baseline for every partition. |
| 11:00 | Cloud Composer, Vertex AI | The next ml_features_daily run succeeds and the Vertex AI feature table is fresh. |
| 11:05 | Looker | Engagement Explore totals match the baseline, and the receipt is recorded. |
Without that context, the same request is a tidy plan that passes CI, cuts the scan bill and quietly drops late-arriving sessions from a feature table a model retrains on. With it, the engineer approved one plan, the owner approved one data change, and the receipt says exactly what moved.
| Job | What Antigravity does | What Data Workers does |
|---|---|---|
| Understand the request | Reads the repo, rules, AGENTS.md and skills; researches the codebase in Planning mode | Adds live data context: lineage across dbt, BigQuery, Composer, Vertex AI and Looker, owners and usage |
| Plan the change | Writes the implementation plan artifact and takes inline comments | Supplies the blast radius, the readers to fix first and the backfill and rollback plan that go into the plan |
| Gate the action | Asks before any unconfigured MCP tool runs; permission presets and Allow, Ask and Deny rules set what auto-runs | Routes data changes to the domain owner by policy, with blast radius attached |
| Apply to production | Edits files, commits and opens the pull request | Applies the approved migration or backfill in the warehouse, with rollback ready |
| Verify | Runs tests, records walkthroughs and browser sessions | Checks the changed tables against baselines, then dashboards, downstream DAG runs and feature tables |
| Record | Keeps the conversation, artifacts and diffs | Writes a receipt to the audit trail: who asked, who approved, what changed, how to undo it |
Why doesn't Antigravity just do this itself?
Focus and risk. Google built Antigravity for one job: letting developers hand real software work to agents and review it at the right moments. Its design shows that. Agents work inside a project's folders, terminal commands run in a sandbox by default, the permission engine treats every MCP tool call as Ask until you allow it, and the Plan Review Policy halts at the plan when you set it to review every plan. Antigravity's own docs even show an Ask rule for a SQL server's mutation tool. That is exactly right for an agent workbench.
Changing production data across systems is a different product. It needs to know that a dbt model feeds a Vertex AI feature table through a Composer DAG that only fails a week later, when the model retrains. It needs a blast radius before anything runs, an approval routed to the owner of that domain rather than to whoever is reviewing the plan, a rollback path inside BigQuery, a parity check afterwards, and a receipt an auditor can read. It also means taking responsibility for changes in systems the agent workbench doesn't run. A sensible developer-tools team leaves that to the server on the other end of the MCP connection. That server is Data Workers.
Every tool owns a slice. Data Workers covers the whole lifecycle
Antigravity goes deepest on directing agents that write and refactor pipeline code. Data Workers covers every stage of the data lifecycle around that code. Each point tool adds another console, contract and handoff; Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail.
| Stage | Data Workers | Antigravity | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 5 | Antigravity reads rules, skills and AGENTS.md, and its MCP Store adds BigQuery and Dataplex servers. Data Workers keeps one governed graph of tables, owners, lineage and usage across platforms. |
| Analytics & Insights | 8 | 5 | Antigravity's agents can query BigQuery through an MCP server and write a report as an artifact. Data Workers answers business questions from governed metric definitions. |
| Data Quality | 8 | 5 | Antigravity writes dbt tests and checks when asked and verifies its own code. Data Workers runs quality checks, writes the missing tests and repairs failing ones. |
| Observability & Incidents | 8.5 | 3 | Antigravity verifies code with browser recordings and walkthroughs. Data Workers detects data incidents, traces the cause and closes them with a receipt. |
| Pipelines & Ingestion | 8.5 | 9 | Antigravity's home stage: parallel agents, Planning mode and implementation plans write and refactor pipeline code across projects. Data Workers builds and reruns pipelines behind approval. |
| Schema & Migration | 8 | 6 | Antigravity writes migration code and DDL. Data Workers assesses the impact, drafts each migration with its rollback SQL for the owner to apply in approved waves. |
| Governance & Access | 8.5 | 3 | Antigravity's permission engine and enterprise admin policies govern its own agents. Data Workers proposes least-privilege grants on your data platforms behind approvals. |
| Security & Privacy | 8 | 5 | Antigravity offers a terminal sandbox, VPC Service Controls and regional endpoints for its own sessions. Data Workers' pull request review flags new columns whose names or annotations look sensitive, and leaves a receipt on every data change. |
| Cost / FinOps | 8 | 2 | Antigravity shows quota and AI credits for Antigravity. Data Workers traces Snowflake credits to the query and dbt model behind them and drafts the fix for the model's owner. |
| MLOps & Models | 7.5 | 4 | Antigravity writes training and feature code. Data Workers keeps the data under models healthy and connects to MLflow and W&B. |
How Antigravity and Data Workers work together
Antigravity stays on top, where engineers launch agents, review artifacts and approve plans. Data Workers sits underneath over MCP: the Data Context Wizard answers from the governed graph, the Data-Agents Swarm does the work, the Autonomous Data-Conductor runs each fix end to end, and Spellbook Data Catalog (in preview) is where people review, roll back and audit.
Connect the MCP server. Every Data Workers agent is a standard MCP stdio server, and Antigravity reads stdio servers from mcp_config.json, so the pattern in our client setup docs carries straight over. Clone the open-source core (dataworkers-claw-community, Apache 2.0), run npm install, and add the agents you want to the project's .agents/mcp_config.json, or to ~/.gemini/config/mcp_config.json to use them in every project. In Antigravity 2.0 the servers then show under Settings, Customizations, Installed MCP Servers; in the CLI, /mcp shows their status. Example:
{
"mcpServers": {
"dw-context-catalog": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-context-catalog"] },
"dw-schema": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-schema"] },
"dw-incidents": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-incidents"] },
"dw-quality": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-quality"] }
}
}The same file works across Antigravity 2.0, the CLI and the IDE, and the Antigravity SDK discovers .agents/mcp_config.json too, so custom agents your platform team builds get the same tools. Teams coming from Gemini CLI move the block out of settings.json into this file; our Gemini CLI guide shows the old shape.
Add a Data Workers rule. Antigravity discovers rules from .agents/rules/*.md (with YAML frontmatter), AGENTS.md and GEMINI.md, and injects them into every agent's context. One short rule tells the agent when to call Data Workers: trace lineage before editing a dbt model, check load lag against its baseline before trusting a query, run a quality check before merge, diagnose before patching anything described as broken, check policy on code that touches personal data, and assess schema impact on migrations and DDL. Example, as .agents/rules/data-workers.md (every file in .agents/rules/ needs YAML frontmatter with a trigger; drop the frontmatter if you paste the lines into AGENTS.md instead):
---
trigger: model_decision
description: "Changes to dbt models, SQL, DDL or pipelines"
---
- Before editing a dbt model or DDL, call trace_cross_platform_lineage and blast_radius_analysis and put every downstream reader in the implementation plan.
- Before trusting a query result, call get_incident_history for open incidents on the tables it reads.
- Before merge, call run_quality_check on changed models.
- When something is described as broken, call diagnose_incident before patching.
- On code that adds a column holding personal data, annotate the column and ask the data owner before merge.Set the gates. Antigravity's permission engine evaluates Deny, then Ask, then Allow, and matches MCP tools as mcp(server/tool) or mcp(server/*). Under the Default and Request Review presets, unconfigured MCP tools ask first. We recommend allowing the read tools so planning runs without a prompt and keeping anything that changes data on Ask, behind Data Workers' own guardrail. Example rules:
Allow:
mcp(dw-context-catalog/trace_cross_platform_lineage)
mcp(dw-context-catalog/blast_radius_analysis)
mcp(dw-schema/assess_impact)
mcp(dw-quality/run_quality_check)
Ask:
mcp(dw-schema/apply_migration)
mcp(dw-schema/rollback_migration)Set the Plan Review Policy (the setting formerly called the artifact review policy) to review every plan for data projects, and keep those projects off the Turbo preset, which allows MCP tools without prompting. On Gemini Enterprise, admin policies cover MCP allowlists and permission thresholds across the organization, so the platform team approves Data Workers once.
One request, from L0 to L4. Take one request an engineer types into Antigravity: "yesterday's daily active users in Looker look 12% low, find out why and fix it". Here is what happens at each level, set per domain.
| Level | What happens when the engineer asks |
|---|---|
| L0 manual | The agent helps the engineer read DAG logs and write SQL by hand. Data Workers isn't in the loop. |
| L1 observe | The agent calls diagnose_incident. Data Workers answers in the conversation: the events load in Composer ran before the upstream export finished, one partition is short, two Explores are affected, and the owner is the product analytics team. |
| L2 propose | Data Workers drafts the fix (a sensor on the upstream export plus a one-partition reload) with its blast radius, and the agent puts it in the implementation plan. The engineer approves the plan and the owner approves the data change. |
| L3 act reversibly | For this pre-approved class of fix, Data Workers reloads the partition itself, with rollback ready, checks the Explore totals and records the receipt. The engineer sees the result in Antigravity. |
| L4 autonomous | Late-load incidents in this domain run end to end without waiting: detect, fix, verify, record. A scheduled task asks Data Workers each morning for the overnight receipts, and the owner reviews them in Spellbook and can dial the domain back at any time. |
What changes for your team
Engineers keep their agents and their habits. What changes is the work around each data change: the hunt for who reads a table, the Slack thread to find an owner, the manual backfill, the evidence an auditor asks for months later.
The data platform team stops being the human lookup service for lineage and ownership. Analytics engineers approve plans that already carry the impact. Owners approve data changes in one place with the blast radius in front of them. And the audit trail builds itself from receipts instead of screenshots of a conversation.
Keep Antigravity, or consolidate?
Keep Antigravity if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
For most data teams, Antigravity stays. It is where engineers chose to direct agents, and Data Workers is built to sit underneath it. What teams tend to consolidate are the extra tools around data changes: the separate lineage lookup, the impact script someone maintains, the spreadsheet of who owns what, the manual runbook for backfills. Data Workers runs that work with one context, one approval flow and one audit trail, and it serves every other MCP client from the same agents. If parts of your company work elsewhere, read You're on Gemini Enterprise for the people asking questions in the same Google license, and You're on Cursor for engineers in another editor, or start from the hub, Your company just rolled out AI assistants. Now what?.
The case for your CFO
You already pay for Antigravity, through Google AI plans or a Gemini Enterprise license, and your engineers hand more work to agents every week. The outcome Data Workers adds is that the data changes those agents write are right the first time: fewer broken dashboards, fewer stale feature tables under production models, and less senior engineering time spent tracing who reads what.
The risk story is plain. At L1, agents only read and explain. At L2, they propose and a named owner approves. At L3, they act only on pre-approved, reversible classes of change, with rollback ready. Every action leaves a receipt with who asked, who approved, what changed and how to undo it. Our safety guide covers what an agent can and can't do at each level, and the security and deployment guide covers where your data goes.
Why now: Antigravity's agents now run in parallel, on schedules and from any web browser through Remote Control. The more work they do while nobody watches, the more each data change needs context and an approval trail. Building that layer in house is possible, and our build-vs-buy guide lays out what it takes.
The first win is impact reports inside every implementation plan for one dbt project, at L1, with no change to how anyone works. What stays the same: Antigravity, BigQuery, dbt, Composer, Looker, Vertex AI and your IAM. Nothing is migrated. Our ROI guide shows how to size the return.
The sentence to repeat upstairs: "Our engineers keep Antigravity; Data Workers makes every data change its agents write scoped, approved, verified and recorded."
Getting started
Start with a pilot: connect Data Workers to Antigravity in one project, add the rule and the permission settings, and run one domain such as freshness incidents or schema changes from L1 to L2 with your own engineers and owners. See pricing for the pilot terms; the pilot is credited in full against the first year.
FAQ
Does Data Workers replace Antigravity's agents or subagents? No. Antigravity's agents, subagents and Planning mode keep writing the code and the plans. Data Workers adds the data context and carries the approved data change into the warehouse, then verifies and records it.
Which Antigravity surface should a data team use? Any of them reads the same mcp_config.json. For enterprise deployments, Google supports Antigravity 2.0, the Antigravity CLI and the IDE extensions (VS Code and Visual Studio, with JetBrains, Zed and Xcode in preview); the standalone Antigravity IDE is for individual accounts. Data Workers works the same way in each.
We already use the BigQuery server and Google's Data Agent Kit. Why add Data Workers? Keep both. The BigQuery server from the MCP Store lets an agent read schemas and run queries, and the Data Agent Kit starter pack gives agents skills for BigQuery SQL, dbt, Spark and Dataflow pipelines. They make Antigravity's agents better at writing data code. Data Workers adds what sits across systems: lineage from BigQuery through dbt, Composer, Vertex AI and Looker, owners, blast radius before a change, owner approval, rollback and a receipt afterwards.
Can an Antigravity agent change production data on its own? Only within the autonomy level you set for that domain. Antigravity's permission engine gates the tool call, and Data Workers' guardrail gates the change itself. At L2 a named owner approves every change; at L3 only pre-approved, reversible classes run, each with rollback ready and a receipt. Keep data projects off the Turbo preset so write tools always ask.
Can scheduled tasks run Data Workers checks? Yes. A scheduled task sends a prompt to an agent on a timer, so a daily "check freshness and quality on the finance models and summarize anything that needs approval" runs every morning. Read tools run on their Allow rules; anything that changes data still waits for its approval.
How do we keep credentials out of the project? Data Workers uses its own scoped credentials to each platform, so engineers never paste warehouse keys into Antigravity or its config files. Keep mcp_config.json free of secrets and commit only the server entries.
Which data platforms does this work with? Data Workers runs control-plane connectors for BigQuery, Snowflake and Databricks, and reads dbt manifests and runs. For Composer, Looker, Vertex AI and the rest of your stack, Data Workers connects over each tool's API or MCP server today.
Sources
Antigravity capabilities and statuses are current as of October 2, 2026, from Google's own Antigravity documentation: product index (checked 2026-10-02), Antigravity 2.0 overview (successor to the Agent Manager; checked 2026-10-02), features (projects, scheduled tasks, secure by default, Remote Control; checked 2026-10-02), MCP (MCP Store, mcp_config.json locations and properties, authentication, MCP permissions; checked 2026-10-02), permissions and agent settings (Deny, Ask and Allow rules, presets; checked 2026-10-02), artifacts and artifact review (Planning mode, review policy; checked 2026-10-02), Build with Google (Data Agent Kit starter pack; checked 2026-10-02), Remote Control (checked 2026-10-02), rules (checked 2026-10-02), Antigravity in Gemini Enterprise (licenses, supported surfaces, VPC Service Controls, regional endpoints; checked 2026-10-02), plans (checked 2026-10-02), Antigravity IDE overview (checked 2026-10-02), migrating from Gemini CLI (checked 2026-10-02) and the changelog (original launch Nov 18, 2025; Antigravity 2.0 launch fixes May 19, 2026; enterprise sign-in and admin policies for MCP allowlists Jul 31, 2026; new permissions system v2.14.0 Sep 15, 2026; /plan and the Plan Review Policy rename v2.17.0 Sep 22, 2026; v2.19.1 Sep 30, 2026; checked 2026-10-02). Data Workers setup follows the client setup docs and the open-source dataworkers-claw-community repository (start-agent.sh and the agent tool registrations for trace_cross_platform_lineage, blast_radius_analysis, assess_impact, run_quality_check, diagnose_incident, scan_pii, apply_migration and rollback_migration; checked 2026-10-02). Product names and statuses change quickly; if we've got something wrong, tell us and we'll fix it.