Data Workers for FinOps leads
What Data Workers changes for a FinOps lead: Snowflake spend attributed down to the query and dbt model, the cause and a proposed fix sent to the owner with a receipt, and no usage meter or markup on model spend.
For a FinOps lead, Data Workers turns data platform spend from a warehouse line on the bill into a cause with an owner: its agents attribute Snowflake credits down to the query and the dbt model behind them, trace who consumes that model, and send the owner a proposed fix with a receipt. You stop chasing the data team for answers and start reviewing changes that are already drafted, while targets, commitments and trade-offs stay your call.
Key takeaways
- •Spend with a name on it. Snowflake credits are attributed per query and carried down to the dbt model, project and run through query tags, so showback for data spend stops being a monthly spreadsheet.
- •The fix goes to the owner, drafted. When a model drives a spike, Data Workers traces its consumers and proposes the change as a diff for the model owner to merge. Nothing in your warehouse changes without an approval.
- •Guardrails before the bill. The agents draft cost-safe warehouse defaults (x-small, 60-second auto-suspend, a resource monitor with a credit quota) for the platform owner to add to the template.
- •Agent spend is visible and capped. The model cost of each agent action sits next to the warehouse cost of that action, and a session scan budget refuses further scans once the cap is reached.
- •No usage meter, no markup on model spend. You bring your own model key and your provider bills you directly. The platform fee is flat, so automating more next quarter does not change it.
A FinOps lead's week today
The State of FinOps 2026 (FinOps Foundation; 1,192 respondents, $83bn+ in annual cloud spend) describes the job well: workload optimization and waste reduction remain the top current priority, FinOps for AI is the top forward-looking priority, and 98% now manage AI spend. 78% of FinOps teams report to the CTO or CIO, and many organizations are asked to self-fund AI investments through optimization savings.
The week spans the FinOps Framework's four domains: understand usage and cost, quantify business value, optimize usage and cost, and manage the practice. Monday is allocation and tagging. Tuesday a spike lands: Snowflake's cost anomaly detection (generally available since December 2025) flags daily consumption above the expected range, or a Databricks budget threshold emails the team. The cloud bill shows the warehouse, not the workload. So a ticket goes to the data team and waits behind incidents. Wednesday is commitments and forecasting, Thursday showback (data platform spend is the hardest line to split), Friday the optimization backlog nobody has had time to apply.
Snowflake, Databricks and BigQuery ship native cost views, budgets and controls. Vantage, CloudZero, Finout and IBM Cloudability allocate cloud, SaaS and AI spend, detect anomalies and track unit economics, and several now ship agents: Vantage a FinOps Agent and an MCP server, Finout agents that propose rightsizing and commitment changes through your approval flow. SELECT attributes Snowflake spend to dbt models and automates warehouse savings. The step they leave to the data team is the change inside the data platform: tracing who reads the expensive model and drafting the fix for its owner. That is where the chasing happens.
The same week with Data Workers
The Cost Savings & Data Cleanup Agent reads metering at the source. On Snowflake it reads warehouse metering history and per-query attribution history, prices credits at list or contracted rates, and decodes dbt query tags into the model, project and invocation behind each query. On BigQuery it sums bytes processed from the Jobs API into an account total. AWS Cost Explorer is a native read for cost by service and the forecast. Ask it from Claude, ChatGPT Enterprise, Cursor or Spellbook (in preview) which workload drove a spike, and the answer names the queries, the warehouse and the dbt model.
trace_cross_platform_lineage walks the lineage graph downstream from the expensive model to the tables, jobs and dashboards that read it, so the owner sees what a change would affect. The fix is proposed as a diff for the owner to merge. A ticket opens through create_jira_sm_ticket or create_servicenow_ticket with the receipt linked. Data cleanups, such as removing duplicate or bad rows, are proposed for the owner to approve and apply, so every delete passes through the person accountable for the data.
What you still own and decide.
- •Targets and trade-offs. Budgets, unit economics targets, commitments and rate optimization stay with you and your FinOps platform, by design. Data Workers works the data platform slice.
- •The level each domain runs at. L0 manual, L1 observe, L2 propose, L3 act reversibly, L4 autonomous, set per domain. We recommend running cost changes at L2 propose. Autonomy levels L0 to L4 explains each rung.
- •Who approves. Approvals go to a named person, usually the model or warehouse owner. An unanswered request expires and escalates; it never auto-grants. How approvals work and who owns the agents set out the split.
- •The agents' own budget. You set the session scan cap and choose the model the agents run on.
How Data Workers fits the tools you use
Keep your FinOps platform and the native consoles: Snowflake's anomaly emails, Databricks budgets, BigQuery's maximum bytes billed and custom quotas. Data Workers turns their alert into an attributed cause, a traced blast radius and a drafted fix for the owner.
You reach it from an AI assistant or coding agent over MCP (setup at client setup), from Spellbook, where you approve, send back or roll back agent work with the receipt behind every item, and through the tickets your data team already works. On Snowflake, Data Workers on Snowflake covers the fit in depth; Data Workers and dbt covers the model side; the integrations page lists the 50+ connectors.
The agents run in your infrastructure on every tier, holding your warehouse credentials and model key. Your data stays in your systems; the hosted Conductor sees workflow metadata only (where does our data go?).
The metrics you are judged on
You are measured on savings realized, allocation coverage, unit economics and, now, AI spend visibility. Data Workers moves the data platform slice.
| Metric | How Data Workers moves it | Where the number comes from |
|---|---|---|
| Allocation coverage | Snowflake credits split per query and per dbt model, with chargeback keys | Per-query attribution, dbt query tags |
| Savings realized | Fixes arrive drafted for the owner, so recommendations ship instead of aging | Approved diffs and their receipts; credits before and after |
| Time from spike to cause | The question returns queries, warehouse, model and consumers | Time from alert to attributed cause in the receipt |
| AI spend visibility | Model cost per agent action next to warehouse cost; scan budget caps | Token counts at published model prices; session budget state |
| Spend at provision time | Cost-safe warehouse defaults drafted for the template | Resource monitors and auto-suspend in the template |
The 25 to 40% lower warehouse spend in the ROI calculator is a design target; baseline on day one of the pilot from your own bill. How to measure AI data agents sets out the scorecard and the ROI of agentic data operations shows the arithmetic. Our guides to FinOps for data platforms and FinOps for data engineering go deeper.
A worked example: one Snowflake spike, two days, one approval
This is an illustration, not a customer case. A FinOps lead covers a company on Snowflake, dbt and Looker, with Jira for the data team's tickets. Cost work runs at L2 propose.
| Time | Who | What happened |
|---|---|---|
| Tue 08:10 | Snowflake | Native cost anomaly email: daily credits above the expected range |
| Tue 08:40 | FinOps lead | Asks Data Workers in Claude which workload drove the spike |
| Tue 08:55 | Data Workers | Attributes the rise to one dbt model moved to an X-Large warehouse by a config change last Friday |
| Tue 09:20 | Data Workers | Traces consumers: one downstream model and two Looker dashboards that refresh daily |
| Tue 09:40 | Data Workers | Drafts the change (model back on TRANSFORM_WH) as a diff and opens a Jira ticket |
| Tue 09:45 | Jira | Ticket links the receipt: cost by query, consumers, diff |
| Tue 14:30 | Model owner | Reviews the diff and merges it |
| Wed 10:00 | Data Workers | Drafts cost-safe defaults for the warehouse template: x-small, 60-second auto-suspend, a resource monitor with a daily credit quota |
| Wed 11:15 | Platform owner | Adds the defaults to the template |
| Thu 09:00 | Data Workers | Attribution shows the model's credits back to their prior range |
No chase email: the owner saw cause, consumers and change in one place, and the receipt went into showback. The first 90 days shows the path from observe-only.
The case for your CFO
The outcome: data platform spend gets the same accountability as the rest of the cloud bill. Every spike arrives with its cause and its owner, and the fix ships behind an approval.
The risk story is control. Agents start at L1 observe. Cost changes run at L2 propose: the agent drafts, a named owner approves, and every change is recorded with the diff, who approved it, the downstream consumers and the way back. Nothing migrates; Snowflake, dbt, your BI and your FinOps platform all stay. The open-source core is Apache 2.0.
Why now: 57% of data teams report rising warehouse and compute spend against 36% reporting rising budgets (dbt Labs 2026), and you are being asked to fund AI from optimization savings. The first win is your most expensive Snowflake workload, attributed and fixed inside the pilot.
The cost is flat and has no meter. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter, no markup on model spend and your own model (why there is no usage meter; pricing). The sentence for finance: "Data spend now arrives with a cause and an owner, and the tool that finds it has no meter of its own."
FAQ
Will the agents add AI spend we can't see? No. You bring your own model key, your provider bills you directly, and Data Workers adds no markup or metering. The model cost of each agent action is reported from its token counts, and a session scan budget refuses further warehouse scans once your cap is reached.
Does Data Workers resize or suspend our warehouses? It drafts the settings and the owner applies them. Warehouse defaults, sizing and schedule changes go to the platform or model owner as a proposal with a receipt.
We already pay for a FinOps platform. Why add this? Keep it. It allocates spend, detects anomalies and manages commitments across clouds. Data Workers works inside the data platform: it reads the dbt project and lineage, finds the model behind the credits and drafts the fix for its owner.
How deep does attribution go on each warehouse? On Snowflake, down to the query and the dbt model, project and run through query tags. On BigQuery, the account total from the Jobs API. AWS Cost Explorer adds cost by service and the forecast.
Who acts on the recommendations? The owner, named on each approval. Unanswered requests expire and escalate; they never auto-grant.
For your peers, see Data Workers for VPs and heads of data and for CIOs and CTOs, and what an agentic data platform is. Before you approve the first change, is it safe to let AI agents change production data? covers the controls, and build it ourselves prices the alternative.
Sources
- •FinOps Foundation, State of FinOps 2026: https://data.finops.org/ (checked Oct 2, 2026)
- •FinOps Foundation, FinOps Framework (four domains, capabilities, phases; "2026 Framework Updates" posted Mar 20, 2026): https://www.finops.org/framework/ (checked Oct 2, 2026)
- •dbt Labs, 2026 State of Analytics Engineering Report: https://www.getdbt.com/resources/state-of-analytics-engineering-2026 (checked Oct 2, 2026)
- •Snowflake, cost anomalies (account- and organization-level detection; anomaly monitors in preview): https://docs.snowflake.com/en/user-guide/cost-anomalies ; "Dec 10, 2025: Cost anomalies (General availability)": https://docs.snowflake.com/en/release-notes/feature-releases-2025 (checked Oct 2, 2026)
- •Databricks, budgets: https://docs.databricks.com/aws/en/admin/account-settings/budgets (checked Oct 2, 2026)
- •Google Cloud, BigQuery cost best practices: https://docs.cloud.google.com/bigquery/docs/best-practices-costs (checked Oct 2, 2026)
- •Vantage (FinOps Agent, MCP): https://www.vantage.sh/ ; CloudZero: https://www.cloudzero.com/ ; Finout (Detector, Investigator and Orchestration agents): https://www.finout.io/ ; SELECT and its dbt integration: https://select.dev/ , https://select.dev/docs/reference/integrations/dbt ; IBM Cloudability: https://www.apptio.com/products/cloudability/ (checked Oct 2, 2026)
- •Data Workers public repository tools (
trace_cross_platform_lineage,create_jira_sm_ticket,create_servicenow_ticket): https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 2, 2026) - •Data Workers product repository,
data-workers-agent-swarmmain @ 0c2491e3: Snowflake metering and per-query attribution with dbt metadata, BigQuery job history, AWS Cost Explorer reads, provision guardrails, session scan budget, approvals and escalation (checked Oct 2, 2026) - •Data Workers product and pricing pages: https://dataworkers.io/product/data-agents-swarm/ , https://dataworkers.io/pricing/ , https://dataworkers.io/roi-calculator/ (checked Oct 2, 2026)