You're on Vantage: Vantage Reports and Remediates Cloud Waste. Data Workers Owns Whether the Data That Spend Pays For Is Still Right
Running Vantage and its FinOps Agent? Keep it. Data Workers checks what each cloud saving does to the data downstream, ties Snowflake spend to dbt models and sends every fix to its owner, behind approvals.
Your FinOps team lives in Vantage. Cost Reports and Virtual Tags split AWS, Azure, Google Cloud, Snowflake, Databricks, Kubernetes and AI provider spend by team and product. Budgets, now including usage budgets for tokens, and anomaly alerts flag a jump before the invoice does. Autopilot buys AWS Savings Plans, automatically or behind approval. The FinOps Agent answers questions in the console or Slack, builds reports and Virtual Tags, and, with a human in the loop by default, turns recommendations into fixes: its GitHub integration files an issue against your infrastructure code with the file, the current configuration, the recommended change and the savings, ready for a coding agent or an engineer. Vantage finds the waste and drives the fix. Data Workers owns whether the data that spend pays for is still right afterwards: it checks what a saving did to the loads, models and reports downstream and sends each data-side fix to its owner, behind approvals. The two jobs meet whenever a resource that looks idle turns out to feed a pipeline.
Key takeaways
- •Vantage keeps its job. Cost Reports, Virtual Tags, budgets, anomaly alerts, Autopilot and the FinOps Agent stay with your FinOps and platform teams. Data Workers works with Vantage from day one.
- •Data Workers checks what a saving does to the data. It watches the baselines your team records, checks keys, nulls and row counts in Snowflake, and reads the dbt manifest and orchestrator runs.
- •It traces the readers before anyone rebuilds. dbt manifest lineage and context-graph notes show which marts, reports and syncs sit on a table that stopped loading.
- •Fixes go to owners, behind approvals. Infrastructure stays with the platform owner; dbt changes are drafted as diffs for the model owner; rebuilds are queued through your orchestrator after a named person approves.
- •Every fix leaves a receipt with the checks and the approver, plus the AWS Cost Explorer line by service and the Snowflake credits per dbt model where the fix touches cost.
- •Start with a pilot on one domain, read-only first, and climb from L0 manual toward L4 autonomous.
Vantage reports and remediates cloud waste. Data Workers owns whether the data that spend pays for is still right.
Vantage answers what the cloud costs, who owns each dollar and what to change to spend less. Data Workers answers whether a change kept the data right, who reads it and who signs off on the repair. When a cloud resource quietly feeds a pipeline, a correct cost decision can still empty a table finance reads at 08:00.
Here is a Monday at a B2B software company. Billing runs on PostgreSQL in Amazon RDS. A read replica, billing-replica, lets the nightly Airbyte connection copy invoices into Snowflake raw_billing at 01:00 without touching the primary. Dagster runs the dbt Core project at 02:00: fct_invoices feeds mrt_daily_revenue and mrt_ar_aging. A Hightouch sync writes overdue flags to Salesforce for the collections team at 07:00, and a Mode report on daily cash goes to finance at 08:00. The dbt project sets Snowflake query tags. The team baselines invoice rows loaded per day with monitor_metrics and has recorded the replica, the Mode report and the Hightouch sync as notes in the Data Workers context graph. This is an illustrative example.
| Time | System | What happens |
|---|---|---|
| Mon 10:00 | Vantage | The FinOps Agent's GitHub integration (private preview) files an issue in the infra-terraform repository: billing-replica sits idle 23 hours a day, with the file path, the current instance class, the recommended change (delete the idle replica) and the monthly savings |
| Mon 11:30 | GitHub | The issue is assigned to the GitHub Copilot coding agent, which opens a pull request removing the replica's resource block |
| Mon 16:00 | GitHub and AWS | A platform engineer reviews the plan, merges, and the team's Terraform pipeline deletes the replica. The saving is real |
| Tue 01:00 | Airbyte | The billing connection fails: its source host no longer resolves. Airbyte retries and emails the ingestion owner, who is asleep |
| 02:00 | Dagster and dbt | The nightly job runs dbt build and succeeds. fct_invoices and both marts rebuild on raw tables that hold nothing for Monday |
| 03:05 | Snowflake | Data Workers' monitor_metrics baseline on invoice rows loaded per day flags zero rows for Monday against a weekday baseline near 4,000 |
| 03:10 | dbt, Dagster, context graph | The dbt manifest shows no model change and the Dagster run succeeded, so the gap sits upstream of dbt. The context-graph note on the Airbyte source names billing-replica as its host |
| 03:15 | dbt, Mode, Hightouch | blast_radius_analysis on raw_billing.invoices returns fct_invoices, mrt_daily_revenue and mrt_ar_aging from the manifest; the graph notes add the 07:00 Hightouch sync and the 08:00 Mode report. A Slack card goes to the ingestion owner, the platform owner and the finance data lead |
| 06:40 | Hightouch and Slack | The Hightouch sync owner pauses the 07:00 run, so no account gets a wrong overdue flag. The platform engineer recognises the replica from Monday's merge |
| 07:30 | Slack and Spellbook | Data Workers posts the options in Spellbook with the readers attached: restore the replica as it was, recreate it at a smaller instance class sized for a one-hour nightly read, or move the read to the primary in a quiet window. The platform owner picks the smaller replica and ships it through Terraform |
| 08:50 | Airbyte and Snowflake | The replica is available. The ingestion owner reruns the Airbyte sync and Monday's invoices land. The monitor_metrics baseline is back in range, and run_quality_check on raw_billing.invoices passes uniqueness on invoice_id, so the rerun loaded nothing twice |
| 09:00 | Spellbook | The finance data lead approves the rebuild in Spellbook |
| 09:01 | Dagster | Data Workers queues the Dagster job that rebuilds fct_invoices, mrt_daily_revenue and mrt_ar_aging |
| 09:40 | Snowflake, Mode, Hightouch | The run completes. run_quality_check passes nulls and uniqueness on fct_invoices, and daily revenue is back on its baseline. The sync owner resumes Hightouch, and finance re-sends the Mode report at 09:45 |
| Wed 10:00 | AWS Cost Explorer and Spellbook | The receipt adds last month's Amazon RDS line from AWS Cost Explorer (monthly cost by service) as the before figure for the month-end comparison, and the rebuild's Snowflake credits per dbt model from the query tags. The platform engineer links the receipt from the Vantage issue |
Nothing in Vantage was wrong. The replica really was idle 23 hours a day, the recommendation carried the right file and savings, and a person reviewed the merge. The missing piece was data context: the one busy hour was the hour finance depended on, and no check stood between a successful dbt build and a revenue report built on a missing day. Data Workers caught the gap from the load baseline, traced the readers, got the sync paused before it ran, put the options to the right owners and closed the loop with a receipt. The context graph keeps the note that the replica feeds the billing load, for the next person who asks.
| Job | What Vantage does | What Data Workers does |
|---|---|---|
| Cost visibility | Cost Reports and Virtual Tags across clouds, Snowflake, Databricks, Kubernetes and AI providers | Reads AWS Cost Explorer (monthly cost by service) and Snowflake credits per query and dbt model, for the receipt |
| Finding the saving | Recommendations, anomaly alerts and the FinOps Agent's investigations | Takes the change your team ships and checks what it did to the data |
| Driving the fix | GitHub issues against infrastructure code, ready for a coding agent or an engineer; Autopilot for Savings Plans | Drafts the data-side change (a dbt model, a schedule, a warehouse setting) as a diff for its owner |
| Detection | Budgets and alerts on spend | Load and metric baselines, plus key, null and row-count checks in Snowflake |
| Impact | Shows which team owns the cost | Traces marts, reports and syncs through the dbt manifest and context-graph notes |
| Recovery | Logs the agent's actions in the Vantage Audit Log | Queues the rebuild through your orchestrator after approval, then re-checks |
| The proof | Savings realized | A receipt per fix: checks, lineage, approver, cloud line and credits per model |
Why doesn't Vantage just do this itself?
Because Vantage is built around one unit of work, a cloud resource and what it costs, across every provider a company pays. It reads Snowflake through a read-only user. Its FinOps Agent keeps a human in the loop by default and logs its actions to the Vantage Audit Log. By Vantage's own description, the agent's GitHub connector can create issues but cannot open pull requests; the merge stays with your engineers and their coding agents. That restraint is right for a cost platform: one that also rewrote data pipelines would carry the liability for every number they feed.
Knowing that billing-replica is busy one hour a night for Airbyte, that three dbt models, a Mode report and a Hightouch sync sit downstream, and that a smaller replica keeps most of the saving, is data-engineering knowledge. Acting on it crosses ingestion, the warehouse, dbt, the orchestrator and BI, each owned by someone else. A cost platform is measured on dollars saved; the data team is measured on the number being right. Data Workers is built for the second job, on top of the cost platform you already run.
Every tool owns a slice. Data Workers covers the whole lifecycle
Vantage owns its slice: multi-cloud cost visibility, allocation and remediation. 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, and builds on the cost view Vantage already gives you.
| Stage | Data Workers | Vantage | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 6 | Vantage maps spend to teams, products and resources across providers with Virtual Tags: rich cost context. Data Workers joins tables, lineage, runs, owners, quality and usage in one graph. |
| Analytics & Insights | 8 | 7 | Cost Reports, dashboards and the FinOps Agent explain the bill in plain language. Data Workers answers questions about the data itself from governed context and checks the numbers behind them. |
| Data Quality | 8 | 1 | Vantage measures what resources cost, not whether rows are right. Data Workers checks keys, nulls, row counts and baselines and takes failures to the cause. |
| Observability & Incidents | 8.5 | 4 | Anomaly alerts and budgets flag spend that moves. Data Workers detects, diagnoses and fixes data incidents across systems, with a receipt for each. |
| Pipelines & Ingestion | 8.5 | 2 | Vantage prices the infrastructure pipelines run on. Data Workers reads orchestrator runs, queues reruns after approval and reviews pipeline changes before they merge. |
| Schema & Migration | 8 | 2 | Vantage sees resources, not schemas or models. Data Workers reviews model changes from the dbt manifest, assesses impact and plans migrations in approved waves. |
| Governance & Access | 8.5 | 3 | Roles and teams govern who sees which costs. Data Workers dry-runs grants, applies approved Unity Catalog changes and drafts the rest for their owners. |
| Security & Privacy | 8 | 3 | Vantage reads Snowflake through a read-only user and billing through provider integrations. Data Workers keeps a receipt for every data change and proposes masking for its owner. |
| Cost / FinOps | 8 | 9.5 | Vantage's home stage: multi-cloud allocation, budgets, anomaly alerts, Autopilot for Savings Plans and the FinOps Agent with GitHub issues. Data Workers ties Snowflake spend to dbt models and checks the data a saving touches. |
| MLOps & Models | 7.5 | 2 | Vantage tracks AI provider and GPU spend, not model or feature health. Data Workers keeps the training and feature data under models healthy. |
How Vantage and Data Workers work together
Your people stay in Vantage, in Slack and in Claude, Claude Code or Cursor. Spellbook Data Catalog (in preview) is where the data team looks: each finding, diff, approver and rollback, with approval requests in Slack or email. Underneath, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm (20+ specialist agents) does the work, and the Autonomous Data-Conductor runs each fix behind per-domain guardrails.
What Vantage keeps. Cost Reports, Virtual Tags, budgets, anomaly alerts, recommendations, Autopilot and the FinOps Agent with its MCP connectors (Datadog, GitHub, Linear, Notion). Vantage is also listed in the Databricks MCP Catalog. Data Workers connects to Vantage over its API or MCP server today. The Vantage MCP server runs remote, hosted by Vantage with OAuth, or self-hosted from open source, so your team's assistant can ask Vantage what a resource costs and Data Workers what depends on it in one session. Data Workers' agents don't call Vantage's MCP server; their checks rest on what Data Workers reads itself.
What Data Workers reads. It reads AWS Cost Explorer natively: monthly cost by service, with the forecast. With your Snowflake credentials the Cost Savings & Data Cleanup agent reads warehouse metering and per-query attribution from Snowflake's account usage views and decodes the dbt node, project and run from the query tag, so credits trace to the dbt model wherever dbt sets query tags. On BigQuery it sums recent job bytes into an account-level total. Each action's model cost is computed from its tokens. Around the bill it reads the dbt manifest, Snowflake checks through run_quality_check, monitor_metrics baselines and orchestrator runs on Airflow, Dagster, Prefect and ADF, among 50+ connectors. Agents get one governed view through explain_table, trace_cross_platform_lineage and blast_radius_analysis. Airbyte, Mode and Hightouch connect over their APIs or MCP servers today.
What Data Workers changes. Infrastructure stays with the platform owner and the Vantage issue queue. dbt changes and warehouse settings are drafted as diffs for their owners. Rebuilds are queued through your orchestrator after a named person approves. Ingestion syncs are rerun by their owners, and deletes of tables or rows are always the owner's.
Setup. Clone the open-source repository and add start-agent.sh entries to your client config, as the client setup docs show. Add the Vantage MCP server to the same client per Vantage's documentation.
// Example: .mcp.json for Claude Code
{
"mcpServers": {
"dw-incidents": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-incidents"]
},
"dw-context-catalog": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-context-catalog"]
},
"dw-quality": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-quality"]
}
}
}List the tools with /mcp in Claude Code, then ask "Vantage wants to delete billing-replica. What loads from it, and what reads those tables?"
One saving, L0 to L4. The ladder is set per domain, so billing data can sit at a different level from marketing data.
- •L0 manual. Someone merges the saving and hopes a stakeholder notices if a report goes blank.
- •L1 observe. Data Workers watches the baselines while savings ship, reports gaps with their lineage, and logs what each action would have needed.
- •L2 propose. It drafts the data-side fix and the rebuild; the owner approves before anything runs.
- •L3 act reversibly. For proven classes, such as rebuilding marts once a missing load is back and its keys check out, it queues the step, re-checks and records.
- •L4 autonomous. For a scoped class in one domain, it runs the loop end to end and posts the receipt. Spend decisions, Vantage settings and infrastructure stay with your FinOps and platform teams.
More on safety, approvals, who owns the agents, autonomy levels, where your data goes, integrations, Data Workers on AWS and on Snowflake. Siblings: CloudZero, SELECT, Keebo, and for this incident's data side Airbyte, Dagster and Hightouch.
What changes for your team
FinOps teams lose time at the seam between saving and trusting: the recommendation nobody merges because nobody can say what it feeds, the saving that blanked a report. With Data Workers, those jobs run on autopilot at the level you set.
- •Cloud spend. The AWS Cost Explorer line by service and Snowflake credits per dbt model sit on the receipt, next to the checks.
- •Incidents. A saving that breaks a load arrives traced, with its readers and owners named.
- •Data quality. Loads and models are checked against baselines, keys and row counts.
- •Audits. Each fix links the approver, the checks and the cost record.
- •Migrations. Each wave is planned with its checks; the owner signs off before it closes.
- •Access. Grants a fix needs are dry-run first and approved by a named owner.
Platform engineers merge more of Vantage's recommendations, because they can ask what a resource feeds before they merge and the baselines watch the data after. The FinOps lead guide and the platform engineer guide cover the people side.
Keep Vantage, or consolidate?
Keep Vantage if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Nothing here replaces Vantage's allocation, Autopilot or FinOps Agent. What teams consolidate is the glue around it: recommendations held back because nobody could trace their dependencies, ad hoc checks after an infrastructure change, and Slack threads reconstructing who approved a saving. Building it yourself? Calling an MCP server is the easy part; the checks, lineage, approvals and receipts are the work. See also FinOps for data platforms and MCP for cost optimization agents.
The case for your CFO
The outcome: every cloud saving your team ships through Vantage comes with proof that the data it touched is still right, so you keep cutting spend without putting the revenue report or the collections queue at risk.
The risk story is plain. Data Workers changes nothing in Vantage and runs no infrastructure changes. It reads AWS Cost Explorer and Snowflake metering, checks the data, traces the readers and drafts each data-side fix for its owner; rebuilds are queued through your orchestrator after a named person approves. Unanswered requests expire and escalate, never auto-grant. No agent can promote its own work. An org-wide stop halts all autonomous dispatch. The agents run in your infrastructure with your credentials; your data stays in your systems, and the hosted Conductor sees workflow metadata only. Zero migration.
Why now: cost platforms are moving from telling to doing. Vantage's agent already files infrastructure fixes for coding agents, and the more your team merges, the more often a saving lands on a pipeline. The first win is one domain, read-only, with baselines on the tables finance reads. Vantage, Terraform, dbt, your orchestrator and your FinOps team stay as they are. The ROI guide shows the math, the model cost guide covers what the agents cost to run, and the flat-fee explainer covers pricing without a usage meter.
The sentence to repeat upstairs: "Vantage tells us where to save; Data Workers proves the data still adds up after we do, with an approver and a receipt for every change."
Getting started
Start with a pilot. Pick the domain where a missing day costs the most, such as billing on Snowflake, connect Data Workers read-only to Snowflake, AWS Cost Explorer, the dbt project and your orchestrator, baseline the loads finance relies on, note which infrastructure feeds them, and let the baselines watch while savings ship before turning on the first fix class. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
Does Data Workers connect to Vantage? Over its API or MCP server today. Your team's assistant can use the Vantage MCP server side by side with Data Workers' MCP servers. Data Workers reads AWS Cost Explorer and Snowflake metering natively with your credentials.
Does Data Workers replace Vantage's FinOps Agent? No. The FinOps Agent keeps investigating spend and turning recommendations into fixes, with a human in the loop by default or autonomously if you enable it. Data Workers takes the data side: what a change feeds, whether the data is still right, and the repair, behind approvals.
Does Data Workers find idle resources or estimate savings? That is Vantage's job, across every provider you pay. Data Workers ties Snowflake spend to the dbt models behind it, reads AWS Cost Explorer by service, and checks the data a saving touches.
Does Data Workers delete or resize cloud resources? No. Infrastructure stays with the platform owner and your Terraform workflow. A warehouse setting a fix needs is drafted for the owner to apply.
How does Data Workers notice a missing load? From the baselines your team records with monitor_metrics, such as rows loaded per day, plus key, null and row-count checks with run_quality_check on Snowflake. Your dbt tests keep running as before.
What about Databricks and BigQuery costs? Vantage covers both. Data Workers sums recent BigQuery job bytes into an account total; its per-model attribution is for Snowflake, built on dbt query tags.
Sources
- •Vantage home page (products, integrations), https://www.vantage.sh/ (checked Oct 3, 2026)
- •Vantage FinOps Agent feature page, https://www.vantage.sh/features/vantage-finops-agent (checked Oct 3, 2026)
- •Vantage, FinOps Agent in the console for all customers (May 5, 2026), https://www.vantage.sh/blog/finops-agent-console (checked Oct 3, 2026)
- •Vantage, GitHub integration for the FinOps Agent, private preview (Apr 2, 2026), https://www.vantage.sh/blog/github-finops-agent-preview (checked Oct 3, 2026)
- •Vantage, MCP connectors for Linear, Notion and GitHub (Aug 27, 2026), https://www.vantage.sh/blog/linear-notion-github-mcp (checked Oct 3, 2026)
- •Vantage, Remote MCP server (Jul 24, 2025), https://www.vantage.sh/blog/remote-mcp (checked Oct 3, 2026)
- •Vantage MCP documentation, https://docs.vantage.sh/vantage_mcp (checked Oct 3, 2026)
- •Vantage, Databricks MCP Catalog listing (Nov 6, 2025), https://www.vantage.sh/blog/databricks-mcp (checked Oct 3, 2026)
- •Vantage Autopilot for AWS Savings Plans, https://www.vantage.sh/features/autopilot (checked Oct 3, 2026)
- •Vantage Snowflake integration, https://www.vantage.sh/integrations/snowflake (checked Oct 3, 2026)
- •Vantage, Usage Budgets (Sep 22, 2026), https://www.vantage.sh/blog/usage-budgets (checked Oct 3, 2026)
- •Vantage, native Business Metrics imports for BigQuery and ClickHouse (Sep 17, 2026), https://www.vantage.sh/blog/gcp-bigquery-clickhouse-business-metrics (checked Oct 3, 2026)
- •Data Workers agent swarm repository (origin/main): AWS Cost Explorer read (GetCostAndUsage, monthly granularity, grouped by service; forecast), Snowflake metering and query-tag attribution (QUERY_ATTRIBUTION_HISTORY joined to QUERY_HISTORY), quality checks, baselines, lineage, approvals (checked Oct 3, 2026)
- •Data Workers client setup docs, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)