You're on Finout: Finout Allocates Every Dollar to the Team That Owns It. Data Workers Owns Whether the Data Behind Those Allocations Is Right
Running Finout, its MCP server and Finout Agents? Keep them. Data Workers checks the telemetry and mapping tables behind every allocation, traces what reads them and sends each fix to its owner, behind approvals.
Your FinOps team lives in Finout. MegaBill puts AWS, Google Cloud, Azure, OCI, Kubernetes, Snowflake, Databricks and your AI providers in one bill. Virtual Tags allocate every line to a team, product or customer without relabelling a resource, and Shared Cost Reallocation splits the shared database, the data transfer and idle Kubernetes capacity by telemetry your teams import each day. CostGuard scans for savings, anomaly detection watches cost and unit economics, and Billy answers in plain language. Since May the Finout MCP server has put it all in Claude, Cursor and your own agents, and in June Finout announced its Detector, Investigator and Orchestrator agents. Finout allocates every dollar to the team that owns it. Data Workers owns whether the data behind those allocations is right: the telemetry tables, ownership mappings and models that decide where each dollar lands, checked, traced and fixed behind approvals.
Key takeaways
- •Finout keeps its job. MegaBill, Virtual Tags, shared-cost reallocation, CostGuard, anomaly detection, Billy, the MCP server and Finout Agents stay with your FinOps team.
- •Data Workers checks the inputs Finout splits the bill on. Key, null and row-count checks in Snowflake plus the metric baselines your team records catch a bad telemetry or mapping table before the showback goes out.
- •It traces what reads a broken table through the dbt manifest and context-graph notes.
- •Fixes go to owners, behind approvals. Model changes are drafted as diffs; rebuilds are queued through your orchestrator after a named person approves; Virtual Tags and telemetry settings stay with the FinOps team.
- •Every fix leaves a receipt with the checks, the approver, the month's AWS Cost Explorer cost by service and the Snowflake credits per dbt model.
- •Start with a pilot on the tables that drive your allocations, read-only first, and climb from L0 manual toward L4 autonomous.
Finout allocates every dollar of cloud and data spend to the team that owns it. Data Workers owns whether the data behind those allocations is right.
Many Finout allocations rest on tables your own teams build: requests per team, an ownership mapping, a unit-economics metric in dbt. When the table is wrong, the allocation is wrong with full precision, and the first to notice is a team lead asking why their showback jumped.
Here is a Tuesday at a marketplace company. Teams own about 480 services in Backstage. A dlt pipeline loads the catalog into Snowflake at 01:00, and Airflow 2 runs the dbt Core project at 02:00. dim_service_owner maps each service to its team, and mrt_requests_by_team_daily joins API gateway requests to it. Finout imports that mart through its Snowflake telemetry integration, and a reallocation Virtual Tag uses it to split a shared Aurora PostgreSQL cluster and inter-zone data transfer across five product teams. A Tableau workbook on engineering unit cost reads the same mart. The team has noted the Finout import and the workbook in the Data Workers context graph, and baselines daily requests in the raw gateway table and in the mart with monitor_metrics. This is an illustrative example.
| Time | System | What happens |
|---|---|---|
| Mon 15:00 | Backstage | A reorg moves 14 services from the Payments team to a new Checkout team. The owners update the catalog the same afternoon |
| Tue 01:00 | dlt and Snowflake | The nightly load runs. The pipeline merges on service and owner together, so each moved service gets a second row with the new owner instead of an updated one |
| 02:00 | Airflow and dbt | The nightly DAG run builds the project and succeeds. dim_service_owner now holds two rows for 14 services, and the join in mrt_requests_by_team_daily counts their requests under both Payments and Checkout |
| 03:00 | Snowflake | Data Workers' scheduled run_quality_check on dim_service_owner fails uniqueness: the distinct ratio of service_id drops to 0.972, below the 0.99 threshold |
| 03:04 | Snowflake | The monitor_metrics baseline on total requests in the mart flags Monday at about 1.23 times its normal level, while the raw gateway baseline sits in its normal range. The extra rows came from the model, not the gateway |
| 03:08 | dbt, Finout, Tableau | blast_radius_analysis on dim_service_owner returns mrt_requests_by_team_daily and mrt_eng_unit_cost_weekly from the manifest; the graph notes add the Finout telemetry import and the Tableau workbook. A Slack card goes to the model owner, the ingestion owner and the FinOps lead, with the failed check, both baselines and the readers |
| 07:40 | Finout | The FinOps lead, a Finout admin, deactivates the telemetry in Finout's settings, which pauses its daily import until the table is right. The weekly showback is held |
| 08:30 | GitHub and dbt | Data Workers drafts the fix as a diff for the model owner: dim_service_owner keeps the latest owner row per service by dlt load, and a dbt unique test on service_id guards it. The card notes for the ingestion owner that the pipeline's primary key should be the service alone |
| 09:15 | Slack and Spellbook | The analytics engineering lead reviews the diff in Spellbook, approves the rebuild and merges. The ingestion owner changes the dlt primary key in the same hour |
| 09:16 | Airflow | Data Workers queues a run of the Airflow 2 DAG that rebuilds dim_service_owner and every model below it |
| 09:55 | Snowflake | The run completes. run_quality_check passes uniqueness on service_id, and total requests in the mart are back within their baseline |
| 10:05 | Finout | The FinOps lead reactivates the telemetry. Finout's next daily import reads the corrected table, and the showback goes out on numbers both teams accept |
| Wed 10:00 | AWS Cost Explorer and Spellbook | The receipt adds the month's cost by service from AWS Cost Explorer for the shared lines the split divides, and the Snowflake credits for the rebuild per dbt model from the query tags. The FinOps lead links the receipt in the showback notes |
Nothing in Finout was wrong. The import ran as configured, and the reallocation would have split the shared cost exactly in proportion to the rows it was given. The bill was right; only the shares would have been wrong. What broke was a join two systems upstream, after a reorg nobody connected to cost. Data Workers caught it from a key check and two baselines, traced the readers, gave the FinOps lead what she needed to pause the import, and closed the loop with a receipt. The context graph keeps the note that this mart drives a Finout reallocation, so the next person who changes it sees what depends on it.
| Job | What Finout does | What Data Workers does |
|---|---|---|
| Cost visibility | MegaBill across clouds, Kubernetes, data platforms, SaaS and AI providers | Reads AWS Cost Explorer monthly cost by service and Snowflake credits per query and dbt model, for the receipt |
| Allocation | Virtual Tags, Dictionary Virtual Tags and shared-cost reallocation by telemetry | Checks the telemetry, mapping and dimension tables those allocations run on |
| Detection | Cost, usage and unit-economics anomalies, routed to Slack, Teams, email or a Jira issue | Key, null and row-count checks in Snowflake plus the metric baselines your team records |
| Investigation | The Investigator agent builds a case file from MegaBill, Virtual Tags and ownership | Traces the broken table to its models, imports and dashboards through the dbt manifest and context-graph notes |
| Driving the fix | The Orchestrator agent routes actions through Jira, Slack and ServiceNow, with approval for destructive ones | Drafts the data-side change as a diff for its owner and queues the rebuild through your orchestrator after approval |
| The proof | Savings and allocation in Finout | A receipt per fix: checks, lineage, approver, cost lines and credits per model |
Why doesn't Finout just do this itself?
Because Finout is built around one question, where each dollar belongs, for every bill a company pays. It reads Snowflake and Databricks through read-only roles. Its telemetry integration asks for SELECT on one KPI table and imports it once a day. Dictionary Virtual Tags validate the file they are given and reject overlapping date ranges. Billy runs read-only and RBAC-scoped, the MCP server sees exactly what the authorizing user sees, and Finout Agents send destructive actions to a person for approval. That restraint is right for a FinOps platform: a product that allocated every bill and also rewrote the dbt models feeding it would carry the liability for every number they produce.
Knowing that the dlt pipeline merges on the wrong key, that dim_service_owner fans out a join, and that one model change plus a rebuild fixes the Finout split and the Tableau workbook together is data-engineering knowledge. Acting on it crosses Snowflake, dbt, Airflow and named owners in other teams, and ends in a receipt auditors accept. Finout is measured on every dollar allocated; the data team is measured on the inputs being right. Data Workers is built for the second job, on top of the FinOps platform you already run.
Every tool owns a slice. Data Workers covers the whole lifecycle
Finout owns its slice: cloud and AI spend allocation, showback and savings. 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 allocation Finout already gives you.
| Stage | Data Workers | Finout | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 5 | MegaBill and Virtual Tags map every cost line to teams, products and customers: rich cost context. Data Workers joins tables, lineage, runs, owners, quality and usage in one graph. |
| Analytics & Insights | 8 | 7 | Dashboards, unit economics and Billy 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 | Finout validates the shape of the files it imports, not whether the rows behind them are right. Data Workers checks keys, nulls, row counts and baselines and takes failures to the cause. |
| Observability & Incidents | 8.5 | 4 | Anomaly detection flags cost, usage and unit-economics moves. Data Workers detects, diagnoses and fixes data incidents across systems, with a receipt for each. |
| Pipelines & Ingestion | 8.5 | 1 | Finout 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 | 1 | Finout sees cost dimensions, 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 | RBAC decides who sees which costs, in the app and over MCP. Data Workers dry-runs grants, applies approved Unity Catalog changes and drafts the rest for their owners. |
| Security & Privacy | 8 | 3 | Finout reads Snowflake and Databricks through read-only roles. Data Workers keeps a receipt for every data change and proposes masking for its owner. |
| Cost / FinOps | 8 | 9.5 | Finout's home stage: MegaBill, Virtual Tags, shared-cost reallocation, CostGuard, anomaly detection, the MCP server and the Detector, Investigator and Orchestrator agents. Data Workers ties Snowflake spend to dbt models and checks the data an allocation runs on. |
| MLOps & Models | 7.5 | 2 | Finout allocates AI provider and GPU spend, not model or feature health. Data Workers keeps the training and feature data under models healthy. |
How Finout and Data Workers work together
Your people stay in Finout, Slack and Claude, Claude Code or Cursor. Spellbook Data Catalog (in preview) is where the data team looks: each finding, diff, approver and rollback; approval requests arrive 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 Finout keeps. Everything above, including Finout Agents, announced on June 4, 2026 and in early access (Finout's docs list the agentic product as Beta). Data Workers connects to Finout over its API or MCP server today. The Finout MCP server, generally available since May 5, 2026, is hosted at https://mcp.finout.io/mcp with OAuth and 21 tools, so your assistant can ask Finout who owns a cost and Data Workers what feeds the allocation. Data Workers' agents don't call Finout's MCP server; their checks rest on what Data Workers reads itself.
What Data Workers reads. AWS Cost Explorer natively: monthly cost by service, with its forecast. With your Snowflake credentials, warehouse metering and per-query attribution from the account usage views; where dbt sets query tags, credits trace to the dbt model. Each action's own model cost is computed from its tokens. Around the bill: the dbt manifest, Snowflake checks through run_quality_check, metrics your team baselines with monitor_metrics, orchestrator runs, Tableau and GitHub pull requests, among 50+ connectors. Agents get one governed view through explain_table, trace_cross_platform_lineage and blast_radius_analysis. Backstage and dlt connect over their APIs or MCP servers today.
What Data Workers changes, and where. Virtual Tags, telemetry settings and showback stay with the FinOps team. dbt changes are drafted as diffs for the model owner to merge, and rebuilds are queued through your orchestrator after a named person approves. Pipeline code changes, such as a dlt primary key, go to the ingestion owner, who also runs any reload. Warehouse settings are drafted for the platform owner to apply, and deletes of tables or rows are always the owner's.
Setup for the open-source agents. Clone the open-source repository and add start-agent.sh entries to your client config, as the client setup docs show. Add the Finout MCP server to the same client by following Finout's documentation.
// Example: .mcp.json for Claude Code
{
"mcpServers": {
"dw-quality": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-quality"]
},
"dw-context-catalog": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-context-catalog"]
}
}
}List the tools with your client's own command (/mcp in Claude Code), then ask "Finout splits our shared database by mrt_requests_by_team_daily. Are its keys clean today, and what else reads it?"
One allocation input, L0 to L4. The ladder is set per domain, so the tables behind finance allocations can sit at a different level from marketing data.
- •L0 manual. Someone notices a showback jump weeks later and reverse-engineers the join.
- •L1 observe. Data Workers checks the telemetry and mapping tables after every build, reports failures with their lineage, and logs what each action would have needed.
- •L2 propose. It drafts the model fix and the rebuild; the owner approves before anything runs.
- •L3 act reversibly. For proven classes, such as downstream rebuilds once a dimension's keys check out again, it queues the step, re-checks and records.
- •L4 autonomous. For a scoped, trusted class in one domain, it runs the loop end to end and posts the receipt. Allocation rules and spend decisions stay with your FinOps team.
More on safety, approvals, autonomy levels, where your data goes, Data Workers on Snowflake and the Cost Savings & Data Cleanup agent. The same pattern holds on You're on Vantage, You're on CloudZero and You're on SELECT; the data side of this incident is on You're on dlt, You're on Airflow and You're on Tableau.
What changes for your team
FinOps teams on Finout lose time between allocating and trusting: the showback dispute that turns out to be a broken join, the reorg that reached the service catalog but not the mapping table. With Data Workers, those jobs run on autopilot at the level you set. The FinOps lead guide and the platform engineer guide cover the people side.
- •Cloud spend. AWS Cost Explorer monthly cost by service and Snowflake credits per dbt model land on every receipt.
- •Data quality. Telemetry and mapping tables are checked after every build, before Finout imports them.
- •Incidents. A broken allocation input arrives traced, with its readers and owners named.
- •Audits. Each fix links the approver, the checks and the cost lines.
- •Access. Grants a fix needs are dry-run first and approved by a named owner.
- •Migrations. Each wave is planned with its checks, and the owner signs off before it closes.
Keep Finout, or consolidate?
Keep Finout if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Finout stays your view of every bill. What teams consolidate is the glue around it: the spreadsheet that sanity-checks telemetry totals before each showback, the ad hoc queries after a reorg, the Slack threads that reconstruct who changed a mapping table and why. 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, FinOps for data engineering and MCP for cost optimization agents.
The case for your CFO
The outcome: every chargeback and showback your FinOps team sends from Finout rests on telemetry and mappings checked the night they were built, with a receipt for every fix. Teams accept their numbers, and allocation disputes stop eating the first week of each month.
The risk story is plain. Data Workers changes nothing in Finout. It checks the data, traces the readers and drafts each data-side fix for its owner; dbt changes merge and rebuilds queue only after a named person approves. Unanswered requests expire and escalate; they never auto-grant. No agent can promote its own work. Autonomy is set per domain from L0 manual to L4 autonomous, an org-wide stop halts all autonomous dispatch, and the admin kill switch takes two people. 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: Finout imports telemetry daily and its agents route fixes to owners, so a bad input reaches more decisions, faster. The first win is the handful of tables behind your allocations, read-only, with checks and receipts. What stays the same: Finout, your allocation model, your dbt project, your orchestrator and your FinOps team. Start with a pilot; the path is on the pricing page, and the pilot is credited in full against the first year. The ROI guide shows the math; the flat-fee explainer covers pricing.
The sentence to repeat upstairs: "Finout tells every team what it spent; Data Workers makes sure the numbers that split the bill are right, with an approver and a receipt."
Getting started
Start with a pilot. List the Snowflake tables Finout imports as telemetry, connect Data Workers read-only to Snowflake, AWS Cost Explorer, the dbt project and your orchestrator, baseline those tables' daily totals, note which tables Finout and your dashboards read, and let it check every build 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 Finout? Data Workers connects to Finout over its API or MCP server today. Your team's assistant can use the Finout MCP server side by side with Data Workers' MCP servers.
Does Data Workers replace Finout Agents? No. The Detector, Investigator and Orchestrator keep finding anomalies, building case files and routing cost actions to owners. Data Workers takes the data side: whether the tables behind an allocation are right, what reads them, and the repair, behind approvals.
Does Data Workers detect cost anomalies or find savings? That is Finout's job, across every provider you pay. Data Workers ties Snowflake spend to the dbt models behind it, reads AWS Cost Explorer monthly cost by service, and checks the data your allocations run on.
How does Data Workers notice a broken telemetry table? From key, null and row-count checks with run_quality_check on Snowflake, plus the baselines your team records with monitor_metrics, such as a telemetry table's daily total. Your dbt tests keep running as before.
What about Databricks and BigQuery costs? Finout covers both, Databricks through read-only system tables. Data Workers sums recent BigQuery job bytes into an account total; its per-model attribution runs on Snowflake query tags.
Does any billing data go to Data Workers? Data Workers reads AWS Cost Explorer and Snowflake's account usage views with your credentials, inside your infrastructure. Your data stays in your systems; the hosted Conductor sees workflow metadata only.
Sources
- •Finout home page (platform, integrations, agents, Billy, FAQ), https://www.finout.io/ (checked Oct 3, 2026)
- •Finout, Introducing Finout's Agents (Jun 4, 2026), https://www.finout.io/blog/introducing-finouts-agents (checked Oct 3, 2026)
- •Finout, The Autonomous Finout Platform (early access), https://www.finout.io/the-autonomous-finout-platform (checked Oct 3, 2026)
- •Finout docs, Agentic Product (Beta), https://docs.finout.io/user-guide/agentic-product-beta (checked Oct 3, 2026)
- •Finout, Introducing Finout's MCP Integration (May 5, 2026), https://www.finout.io/blog/introducing-finouts-mcp-integration (checked Oct 3, 2026)
- •Finout docs, Finout MCP Integration, https://docs.finout.io/ai-and-developer-tools/finout-mcp-integration (checked Oct 3, 2026)
- •Finout docs, Telemetry, https://docs.finout.io/telemetry-integrations/telemetry (checked Oct 3, 2026)
- •Finout docs, Snowflake Telemetry Integration, https://docs.finout.io/telemetry-integrations/telemetry/snowflake-telemetry-integration (checked Oct 3, 2026)
- •Finout docs, Telemetry settings, https://docs.finout.io/settings/telemetry (checked Oct 3, 2026)
- •Finout docs, Virtual Tags, https://docs.finout.io/user-guide/inform/virtual-tags (checked Oct 3, 2026)
- •Finout docs, Dictionary Virtual Tags, https://docs.finout.io/user-guide/inform/virtual-tags/dictionary-virtual-tags (checked Oct 3, 2026)
- •Finout, Introducing Dictionary Virtual Tags (Jul 7, 2026), https://www.finout.io/blog/introducing-dictionary-virtual-tags (checked Oct 3, 2026)
- •Finout docs, Anomalies, https://docs.finout.io/user-guide/optimize/anomalies (checked Oct 3, 2026)
- •Finout Shared Cost, https://www.finout.io/shared-cost (checked Oct 3, 2026)
- •Finout MegaBill, https://www.finout.io/megabill (checked Oct 3, 2026)
- •Finout docs, Connect to Databricks, https://docs.finout.io/billing-integrations/data-and-engineering-platforms/connect-to-databricks (checked Oct 3, 2026)
- •Finout Snowflake solution, https://www.finout.io/finout-snowflake-solution (checked Oct 3, 2026)
- •Finout product news, https://www.finout.io/product-news (checked Oct 3, 2026)
- •Data Workers agent swarm repository: AWS Cost Explorer read, Snowflake metering and query-tag attribution, 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)