You're on Soda: It Checks the Data Against the Contract. Data Workers Fixes What Fails It
Soda verifies your data contracts and flags the failed check. Data Workers diagnoses the cause across systems, fixes it with approval and re-runs the Soda checks.
Your data team runs on Soda 4.0. Producers and consumers agree on a data contract for each dataset, kept in git or edited in Soda Cloud, and the dataset owner approves every change. soda contract verify runs in CI on each pull request and on schedule, metric monitors watch the tables nobody wrote a rule for, failed rows land in the Diagnostics Warehouse inside your own warehouse, and a failed check becomes an incident with a lead. Soda AI drafts contracts (Contract Autopilot, in preview) and edits them in plain English (Contract Copilot), Soda MCP brings Soda into Claude, Cursor and Codex, and the RCA agent, in private preview, investigates a failing check from Claude Code. Soda is the contract check, and a very good one. Data Workers fixes what fails it.
When a contract fails, Soda tells you which check broke, on which rows, and who owns the dataset. Somebody still has to find the upstream change, get a fix approved, rebuild the models, update the contract and prove it holds. Data Workers does that work behind approvals and leaves a receipt.
Key takeaways
- •Soda keeps its job. Contracts, checks, monitors, incidents and Soda AI stay where they are, owned by the same people.
- •A failed check becomes a governed fix. Data Workers reads Soda check results and monitors through its native Soda connector, traces the failure to the upstream change and proposes the whole repair: the dbt diff, the rebuild and the contract change.
- •The contract is the proof. After the owner approves, Data Workers queues the rebuild through your orchestrator, then triggers the Soda checks again. The fix is done when the contract passes.
- •Schema changes get caught before the contract fails. Data Workers reads the producer side too, so a column dropped from the CDC schema in Schema Registry is flagged with its blast radius before the next build.
- •Autonomy per domain. Each data domain climbs from L0 manual to L4 autonomous at the pace your team sets.
Soda is the contract check. Data Workers fixes what fails it.
Soda is the smoke alarm; Data Workers is the crew. Here is a Tuesday across a PostgreSQL product database, Debezium on Kafka, Databricks, dbt run by Airflow and Looker. This is an illustration, not a customer case.
| Time | System | What happens |
|---|---|---|
| Tue 09:40 | PostgreSQL | A product release splits customers.region into country_code and region_code and drops region |
| 09:41 | Debezium on Kafka | The CDC connector emits a new schema version for the customers topic; Schema Registry accepts it as compatible |
| 09:43 | Data Workers | Reads the new subject version from Schema Registry and flags the dropped column as breaking; blast_radius_analysis maps it to dim_customer, the Looker territory Explore and three dashboards, and posts the finding to the analytics engineering channel |
| 10:05 | Databricks | The streaming job merges the new rows into bronze.customers; region arrives null for 4,212 changed customers |
| 10:12 | Airflow and dbt | The hourly DAG run rebuilds dim_customer on Databricks with the nulls |
| 10:20 | Soda | Contract verification on dim_customer fails: the missing check on region and the valid-values check on sales_territory; the on-call opens a Soda incident |
| 10:24 | Data Workers | Reads the failed check results from Soda Cloud and ties them to the 09:40 migration it had already flagged; get_incident_history finds no earlier fix to reuse |
| 10:35 | Data Workers | Proposes the repair: a dbt staging diff that derives region from region_code, a rebuild of dim_customer and its two downstream models for the affected rows, and a contract change adding region_code with a deprecation note on region |
| 10:52 | Spellbook | The analytics engineering owner reviews the diff and blast radius, approves and merges it; Soda's Verify Contracts on Pull Request workflow passes |
| 11:05 | Airflow | Data Workers queues the rebuild through Airflow; the dbt tests pass |
| 11:20 | Soda | Data Workers triggers the Soda checks again; the contract passes and the dataset owner publishes the updated contract |
| 11:26 | Looker | Data Workers confirms volume on the models behind the Explore, and load lag against its monitor_metrics baseline, and records the receipt; the on-call links it on the Soda incident through Soda MCP's update_incident |
Soda did exactly what a contract is for: it stopped bad data and named the owner. What changed is everything after: the cause was already known, one proposal covered model, rebuild and contract, a named owner approved it, and the contract that failed is the evidence the fix held.
| Job | What Soda does | What Data Workers does |
|---|---|---|
| Expectations | Data contracts in git or Soda Cloud, with owner review and change requests | Uses the contract as the bar a fix must clear, and drafts contract changes for the owner |
| Detection | Contract verification in CI and on schedule, metric monitors and record-level anomaly detection | Also reads schema versions on the stream and tracks freshness and volume against monitor_metrics baselines, so many breaks are flagged before a check runs |
| Root cause | Failed rows in the Diagnostics Warehouse; the RCA agent (private preview) investigates from Claude Code and proposes a fix | Joins Soda's check results to CDC, Databricks, dbt, Airflow and incident history in one context graph to find what changed and what else it touched |
| The fix | Proposed by the RCA agent; your team writes, reviews and runs it | Proposes the complete repair (dbt diff, rebuild, backfill, contract change) with blast radius, routed to a named owner |
| Running it | Your engineers merge, rerun and backfill by hand | The owner approves in Spellbook and merges; Data Workers queues the reruns through your orchestrator |
| Verification | The contract passes on the next run | Triggers the Soda checks, then checks volume, quality and load lag against its baseline on the downstream models the fix touched |
| The record | The check history and the incident | A receipt: the cause, the diff, who approved it, what it touched, how it was verified and how to undo it |
Why doesn't Soda just do this itself?
Because Soda chose where its product ends, and its docs say so. Soda AI is "assistive, not autonomous": "every proposed action is shown and approved by a person before it is applied", and the chat, Autopilot and Copilot "do not operate outside the context of your Soda Cloud workspace." The RCA agent "only proposes fixes. It does not commit to a remote, push, or open a pull request unless you explicitly ask it to", and the docs say to "register warehouse MCP servers read-only. The agent never needs to write, and an investigation must not be able to." The Diagnostics Warehouse needs no delete permission at all, and AI Remediation of bad records is marked "Soon" on the homepage.
That is the right design for a contract product. A contract is only trustworthy if the thing checking it is not also rewriting the data. Fixing what failed is a different product with a different liability: the fix lands in dbt, the orchestrator and the lakehouse, the contract change needs the dataset owner, and someone has to prove the result. Soda would have to own changes in systems it checks but does not run. Data Workers is built for exactly that job.
Every tool owns a slice. Data Workers covers the whole lifecycle
Soda owns the contract: what good data means for each dataset and whether today's data meets it. 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 the contracts you already have.
| Stage | Data Workers | Soda | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 3 | Soda keeps datasets, owners and contracts, and shows lineage and impact for a failed check. Data Workers keeps one governed context graph of definitions, owners, lineage, quality and usage across every platform. |
| Analytics & Insights | 8 | 2 | The Soda AI chat answers questions about checks, contracts and incidents. Data Workers answers data questions from governed definitions with lineage behind every number. |
| Data Quality | 8 | 9 | Soda's home stage: data contracts in git or Soda Cloud, verified in CI and on schedule, with metric monitoring and record-level anomaly detection. Data Workers also runs checks and repairs the data that fails them. |
| Observability & Incidents | 8.5 | 7.5 | Metric monitors, failed-row diagnostics and incidents, plus an RCA agent in private preview that proposes fixes. Data Workers diagnoses across systems, fixes with approval and verifies the fix. |
| Pipelines & Ingestion | 8.5 | 3 | Soda checks run inside Airflow, Dagster and dbt Cloud pipelines and block bad data early. Data Workers queues reruns and backfills through your orchestrator, with approvals. |
| Schema & Migration | 8 | 5 | Schema checks catch a missing or retyped column, and contract changes go through owner review. Data Workers catches the schema change upstream, scores its blast radius and plans migrations in waves. |
| Governance & Access | 8.5 | 3 | Dataset roles, responsibilities and contract approvals govern who changes the checks. Data Workers routes each warehouse access request to its owner as a scoped, time-boxed grant. |
| Security & Privacy | 8 | 2 | Failed rows stay in your own warehouse, and source data is not sent to models by default. Data Workers' pull request review flags new columns whose names or annotations look sensitive, and leaves a receipt on every data change. |
| Cost / FinOps | 8 | 2 | Soda does not manage warehouse spend. Data Workers traces Snowflake credits to the dbt model behind them and drafts the fix for its owner. |
| MLOps & Models | 7.5 | 2 | Contracts can cover feature tables, but models are out of scope. Data Workers keeps the data under your models fresh and correct. |
Soda leads on its home stage, as it should. For the category view, see Bigeye, Anomalo, Sifflet and Soda vs Data Workers, how Data Workers differs from data observability, Great Expectations vs Soda, Great Expectations vs Soda vs AI agents and Soda data quality alternatives.
How Soda and Data Workers work together
Soda stays on top, where contracts are verified. Spellbook Data Catalog (in preview) is where the data team looks: each proposed change, who approved it and how to roll it back. Between them, Data Context Wizard keeps one governed context graph across the estate, 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 guardrails.
What Data Workers reads, runs and writes with Soda. Soda is a native Data Workers connector. Through the Soda Cloud API, Data Workers reads check results and monitors, and it triggers a Soda check run to re-verify a contract after a fix. It writes nothing to Soda: contract changes are drafted for the dataset owner, who publishes them in Soda. The receipt link goes on the Soda incident's resolution notes from your team's MCP client, through Soda MCP's update_incident.
What happens on a failed check. diagnose_incident and get_root_cause work through the evidence, assess_impact covers the source change, trace_cross_platform_lineage and blast_radius_analysis map everything downstream, and get_incident_history finds earlier fixes. The repair runs through remediate: the dbt change is proposed as a diff for the owner to merge, and reruns are queued through your orchestrator after approval. Verification uses the Soda checks plus the monitor_metrics baseline, and every step lands in get_audit_trail.
Side by side in one client. Soda documents Soda MCP for Claude Code, Cursor, Codex and GitHub Copilot. Every Data Workers agent is an MCP server; the client setup guide documents the path (clone the open-source repo, add one start-agent.sh entry per agent).
# Example: Soda MCP plus Data Workers in Claude Code
# Soda's documented setup (Team or Enterprise private index, Soda Cloud API key)
claude mcp add soda-mcp --transport stdio --scope user \
-e SODA_CLOUD_HOST="$SODA_CLOUD_HOST" \
-e SODA_API_KEY_ID="$SODA_API_KEY_ID" \
-e SODA_API_KEY_SECRET="$SODA_API_KEY_SECRET" \
-e UV_INDEX="$UV_INDEX" \
-- uvx -qq --no-progress soda-mcp@latest
# Data Workers agents over stdio, from a clone of the open-source repo
claude mcp add --scope user dw-catalog -- "$(pwd)/start-agent.sh" dw-context-catalog
claude mcp add --scope user dw-schema -- "$(pwd)/start-agent.sh" dw-schema
claude mcp add --scope user dw-incidents -- "$(pwd)/start-agent.sh" dw-incidents
claude mcp add --scope user dw-quality -- "$(pwd)/start-agent.sh" dw-qualityAsk "why did the dim_customer contract fail, and what does the fix touch?" and the client calls both: Soda returns the failing checks and the incident; Data Workers returns the source migration behind it and a proposed repair with its blast radius. Soda's API key scopes what the client can do in Soda; Data Workers' guardrail decides whether a change may run, with a named approver. For a shared endpoint, the Data Workers remote server serves /mcp with an API key (bearer) or OAuth tokens from your identity provider, verified through JWKS.
One failed contract, L0 to L4. The same dim_customer failure at each level of the autonomy ladder, set per domain.
- •L0 manual. An engineer digs through CDC logs and dbt and writes the fix by hand.
- •L1 observe. Data Workers posts the diagnosis: the 09:40 migration, the 4,212 rows and everything downstream. Nothing changes.
- •L2 propose. Data Workers proposes the dbt diff, the rebuild and the contract change. Nothing runs until the owner approves.
- •L3 act reversibly. For change classes with a proven record, such as rerunning a failed DAG run, Data Workers queues the step through Airflow, re-runs the Soda checks and records the receipt.
- •L4 autonomous. For a scoped domain with a long clean record, Data Workers handles the repeatable steps end to end and posts the receipt; code and contract changes still go to their owners.
For the safety model, read is it safe to let AI agents change production data, how approvals work, autonomy levels L0 to L4 and how to roll back an AI agent change. On where data lives: the agents run in your infrastructure, your data stays in your systems, and the hosted Conductor sees workflow metadata only.
What changes for your team
Soda gave producers and consumers a shared definition of good data. Data Workers gives them someone to fix it when the definition is broken.
- •Incidents. A failed Soda check arrives with a diagnosis, a blast radius and a proposed fix, and the Soda incident closes with a receipt.
- •Data quality. Each fix ends with the Soda checks re-run and passing, and the contract change drafted for the dataset owner.
- •Cloud spend. Snowflake credits are traced to the dbt model behind them, and each fix goes to its owner drafted.
- •Access. A request for warehouse access becomes a scoped, time-boxed grant the data owner approves.
- •Audits. Soda records the check history; Data Workers records what changed, who approved it and how to undo it.
- •Migrations. A producer's schema change is caught in review or in Schema Registry and planned in approved waves, with consumers told first.
The dataset owner changes most: instead of chasing a producer team, they review one proposal covering model, rebuild and contract. See the data incident response playbook, autonomous resolution beyond observability and who owns the agents.
Keep Soda, or consolidate?
Keep Soda if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Most Soda customers keep it, especially where contracts are how producers and consumers agree. What teams consolidate is the stack around it: a second quality tool alerting on the same break, hand-written backfill scripts and a runbook wiki. One licensing note: Soda Core moved to the Elastic License 2.0 with v4 in January 2026 (current release v4.25.0), so read its terms before embedding it in a product you host. Weighing building the fix layer yourself on Soda MCP and a coding agent? Read build it ourselves with Claude Code and MCP servers and Claude Code with Soda for data quality: the investigation is the easy part; the context graph, approvals, rollback and receipts are the work. The same pattern holds in you're on Great Expectations, you're on Monte Carlo and you're on Elementary; see also Data Workers integrations and what is an agentic data platform.
The case for your CFO
The outcome: you pay for Soda so bad data stops at the contract instead of reaching a board report. Data Workers turns each failed contract from a half day of tracing across teams into a diagnosis on arrival and a complete fix with one approval.
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 only changes it can undo. Code and contract changes go to their owners. An unanswered approval request expires and escalates, never auto-grants, and no agent can promote its own work. Every change carries a receipt, and an org-wide stop halts all autonomous dispatch.
Why now: finding the cause is getting faster as Soda's agents investigate and propose. The slow, expensive part is what follows: approving the fix, running it across systems and proving the contract holds. The first win is read-only: every failed Soda check in one domain gets a diagnosis and a blast radius. What stays the same: your contracts, checks, owners, CI workflow and warehouse permissions, with zero migration. The pilot path is on the pricing page, and the pilot is credited in full against the first year. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "Soda tells us the data broke its contract; Data Workers fixes the cause across every system, gets it approved and proves the contract holds again."
Getting started
Start with a pilot. Pick one domain whose contracts live in Soda, such as the customer datasets behind sales reporting, connect Data Workers to Soda, your lakehouse, dbt and your orchestrator, and run at L1 so every failed check gets a diagnosis. Then turn on reruns and rebuilds at L2 with owner approval, verified by the Soda checks. Plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
How does Data Workers connect to Soda? Soda is a native Data Workers connector. Data Workers reads check results and monitors through the Soda Cloud API and triggers a Soda check run to re-verify a contract after a fix. You can also run Soda MCP beside Data Workers in Claude Code and ask both in one conversation.
Does Data Workers change our Soda contracts or checks? No. Contracts, checks and monitors stay under your dataset owners and Soda admins. When a fix needs a contract change, such as a new column, Data Workers drafts it for the dataset owner, who publishes it in Soda through the usual review.
Soda's RCA agent already finds the root cause. Why add Data Workers? The RCA agent, in private preview, investigates a failing check from Claude Code and proposes a fix, by design with read-only warehouse access. Data Workers takes the next steps: one proposal covering code, rebuild and contract, a named approver, reruns queued through your orchestrator, the Soda checks re-run, and a receipt.
Does Data Workers run backfills or delete bad rows in our lakehouse? Backfills run as orchestrator task reruns after approval, with the undo step written into the plan before anything runs, for the owner to use if needed. Data cleanups such as removing bad rows are proposed for the owner to approve and apply. Soda's failed rows stay in your Diagnostics Warehouse as evidence.
Is Soda Core open source? Soda Core is source-available under the Elastic License 2.0 since v4 in January 2026: free to use, with limits on offering it as a hosted service. Data Workers works with Soda Cloud either way.
Sources
- •Soda, homepage (Soda 4.0, data contracts, Diagnostics Warehouse, AI Remediation marked Soon), https://www.soda.io/ (checked Oct 3, 2026)
- •Soda, Soda MCP product page, https://www.soda.io/product/mcp (checked Oct 3, 2026)
- •Soda Docs, Soda AI (assistive, not autonomous; human approval; source data not sent by default), https://docs.soda.io/soda-ai (checked Oct 3, 2026)
- •Soda Docs, Root cause analysis (RCA) agent (private preview), https://docs.soda.io/soda-ai/rca-agent (checked Oct 3, 2026)
- •Soda Docs, Soda MCP and MCP tools (
update_incidentresolution notes), https://docs.soda.io/soda-ai/soda-mcp and https://docs.soda.io/soda-ai/soda-mcp/mcp-tools (checked Oct 3, 2026) - •Soda Docs, Contract Autopilot (preview) and Contract Copilot, https://docs.soda.io/soda-ai/contract-autopilot and https://docs.soda.io/soda-ai/contract-copilot (checked Oct 3, 2026)
- •Soda Docs, Contract collaboration, https://docs.soda.io/data-testing/contract-collaboration (checked Oct 3, 2026)
- •Soda Docs, Verify a contract, https://docs.soda.io/data-testing/git-managed-data-contracts/verify-a-contract (checked Oct 3, 2026)
- •Soda Docs, GitHub (Verify Contracts on Pull Request), https://docs.soda.io/integrations/github (checked Oct 3, 2026)
- •Soda Docs, Incidents, https://docs.soda.io/manage-issues/incidents (checked Oct 3, 2026)
- •Soda Docs, Diagnostics Warehouse, https://docs.soda.io/diagnostics-warehouse (checked Oct 3, 2026)
- •Soda Core repository (Elastic License 2.0 since the v4 release, Jan 28, 2026; v4.25.0, Sep 23, 2026), https://github.com/sodadata/soda-core (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)