You're on Espresso AI: It Routes Every Query. Data Workers Keeps the Data and the Cost Trail Right
Espresso AI routes and schedules Snowflake queries to cut spend. Data Workers checks the data and the cost trail behind every routed query, behind approvals.
Your platform team put Espresso AI in front of Snowflake so nobody hand-tunes warehouses again. Your tools now connect to <host>.espressocomputing.com instead of snowflakecomputing.com, and Espresso's agents work on every query that passes through. The Autoscaling Agent scales each workload on its own models. The Scheduling Agent, which Espresso calls Kubernetes for Snowflake, decides in real time which warehouse each query runs on instead of sending it to a fixed one. The Query Agent, in private preview, rewrites SQL with LLMs and checks each rewrite with formal verification. Since October 29, 2025 the same agents run on Databricks SQL, and a Spark optimizer right-sizes Databricks jobs. You turned optimization on per warehouse in the Espresso dashboard, and you pay a share of what it saves. Espresso AI is the query router. Data Workers is the keeper of the data and the cost trail behind every routed query: it checks that the models, marts and reports built on routed work are still right, and drafts the fix for a named owner when they are not.
Espresso's proxy passes your data through without inspecting or storing it, and its models train on metadata. That is a sound design for a performance layer, and it is why someone else owns the other half of the question: when a query ran somewhere new, is every number built on top of it still right?
Key takeaways
- •Espresso keeps its job. Scaling, routing and SQL optimization stay with Espresso. Data Workers never reroutes a query, resizes a warehouse or rewrites SQL.
- •Routed work gets a data check. Data Workers keeps baselines on the marts built from routed work, reads the orchestrator run and traces the models and noted reports downstream.
- •The cost trail follows the query. Where dbt sets query tags, Data Workers traces Snowflake credits to the query and the dbt model behind them, on whichever warehouse Espresso chose.
- •Fixes go to their owners, drafted. The model change goes to its owner as a diff; the rerun is queued through your orchestrator after approval.
- •Autonomy per domain, from L0 manual to L4 autonomous, at the pace your team sets.
Espresso AI is the query router. Data Workers is the keeper of the data and the cost trail behind every routed query.
Here is a month-end with both in place, across Espresso AI, Snowflake, Airflow, dbt Core, Power BI and NetSuite. This is an illustrative example. The FinOps team built its own Snowflake chargeback in dbt: fct_snowflake_chargeback reads Snowflake's warehouse metering history and maps each warehouse to a cost center with a CASE on the warehouse name, with an ELSE branch that sends anything unknown to platform-shared. Finance posts the month's chargeback to NetSuite from a Power BI report.
| Time | System | What happens |
|---|---|---|
| Mon 10:00 | Espresso AI | The platform owner turns on the Scheduling Agent for MARKETING_WH and FINANCE_WH. Both dbt Core projects already connect through the Espresso proxy |
| Mon to Wed | Snowflake | Espresso routes many of those queries to pool warehouses such as _ESPRESSO_POOL_XS_1. Each carries Espresso's metadata comment naming the warehouse it was sent to and the one it ran on. Snowflake records each query, with its dbt query tag, under the pool warehouse |
| Thu 05:00 | Airflow | The finops_daily DAG run starts dbt build for the chargeback models, which rebuild the month to date |
| 05:20 | dbt Core | The pool warehouses match no branch of the CASE. Their credits fall to platform-shared. From Monday on, marketing and finance analytics show a fraction of their usual daily charge |
| 05:25 | Snowflake | run_quality_check on the mart passes: no null cost centers, a unique chargeback_id, above the minimum row count. Every row is valid; the allocation is wrong |
| 06:10 | Data Workers | The day's credits per cost center, recorded to monitor_metrics after the build, flag marketing and finance far below their baselines and platform-shared several times above. The daily total stays on its baseline: the credits moved buckets, they did not disappear |
| 06:16 | Snowflake | Data Workers' per-query attribution, through the dbt query tags, shows the marketing_dbt and finance_dbt projects consuming close to their usual credits, a little lower since Monday (the Espresso saving), on _ESPRESSO_POOL_ warehouses |
| 06:20 | dbt, Power BI, NetSuite | blast_radius_analysis on fct_snowflake_chargeback returns mrt_chargeback_monthly from the dbt manifest. Context-graph notes add the Power BI Snowflake Chargeback report and the September journal finance posts in NetSuite on Friday |
| 06:24 | Slack, Spellbook | A card goes to the FinOps lead and the model owner: hold the report, with the diagnosis and a drafted change waiting in Spellbook |
| 06:40 | GitHub, dbt | The draft, as a diff for the model owner: read routed credits from the attributed metering Espresso publishes, which rolls each routed query's credits back to the warehouse it was sent to, so nothing counts twice; a singular dbt test fails the build when platform-shared holds more than a set share of a day's credits |
| 09:05 | Spellbook | The analytics engineering lead reviews the diff, approves the rebuild and merges |
| 09:07 | Airflow | Data Workers queues the approved finops_daily run with trigger_airflow_dag |
| 09:50 | Snowflake | The run completes. run_quality_check passes; the cost-center baselines are back in range and the daily total is unchanged |
| 10:30 | Power BI | The report owner refreshes the semantic model and the FinOps lead releases the hold |
| Fri 09:00 | NetSuite, Spellbook | Finance posts the September chargeback from the corrected report. Once Snowflake's usage views catch up, the receipt adds the rebuild's credits, traced through the dbt query tag |
Espresso did exactly what it promised: the same work on fewer idle warehouses, plus an attribution output built for this case. It could not know that one dbt model still treated a warehouse name as a team. That data problem was found, fixed and verified before finance posted the month, approved by the model's owner.
| Job | What Espresso AI does | What Data Workers does |
|---|---|---|
| Where queries run | Routes each query in real time to the warehouse that can take it, within latency constraints | Traces what a routing change touches: the models, marts and reports built on that work |
| Scaling | Scales each workload on its own models | Drafts a warehouse setting for the platform owner when the data needs one |
| SQL | The Query Agent (private preview) rewrites queries with formal verification | Checks the tables the work produces and keeps baselines on the metrics the team records |
| Cost attribution | Rolls routed credits back to the warehouse each query was sent to | Traces Snowflake credits to the query and dbt model through query tags, on any warehouse |
| The fix | Optimization on or off per warehouse | Proposes the model change as a diff with its blast radius and queues the rerun after the owner approves |
| The record | The Espresso dashboard and its savings | A receipt: cause, approver, what it touched, how it was verified, its model cost |
Why doesn't Espresso AI just do this itself?
Because Espresso made a sharp design choice. It is a performance layer in the query path, and security teams approve it because data passes through the proxy without being inspected or stored, the proxy can be self-hosted, and a self-hosted proxy can run without sending query text. Its scheduler is trained to cut Snowflake cost subject to latency constraints, and its Query Agent proves each rewrite equivalent to the original. Those are the right goals for deciding where and how a query runs.
The data side needs a different posture. To know the chargeback mart is wrong while every row in it is valid, you keep baselines on the numbers themselves. To know finance posts that mart to NetSuite on Friday, you need dbt lineage and notes on who reads what. To fix it, you need the model's owner, an approval, a rerun through the orchestrator and a check afterwards, with a receipt. A query router that also edited your dbt models would answer for every number they feed. That is a different product, and it is the one Data Workers is.
Every tool owns a slice. Data Workers covers the whole lifecycle
Espresso owns query routing and warehouse scheduling and owns it well. Each point tool adds another console, another contract and another handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail, and builds on Espresso where it already runs.
| Stage | Data Workers | Espresso AI | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 3 | Reads Snowflake workload metadata to model queries and warehouses; no catalog of tables, owners or definitions. Data Workers keeps one governed context graph of definitions, owners and lineage. |
| Analytics & Insights | 8 | 4 | The dashboard (offered free as Snowflake observability since Feb 2026) shows workload latency, savings and routing. Data Workers answers data questions from governed definitions. |
| Data Quality | 8 | 1 | Never inspects result data by design. Data Workers runs checks on the tables and keeps baselines on the metrics the team records. |
| Observability & Incidents | 8.5 | 3 | Routes around latency constraints. Data Workers turns a wrong number downstream of a routing change into a diagnosed incident with a fix and a receipt. |
| Pipelines & Ingestion | 8.5 | 1 | Decides where each query runs and leaves the pipeline alone. Data Workers reads the orchestrator run and queues the approved rerun. |
| Schema & Migration | 8 | 1 | The Query Agent (private preview) rewrites SQL with formal verification; it does not change tables or models. Data Workers reads dbt manifest changes and scores their blast radius. |
| Governance & Access | 8.5 | 2 | Scheduler onboarding grants warehouse usage; dashboard and API keys control who changes settings. Data Workers routes every data change to a named owner, with expiry and escalation. |
| Security & Privacy | 8 | 2 | The proxy never inspects or stores data, can be self-hosted and can run without query text. Data Workers keeps a receipt on every data change. |
| Cost / FinOps | 8 | 9 | Espresso's home stage: autoscaling, real-time query routing and SQL optimization on Snowflake, plus Databricks SQL and Spark jobs. Data Workers traces Snowflake credits to the query and dbt model and drafts the fix for its owner. |
| MLOps & Models | 7.5 | 1 | No model or feature work. Data Workers keeps the tables under your models checked. |
Espresso leads where it should. Directional scores of scope, not benchmarks. For Data Workers on the warehouse itself, read Data Workers on Snowflake.
How Espresso AI and Data Workers work together
People ask questions in Claude Code or another MCP client and get approval requests in Slack. Spellbook Data Catalog (in preview) is where the data team looks: each proposed change, who approved it and how to roll it back. Underneath, Data Context Wizard keeps one governed context graph across Snowflake, dbt, Airflow and Power BI, the Data-Agents Swarm does the work with 20+ specialist agents, and the Autonomous Data-Conductor runs each fix end to end (detect, diagnose, fix, review, verify, remember) behind per-domain approvals, receipts and rollback.
What Data Workers reads natively. With your Snowflake credentials, the Cost Savings & Data Cleanup agent reads Snowflake's query attribution and query history views, splits each warehouse's metered credits across the queries that ran on it, and decodes the dbt model, project and run from each query's tag. A routed query is attributed to the pool warehouse it ran on, and its tag still names the model, so where dbt's query tags reach Snowflake through the proxy, the trail holds. Data Workers reads Airflow DAG runs and task instances and, on Airflow 2, queues approved runs with trigger_airflow_dag. trace_cross_platform_lineage and blast_radius_analysis map what a model feeds, from the dbt manifest and from context-graph notes on which reports and finance processes read which models. run_quality_check covers nulls, ID uniqueness and row counts on Snowflake tables, and monitor_metrics keeps baselines on what the team records, such as daily credits per cost center.
Espresso, side by side. Data Workers connects to Espresso over its API today; your team manages Espresso settings in its dashboard or through its Terraform provider with an organization API key. Espresso publishes attributed metering as a reporting table shaped like Snowflake's metering history, so your dbt models can read it and Data Workers can check the marts built on it. Data Workers never changes Espresso settings; when routing needs an exception, it drafts the request and the platform owner decides.
# Example: Data Workers agents in Claude Code, from a clone of the open-source repo
# (path documented at /opensource-docs/client-setup/)
claude mcp add --scope user dw-catalog -- "$(pwd)/start-agent.sh" dw-context-catalog
claude mcp add --scope user dw-quality -- "$(pwd)/start-agent.sh" dw-quality
claude mcp add --scope user dw-incidents -- "$(pwd)/start-agent.sh" dw-incidents
claude mcp add --scope user dw-connectors -- "$(pwd)/start-agent.sh" dw-connectorsAsk "why did marketing's chargeback drop this week?" and the client gets the flagged baselines, the credits by dbt project and warehouse, the mart's readers and a drafted change. For a shared endpoint, the Data Workers remote server takes an API key (bearer) or OAuth tokens from your identity provider, verified through JWKS.
One reshuffled chargeback, L0 to L4, set per domain.
- •L0 manual. A marketing lead asks on Friday why their charge fell by two thirds, after finance posted the journal.
- •L1 observe. Data Workers posts the diagnosis at 06:10: which cost centers moved, where the credits went, which report reads the mart. Nothing changes.
- •L2 propose. Data Workers drafts the model change and the guard test. Nothing runs until the model owner approves in Spellbook.
- •L3 act reversibly. For change classes with a proven record, such as rebuilding a mart after an approved model change, Data Workers queues the run, verifies it and records the receipt.
- •L4 autonomous. For a scoped domain, Data Workers rebuilds and verifies before the business day; Espresso settings and model logic stay with their owners.
For the safety model, read is it safe to let AI agents change production data, how approvals work and autonomy levels L0 to L4. On where data lives: the agents run in your infrastructure with your credentials, your data stays in your systems, and the hosted Conductor sees workflow metadata only.
What changes for your team
Espresso took warehouse placement off the platform team's plate. Data Workers takes the data consequences of routing off the data team's.
- •Incidents. A number that moved after a routing change arrives with its cause, its readers and a fix to approve.
- •Data quality. Baselines on the marts built from routed work catch a shift before a report goes out.
- •Cloud spend. Snowflake credits are traced to the query and dbt model, wherever Espresso ran them, so showback stays tied to the work.
- •Access. A warehouse grant the scheduler needs becomes a scoped request the data owner approves and applies, with the expiry on record.
- •Audits. Espresso records where each query ran; Data Workers records what changed in the data and who approved it.
- •Migrations. Turning routing on for another warehouse starts with a blast-radius check of every model that reads warehouse metering, and the changes go to their owners as diffs.
Keep Espresso AI, or consolidate?
Keep Espresso AI if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
For query routing and scaling, keep Espresso: deciding where every query runs, as it arrives, is its whole job. What teams consolidate is the work around it: the scripts that watch marts for odd swings, the separate observability contract and the spreadsheet of who owns which model. The neighbours take different paths: Keebo tunes warehouse settings from metadata, SELECT pairs automated savings with dbt cost attribution, and Revefi runs DBA work with an agent. For the wider practice, see Snowflake cost optimization with AI agents and FinOps for data platforms. Weighing a build? Read build it ourselves with Claude Code and MCP servers, and for every connector category, Data Workers integrations.
The case for your CFO
The outcome: you bought Espresso to spend less on Snowflake without anyone tuning warehouses by hand. Data Workers protects that decision by making sure the cheaper platform never produces a wrong number, including the cost numbers finance charges back to each team. When a routing change shifts something downstream, the fix is approved and verified before the business acts on it.
The risk story is plain. At L1 Data Workers only reads; at L2 it changes nothing until a named person approves; at L3 it applies changes it can undo. An unanswered approval request expires and escalates, never auto-grants. No agent can promote its own work. Every change carries a receipt: cause, change, approver, what it touched, how it was verified and its model cost. An org-wide stop halts all autonomous dispatch. Zero migration: Espresso, Snowflake, dbt, Airflow and Power BI stay where they are.
Why now: optimization moved from a quarterly project to an agent that acts on every query, so changes land before the data team hears about them. The first win is read-only: every mart built on routed warehouses gets baselines, and every shift gets a diagnosis with the real credit trail. Espresso bills a share of its savings; Data Workers has a flat platform fee with no usage meter (why). For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "Espresso decides where each query runs; Data Workers makes sure every number built on it is still right, with an owner's approval on every fix."
Getting started
Start with a pilot. Pick one domain on Espresso-routed Snowflake warehouses, such as the finance and chargeback marts, connect Data Workers to Snowflake, dbt and your orchestrator, record baselines on the numbers that matter, and run at L1 so every shift gets a diagnosis, a credit trail and a blast radius. Then turn on L2: drafted model changes and reruns with the owner's approval. 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 route queries or resize warehouses like Espresso AI? No. Routing, scaling and SQL optimization are Espresso's job and your platform team's. Data Workers drafts a warehouse setting or a routing exception when the data needs one, and the owner applies it. It never reroutes a query, resizes a warehouse or cancels a statement.
Espresso's Query Agent proves rewrites equivalent. What is left to check? The rewrite itself is Espresso's to prove. Data Workers checks everything around the work: the tables your models produce, the baselines on the numbers people use, and the models that read warehouse metering or query history. The incident above involved no rewrite at all.
Can Data Workers show what routing did to a dbt model's Snowflake credits? Where dbt sets query tags, Data Workers traces credits to the query and the dbt model, project and run behind them, on whichever warehouse Espresso chose, so you can compare a model's credits before and after routing. Espresso reports its savings and rolls routed credits back to the warehouse each query was sent to.
We also run Espresso on Databricks. What does Data Workers do there? Espresso optimizes Databricks SQL warehouses and right-sizes Spark jobs. Data Workers traces what a job feeds from the dbt manifest and the context graph, queues approved reruns through your orchestrator and routes fixes to their owners; checks on the Databricks tables stay with the owner's tests, and the per-query credit trail is built on Snowflake's attribution views.
Does Espresso or Data Workers see our data? Espresso's proxy passes data through without inspecting or storing it, and it can be self-hosted. Data Workers runs in your infrastructure with your credentials, reads Snowflake usage metadata and runs the checks you configure; your data stays in your systems, and the hosted Conductor sees workflow metadata only.
Sources
- •Espresso AI, home page (agents, setup, savings-based pricing), https://espresso.ai/ (checked Oct 3, 2026)
- •Espresso AI, How it Works (Scheduling Agent, Query Agent, formal verification), https://espresso.ai/how-it-works (checked Oct 3, 2026)
- •Espresso AI, Pricing (Single-Shot, Double-Shot, Cold Brew), https://espresso.ai/pricing (checked Oct 3, 2026)
- •Espresso AI, Introducing Kubernetes for Snowflake (Aug 6, 2025; generally available), https://espresso.ai/post/introducing-kubernetes-for-snowflake (checked Oct 3, 2026)
- •Espresso AI, Launching our Databricks SQL Optimizer (Oct 29, 2025), https://espresso.ai/post/launching-our-databricks-sql-optimizer (checked Oct 3, 2026)
- •Espresso AI, Free Snowflake Observability (Feb 26, 2026), https://espresso.ai/post/observability (checked Oct 3, 2026)
- •Espresso AI Docs, Welcome (Autoscaling, Scheduling and Query agents; Query Agent private preview), https://docs.espresso.ai/ (checked Oct 3, 2026)
- •Espresso AI Docs, Scheduler Credit Attribution (metadata comment, pool warehouses, attributed metering), https://docs.espresso.ai/snowflake-optimizer/credit-attribution (checked Oct 3, 2026)
- •Espresso AI Docs, Snowflake Architecture (proxy, self-hosting, query-text-less mode), https://docs.espresso.ai/snowflake-optimizer/snowflake-architecture (checked Oct 3, 2026)
- •Espresso AI Docs, Snowflake Autoscaler (service user, metadata, per-warehouse opt-in), https://docs.espresso.ai/snowflake-optimizer/snowflake-autoscaler (checked Oct 3, 2026)
- •Espresso AI Docs, Snowflake Proxy Onboarding, dbt Core and Warehouse access, https://docs.espresso.ai/snowflake-optimizer/proxy-onboarding (checked Oct 3, 2026)
- •Espresso AI Docs, Terraform provider (organization API key, warehouse agent settings), https://docs.espresso.ai/snowflake-optimizer/terraform-provider (checked Oct 3, 2026)
- •Espresso AI Docs, Databricks Spark Optimizer, https://docs.espresso.ai/databricks-optimizer/databricks-spark-optimizer (checked Oct 3, 2026)
- •Data Workers open-source repository, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)
- •Data Workers client setup guide, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)
- •Data Workers pricing, https://dataworkers.io/pricing/ (checked Oct 3, 2026)