You're on Unravel: Unravel Tunes How Your Jobs Run. Data Workers Owns Whether What They Produce Is Right

Your platform team runs on Unravel. Arvix AI, the engine Unravel unveiled on May 27, 2026, now powers every optimization action in the product: it rewrites SQL and PySpark, right-sizes clusters, warehouses and slot reservations, cleans up storage and tracks each action to realized savings across Databricks, Snowflake and BigQuery. Its Context Graph knows which cluster a query runs on, which team owns it and what the SLA is. Each optimization runs in AutoApply or Human-in-Loop, set per action category, workload and team, and code rewrites default to Human-in-Loop. Unravel tunes how your jobs run. Data Workers owns whether what they produce is right, and who signed off on changing it: it checks the output of every optimized job, traces who reads it and sends each fix to its owner, behind approvals.

The two jobs meet every time a faster job ships.

Key takeaways

• •Unravel keeps its job. Arvix, the Context Graph, AutoApply and Human-in-Loop, cost attribution and savings tracking stay with your platform team.
• •Data Workers checks what each optimization did to the data. After an optimized job runs, it checks nulls, keys and row counts in Snowflake or BigQuery, compares your baselines and reads the dbt manifest diff.
• •It traces the readers before anyone touches the fix. Lineage from the dbt manifest shows the marts and feature models; the context-graph notes your team records add the dashboards, ML pipelines and exports outside dbt.
• •Fixes go to owners, behind approvals. The model change is drafted as a diff for its owner; the rebuild is queued after a named person approves.
• •Every fix leaves a receipt linking the change that caused it, the checks, the lineage, the diff and the approver.
• •Start with a pilot on one domain, read-only first, and climb from L0 manual toward L4 autonomous.

Unravel tunes how your jobs run. Data Workers owns whether what they produce is right.

Unravel answers how a job should run: on what compute, with what code, at what cost, inside what SLA. Data Workers answers whether its output still means what the business thinks, who reads it and who approves a fix. Usually they agree. The cases worth planning for are where a faster query and an unwritten business rule disagree.

Here is a Monday at a usage-billed software company on Google Cloud. Usage events land in BigQuery. A dbt Core project, run nightly by an Airflow 2 DAG, builds fct_billable_usage, which drops events from internal and test accounts with WHERE account_id NOT IN (SELECT account_id FROM dim_internal_accounts). It feeds mrt_usage_revenue, read by the finance team's Looker "Usage & Revenue" Explore; feat_account_usage, which a Vertex AI pipeline uses to train the churn model; and a 09:00 Airflow task that posts metered usage to Stripe for invoicing. About 0.8% of events arrive without an account_id: guest sessions in the free tier. Under NOT IN those rows never reach the billing table, though nobody wrote that rule down. The team has recorded the Looker Explore, the Vertex AI pipeline and the Stripe export as notes in the Data Workers context graph, baselines daily billable usage units with monitor_metrics, and has registered a null check on account_id that requires every row to carry one. Data Workers reaches BigQuery through a service account the team set up for it. This is an illustrative example.

Unravel did its job well. The rewrite is faster and cheaper, it went through Human-in-Loop review, and the saving stays: the fix keeps NOT EXISTS. NOT IN and NOT EXISTS return the same rows until a key is NULL, and whether a NULL-key event belongs on an invoice is a business rule no performance check can see. Data Workers checked the output, tied it to the change, traced every reader, reached the export's owner in time and drafted a fix that writes the rule down for the next optimization.

Why doesn't Unravel just do this itself?

Because Unravel is built for a hard job and does it well: making data workloads cheaper and faster without breaking their SLAs. Its validation loop asks whether a change makes the job run better and whether anything degrades after it lands. Its controls fit that job: read-first connectors, separately granted write roles, Human-in-Loop as the default for code, approval routing by action type and cost threshold. Unravel's FAQ says it sends no data back to your warehouse, a sound decision for an optimizer.

Knowing that guest sessions must never reach an invoice, that a churn model trains on the same table and that the Stripe export runs at 09:00 is knowledge about what the data means and who depends on it. Acting on it crosses six systems, each with its own owner, and carries the liability for changing a revenue number. An optimizer is measured on dollars and runtimes; the data team is measured on the number being right. Data Workers is built for that second job, on top of the optimizer you already trust.

Every tool owns a slice. Data Workers covers the whole lifecycle

Unravel owns its slice: autonomous data platform optimization. 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 optimization Unravel already runs.

How Unravel and Data Workers work together

Your people stay in Claude Code, Cursor or Claude, in Unravel's Operations Center and in the warehouse. Spellbook Data Catalog (in preview) is where the data team reviews each finding, diff and approver, 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 Unravel keeps. Arvix, its policies and approvals, cost attribution and savings tracking. Data Workers connects to Unravel over its REST API today, which exposes cost data, efficiency scores, optimization queues and action history. Your team's own assistant can call that API side by side with Data Workers' MCP servers. Data Workers' checks rest on what its own connectors read.

What Data Workers reads. Natively, among 50+ connectors: the dbt manifest and its lineage, warehouse checks through run_quality_check on Snowflake and BigQuery, baselines in monitor_metrics, orchestrator runs on Airflow, Dagster, Prefect and ADF, and GitHub pull requests. On Snowflake it traces credits to the query and dbt model behind them, where dbt sets query tags; on BigQuery it sums recent job bytes into an account-level total, with no per-model split. Agents get one governed view through explain_table, trace_cross_platform_lineage and blast_radius_analysis. On Databricks, Unravel keeps the DBU and cluster view; Data Workers applies approved Unity Catalog grants and works from dbt lineage, runs and baselines.

BigQuery setup. run_quality_check reaches BigQuery with a service-account key. Create a service account that can read the datasets to check and run query jobs in the project, and give its key and project ID to the quality agent in your deployment, where the key stays.

What Data Workers changes, and where. Model changes are drafted as diffs for the owner to merge. Rebuilds are queued through your orchestrator after a named person approves: on Airflow 2 Data Workers queues the DAG run; on Airflow 3 the owner triggers it. Warehouse or cluster settings are drafted for the platform owner. 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.

// 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"]
    },
    "dw-incidents": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-incidents"]
    },
    "dw-connectors": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-connectors"]
    }
  }
}

List the tools with your client's own command (/mcp in Claude Code), then ask "Arvix wants to rewrite fct_billable_usage. What reads that table, and which checks should run after the next build?"

One optimization, L0 to L4. The ladder is set per domain, so billing models can sit lower than product analytics.

• •L0 manual. An engineer approves the rewrite and hopes someone notices if a number moves.
• •L1 observe. Data Workers checks every table an optimization touches after its next run, reports failures with their lineage and logs what each action would have needed.
• •L2 propose. It drafts the model fix and the rebuild for the owner, who approves before anything runs.
• •L3 act reversibly. For proven classes, such as rebuilding a model whose approved fix has merged, it queues the step, re-checks and records. The owner can revert at any point.
• •L4 autonomous. For a scoped, trusted class in one domain, it runs the loop end to end and posts the receipt. Unravel's AutoApply settings stay with your platform team.

More on safety, approvals, who owns the agents, autonomy levels, where your data goes, integrations, Google Cloud, Databricks and the Cost Savings & Data Cleanup agent. The same pattern holds for Revefi, SELECT and Keebo, and for the orchestration side on Airflow and dbt.

What changes for your team

Platform teams on Unravel lose time at the seam between optimizing and trusting: the rewrite nobody will approve because nobody knows what reads the table, the faster job that moved a revenue number, the question of who signed off. With Data Workers, those jobs run on autopilot at the level you set.

• •Data quality. Every table an optimization touches is checked for nulls, keys and row counts after its next run.
• •Incidents. A rewrite that moves a number arrives traced to its change, with its owner asked and the fix drafted.
• •Cloud spend. Snowflake credits are traced to the dbt model behind each fix through query tags.
• •Audits. Each fix links the change that caused it, the checks and its approver.
• •Migrations. When a platform moves, each wave is planned with its checks, and the owner signs off before it closes.
• •Access. Grants a fix needs are dry-run first and approved by a named owner.

Engineers approve more of Arvix's queue because each change comes back checked. See the guides for FinOps leads, platform engineers and heads of data, and how to measure AI data agents.

Keep Unravel, or consolidate?

Keep Unravel if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.

Unravel stays your optimizer. What teams consolidate is the glue around it: the ad hoc queries after a rewrite ships, the Slack threads about which dashboards read a table, the spreadsheet of who approved which change, and the separate quality and incident tools that never see what the optimizer did. Building it yourself? Calling an MCP server is the easy part; the checks, lineage, approvals and receipts are the work. For the BigQuery cost side, see how to optimize BigQuery costs and BigQuery cost optimization with AI agents.

The case for your CFO

The outcome: every optimization your platform ships comes with proof that the numbers it feeds are still right. You keep Unravel's savings without risking an invoice, a revenue report or a model trained on the wrong rows.

The risk story is plain. Data Workers changes nothing in Unravel and runs no warehouse or cluster changes. It checks the data, traces the readers and drafts each fix for a named owner to approve. Unanswered requests expire and escalate, never auto-grant. No agent can promote its own work. Autonomy is set per domain, an org-wide stop halts all autonomous dispatch, and the admin kill switch takes two people. Every fix leaves a receipt. The agents run in your infrastructure with your credentials; your data stays in your systems, and the hosted Conductor sees workflow metadata only.

Why now: Arvix moved optimization from advice to action, so faster jobs touch reported numbers more often. The first win is one domain, read-only, with a check on every table an optimization touches. What stays the same: Unravel, your dbt project, your orchestrator and your platform team. The ROI guide shows the math, and the flat-fee explainer covers pricing without a usage meter.

The sentence to repeat upstairs: "Unravel makes our jobs cheaper and faster; Data Workers proves the output is still right, with an approver and a receipt for every fix."

Getting started

Start with a pilot. Pick the domain where a wrong number costs the most, such as billing, connect Data Workers read-only to the warehouse, the dbt project and your orchestrator, record your key metrics as baselines and the readers outside dbt as context-graph notes, and let it check every table Arvix optimizes before you turn 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 Unravel? Over Unravel's REST API today, which your team's assistant can call side by side with Data Workers' MCP servers. Data Workers reads your warehouse, dbt project and orchestrator natively with your credentials; on BigQuery, a service-account key you create for it.

Arvix already validates every change and reverts on degradation. Why add another check? Arvix validates how a change runs against your workload history. Data Workers checks what the change produced against the checks and baselines your data team owns, and traces the readers downstream. One protects the SLA and the bill; the other protects the number.

Does Data Workers replace Unravel's cost attribution or rightsizing? No. Unravel stays your view of platform cost. Data Workers traces Snowflake credits to the dbt model behind a fix, reads BigQuery as an account total, and drafts any warehouse setting a fix needs for the platform owner.

Should we run Arvix in AutoApply or Human-in-Loop? That stays your platform team's call, set in Unravel per action category, workload and team. Code rewrites default to Human-in-Loop in Unravel; either way, Data Workers checks every table after the change ships.

We run Unravel mostly on Databricks. Does this still work? Yes. Unravel keeps the DBU and cluster view. Data Workers works through approved Unity Catalog grants, dbt lineage, orchestrator runs and your baselines; the table owner runs the checks on Delta tables, by design.

Does any data go to Data Workers? The agents run in your infrastructure with your credentials. Your data stays in your systems; the hosted Conductor sees workflow metadata only.

Sources

• •Unravel Data home page (Arvix AI, Context Graph, validation loop and watchdog), https://www.unraveldata.com/ (checked Oct 3, 2026)
• •Unravel Data, "Unravel Data Unveils Arvix AI, the First Agentic AI Engine Enabling Autonomous Optimization across Databricks, Snowflake, and BigQuery" (May 27, 2026), https://www.unraveldata.com/resources/unravel-data-arvix-ai-agentic-ai-engine-autonomous-optimization/ (checked Oct 3, 2026)
• •Unravel Data, Arvix AI (what Arvix automates, control modes, FAQ), https://www.unraveldata.com/platform/purpose-built-ai (checked Oct 3, 2026)
• •Unravel Data, Docs and FAQ (AutoApply vs Human-in-Loop, approvals, read-only mode, REST API, CI/CD plugins, bring-your-own LLM), https://docs.unraveldata.com/ (checked Oct 3, 2026)
• •Unravel Data for Google Cloud BigQuery (rewrite diff, 30-day validation, AutoApply or review, Dataform runs, custom dashboards), https://www.unraveldata.com/solutions/technologies/google-cloud-bigquery (checked Oct 3, 2026)
• •Unravel Data, Data Quality use case, https://www.unraveldata.com/solutions/use-cases/data-quality (checked Oct 3, 2026)
• •Unravel Data, Integrations and APIs, https://www.unraveldata.com/platform/integrations-and-apis (checked Oct 3, 2026)
• •Unravel Data, News and Press, https://www.unraveldata.com/company/news-and-press (checked Oct 3, 2026)
• •Google Cloud, BigQuery operators, IN operator (NOT IN returns NULL when the search value is NULL), https://cloud.google.com/bigquery/docs/reference/standard-sql/operators (checked Oct 3, 2026)
• •Data Workers product repository: quality checks and BigQuery service-account access, lineage, approvals, Airflow 2 triggers, cost reads (checked Oct 3, 2026)
• •Data Workers client setup docs, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)