You're on Elementary: It Opens the dbt Fix PR. Data Workers Carries the Fix Through the Stack and Proves It
Elementary catches the failed dbt test and its Triage & Resolution agent opens a PR. Data Workers carries the fix across your stack, with approval and a receipt.
Your analytics engineers live in the dbt project, and Elementary lives there with them. The Elementary dbt package writes every run result and test result into your warehouse and adds anomaly tests for volume, freshness and column values next to your not_null and unique tests. Elementary Cloud groups related failures into one incident, routes the alert to the model's owner in Slack, and draws column-level lineage through dbt to your BI tools. When a test fails, an engineer clicks "Investigate with AI" or tags @Elementary in the alert thread, and the Triage & Resolution agent reads the recent commits, the run history and the lineage, then opens a pull request with its proposed fix. Elementary is the smoke alarm inside your dbt project, and a smart one. Data Workers is the crew.
Elementary opens the PR. Data Workers carries the fix through the rest of the stack. A failed dbt test is often a symptom of something before dbt ran: an ingestion setting, a source change, a bad load. Data Workers diagnoses that incident across ingestion, the warehouse and the orchestrator, carries the repair through approvals, verifies it and leaves a receipt.
Key takeaways
- •Elementary keeps its job. The dbt package, tests, incidents, alert routing, lineage and AI agents stay where your team already reviews them.
- •The PR is half the fix. Elementary's Triage & Resolution agent proposes a code change to a dbt model. Data Workers handles the rest: the bad rows already loaded, the models built on them and the upstream cause.
- •One approval, one receipt. A named owner approves the whole repair in Spellbook; Data Workers queues the rebuild, verifies it and records how to undo it.
- •Two MCP servers in one client. Elementary answers what failed and what it touches; Data Workers answers why, and what the fix is across systems.
- •Autonomy per domain. Each domain climbs from L0 manual to L4 autonomous at your pace.
Elementary is the smoke alarm inside your dbt project. Data Workers is the crew.
Elementary observes dbt runs and tests, groups failures and proposes code fixes. Data Workers diagnoses the data incident behind the failure, carries the fix through approvals and verifies it. Here is a Monday at a subscription software company running dbt Core on Dagster against a Postgres warehouse, with Chargebee billing data synced by Airbyte and a Hex dashboard the board reads. This is an illustration, not a customer case.
| Time | System | What happens |
|---|---|---|
| Sun 23:40 | Airbyte | A connection refresh on the Chargebee source resets the invoices stream and its sync mode changes from Incremental Append + Deduped to Incremental Append |
| Mon 05:30 | Postgres | The morning sync re-appends 14,882 invoice rows that were already loaded into raw_chargebee.invoices |
| 06:00 | Dagster | The dbt Core build runs; the incremental fct_mrr model merges the duplicated invoices into this month's MRR |
| 06:12 | Elementary | unique_stg_chargebee__invoices_invoice_id fails and the volume anomaly test on fct_mrr fires; Elementary groups both into one incident and alerts the finance analytics owner in Slack |
| 06:20 | GitHub | The on-call clicks "Investigate with AI"; the Triage & Resolution agent finds no recent model change and opens a PR that adds a row_number() dedupe to stg_chargebee__invoices |
| 06:24 | Data Workers | Reads the incident over Elementary's MCP server, traces the duplicates past dbt to the Airbyte sync and finds that fct_mrr already holds inflated rows the staging fix will not reach, plus the Hex board MRR dashboard downstream |
| 06:35 | Data Workers | Proposes the repair: keep the PR as a guard, remove the duplicate raw rows with a saved copy as the undo, full-refresh fct_mrr and dim_customers_arr, and change the sync mode back, for the Airbyte owner |
| 07:10 | Spellbook | The analytics lead reviews the blast radius and approves; the engineer merges the PR, the warehouse owner applies the cleanup, the Airbyte owner resets the sync mode |
| 07:25 | Dagster | Data Workers queues the full refresh of the two models through Dagster |
| 07:50 | Postgres | Data Workers verifies uniqueness, volume and MRR totals against distinct invoices in the raw table |
| 07:55 | Elementary | The rerun's tests pass; the on-call resolves the incident with the Spellbook receipt linked |
Elementary did its job well: one incident, the right owner and a sensible code change by 06:20. What changed is everything around that PR: the duplicates were traced to an ingestion setting dbt never sees, the fact the PR could not fix (an incremental model already holding inflated rows) was in the proposal, a named owner approved one change set, and the board dashboard showed correct MRR before anyone opened it.
| Job | What Elementary does | What Data Workers does |
|---|---|---|
| Detection | dbt tests, anomaly tests in the dbt package, ML monitors and Cloud Tests catch failures in or around each run | Watches freshness and volume itself and reads schema changes from the dbt manifest, so many breaks are caught before the next dbt run |
| Grouping and routing | Groups related failures into one incident and routes alerts by owner and severity | Joins the incident to history with get_incident_history, so a repeat break arrives with the last fix attached |
| Root cause | The Triage & Resolution agent reads commits, run history, lineage and (when allowed) the data | Traces past dbt into ingestion, the warehouse and the orchestrator to find what actually changed |
| The fix | Opens a pull request with a proposed change to the dbt project | Proposes the complete repair: data cleanup with undo, model rebuilds, and the upstream change for its owner, with blast radius |
| Running it | Your team reviews and merges the PR | A named owner approves in Spellbook; owners apply their changes; Data Workers queues the rebuilds through Dagster |
| Verification | The next run's tests pass | Checks uniqueness, volume and totals on every model the fix touched |
| The record | The incident, its alerts and the PR | A receipt: the cause, the diff, who approved it, what it touched, how it was verified and how to undo it |
Why doesn't Elementary just do this itself?
Because Elementary made a clear choice about where its product acts, and it is a good one. Its documentation says "Every action the agent takes goes through a pull request or requires explicit confirmation. Your team stays in control of what gets merged." The Triage & Resolution agent can "Recommend concrete steps to fix the issue" and open a pull request; the Performance & Cost agent opens one once its recommendations are approved. Everything lands in the dbt project, as code, through review. That is what analytics engineers want from a tool inside their repository.
Elementary's newest piece follows the same line. Elementary Runtime, announced on September 17, 2026 and in private beta, runs supported data-quality queries and AI agent tasks inside your network with your own warehouse credentials, while Elementary Cloud stays the control plane. It brings Elementary's checks closer to the data; it does not take over your ingestion, your warehouse writes or your orchestrator.
The Monday fix needed exactly those. Removing 14,882 duplicate rows from a production raw table, changing a sync setting in Airbyte, full-refreshing incremental models in a Dagster schedule and proving the board number is right are changes in systems Elementary watches but does not own. Each needs blast-radius scoping, an owner's approval, an undo ready before anything runs, and a record an auditor can read: liability far outside the dbt project. Data Workers is built for exactly that job.
Every tool owns a slice. Data Workers covers the whole lifecycle
Elementary owns observability for the dbt project, and it goes deep there. 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 Elementary where your analytics engineers already look.
| Stage | Data Workers | Elementary | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 5 | Elementary's catalog, Governance agent and column-level lineage from dbt to BI cover the dbt estate. Data Workers keeps one governed context graph of definitions, owners, lineage, quality and usage across every platform. |
| Analytics & Insights | 8 | 3 | The Catalog agent answers questions about assets in plain language. Data Workers answers data questions from governed definitions with lineage behind every number. |
| Data Quality | 8 | 8.5 | Elementary's home stage: dbt package anomaly tests, ML monitors, Cloud Tests and the Test Recommendation agent. Data Workers also writes, runs and repairs the checks and the dbt tests behind them. |
| Observability & Incidents | 8.5 | 9 | Elementary's home stage: grouped incidents, ownership-based alerts and the Triage & Resolution agent that traces the cause and opens a fix PR. Data Workers carries the fix across systems with approval and verifies it. |
| Pipelines & Ingestion | 8.5 | 4 | The Triage agent opens dbt pull requests. Data Workers queues reruns and backfills through your orchestrator and proposes the ingestion change for its owner, with approvals. |
| Schema & Migration | 8 | 5 | The Code Review agent reviews every dbt pull request. Data Workers catches schema changes in the dbt manifest and in review, scores their blast radius and plans migrations in waves. |
| Governance & Access | 8.5 | 4 | The Governance agent enforces documentation standards. Data Workers runs the warehouse access request queue with time-bound, approved grants. |
| Security & Privacy | 8 | 2 | Elementary secures its own AI features. 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 | 4 | The Performance & Cost agent flags slow or expensive models and opens a PR. Data Workers traces Snowflake credits to the dbt model behind them and drafts the fix for its owner. |
| MLOps & Models | 7.5 | 2 | Elementary reports ML pipeline assets through its SDK. Data Workers keeps the data under your models fresh and correct. |
Elementary leads on its two home stages, as it should. For the category view, read how is Data Workers different from data observability; for Elementary directly, see Data Workers vs Elementary Data and Elementary Data alternatives.
How Elementary and Data Workers work together
Elementary stays on top, where tests fail and the agent investigates. Spellbook Data Catalog (in preview) is where the data team reviews, approves and rolls back. 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 carries each fix from detection to verification.
Elementary to Data Workers. Elementary connects over its API or MCP server today: your team's assistant reads incidents, tests, run history and lineage side by side with Data Workers, which reads dbt, Dagster and Postgres natively. A new incident starts a diagnosis: diagnose_incident and get_root_cause work the evidence, trace_cross_platform_lineage follows the failure past dbt, blast_radius_analysis maps everything downstream, and get_incident_history checks for repeats. The repair runs through remediate: data cleanups are proposed for the owner to approve and apply, dbt changes arrive as a diff for the owner to merge, and reruns are queued through Dagster. Verification uses run_quality_check and get_quality_score, and every step lands in get_audit_trail.
Data Workers and Elementary's PRs. Data Workers reviews Elementary's pull request like any dbt change: what it touches downstream and whether it fixes the data already wrong. Its own dbt changes, such as a test that would have caught the duplicates, arrive as a diff for the owner to merge, or as a pull request when your team turns on the GitHub pull-request target. The receipt lives in Spellbook and the audit trail, and the on-call links it when resolving the incident.
Side by side in one client. Elementary documents its remote MCP server for Claude and Cursor, with OAuth 2.1 sign-in or an access token. Add Data Workers beside it: every Data Workers agent is an MCP server, and the client setup guide documents the path (clone the open-source repo, add one start-agent.sh entry per agent). Example for Cursor's .cursor/mcp.json, with Elementary's documented OAuth endpoint:
{
"mcpServers": {
"Elementary": { "url": "https://prod.api.elementary-data.com/mcp/" },
"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-quality": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-quality"] }
}
}Ask "why did MRR jump, and what does the fix touch?" and the client calls both: Elementary returns the incident, failed tests, run history and dbt lineage; Data Workers returns the Airbyte cause, the models holding bad rows, the Hex dashboard downstream and a proposed repair. Data Workers' guardrail decides whether a data change may run in that domain, 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 Elementary incident, L0 to L4. The same incident at each level of the autonomy ladder, set per domain.
- •L0 manual. An engineer merges the PR and hunts the duplicates by hand.
- •L1 observe. Data Workers posts the diagnosis: the Airbyte cause, the 14,882 rows and everything downstream. Nothing changes.
- •L2 propose. Data Workers proposes the cleanup with its undo, the rebuilds and the sync-mode change. Nothing runs until the analytics lead approves.
- •L3 act reversibly. For change classes with a proven record, such as rebuilding a model, Data Workers queues the step through Dagster, verifies it and records the receipt.
- •L4 autonomous. For a scoped domain with a long clean record, Data Workers handles the repeatable steps end to end; data cleanups still go to the owner.
For the safety model, read is it safe to let AI agents change production data and how approvals work. 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
Elementary made every broken model visible to its authors. Data Workers gives them a crew for everything outside the model.
- •Incidents. An Elementary incident gets a cross-system diagnosis, a blast radius and a proposed fix, and closes with a receipt.
- •Data quality. Each fix comes with a dbt test for the model that broke, proposed as a diff for the project Elementary already watches.
- •Cloud spend. On 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. Elementary records the incident and the PR; Data Workers records what changed in the data, who approved it and how to undo it.
- •Migrations. A move to a new warehouse runs in approved waves, with parity checks planned and tracked for each wave.
The analytics engineering on-call changes most: one proposal to review at 7 a.m., not duplicates to chase through three tools. See the data incident response playbook and who owns the agents.
Keep Elementary, or consolidate?
Keep Elementary if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Most dbt-centric teams keep Elementary: the package is Apache 2.0 and the tests live in the repo. What teams consolidate is the stack around it: a second monitor on the same break, hand-written cleanup scripts and a runbook wiki. Weighing building the fix layer yourself on Elementary's MCP server and a coding agent? Read build it ourselves with Claude Code and MCP servers: the MCP calls are the easy part; the context graph, approvals and rollback are the work. The same pattern holds in you're on Monte Carlo, you're on Soda and you're on Coalesce Quality; for this stack, see you're on dbt.
The case for your CFO
The outcome: the numbers your board, finance and sales teams read come out of dbt, and Elementary already flags the moment a dbt test fails. Data Workers turns each failure from a morning of tracing and reruns into a diagnosis on arrival and a complete repair under one approval, so MRR and churn are right before anyone reads them.
The risk story: at L1 Data Workers only reads; at L2 it changes nothing until a named person approves; at L3 it acts only on changes it can undo. Data cleanups go to the table's owner with a saved undo, every time. An unanswered request expires and escalates, never auto-grants. No agent can promote its own work. Every change carries a receipt. An org-wide stop halts all autonomous dispatch. Zero migration: Elementary, Airbyte, Postgres, dbt Core, Dagster and Hex stay where they are.
Why now: Elementary's agents already draft the code fix, so the slow part is the wrong data outside dbt, and proving it right. The first win is read-only: every incident in one domain, such as revenue models, gets a cross-system diagnosis and a blast radius. Your tests, alert routing, PR review and Dagster schedules stay the same. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "Elementary tells us which dbt test broke and drafts the code fix; Data Workers carries the fix for the data behind it through the stack, with an approval, and proves it held."
Getting started
Start with a pilot. Pick one domain whose incidents already live in Elementary, such as the revenue models behind the board dashboard, connect Data Workers to Elementary, the dbt project, Dagster and Postgres, and run at L1 so every incident gets a diagnosis and a blast radius. Then turn on the first write class at L2, such as model rebuilds with owner approval. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
How does Data Workers connect to Elementary? Over Elementary's API or MCP server today, reading incidents, tests, run history and lineage; dbt, Dagster and Postgres natively. You can also run Elementary's MCP server beside Data Workers in Claude or Cursor and ask both in one conversation.
Elementary's Triage & Resolution agent already opens a pull request. Why add Data Workers? The PR is the right fix for a code problem. Many dbt failures start before dbt runs. Data Workers traces past dbt to that cause, proposes the cleanup of rows already in the warehouse, queues the rebuilds of models built on them, routes the upstream change to its owner and verifies the result, with the PR in the same approval.
Does Data Workers delete or change rows in our warehouse? Data cleanups are proposed with their row counts, blast radius and a saved undo; the table's owner approves and applies them. Data Workers then queues the dependent rebuilds through your orchestrator, verifies the result and records the receipt.
Does Data Workers change anything in Elementary? No. Tests, monitors, alert routing and incidents stay with your Elementary admins and your dbt review. Data Workers reads Elementary, and its receipt is ready to link from the incident.
We run the open-source Elementary package, not Elementary Cloud. Does this still work? Yes. Data Workers reads your dbt project, its runs and your warehouse natively, so a failed test starts the same diagnosis. Elementary Cloud adds incidents, BI lineage and the MCP server, which your team's assistant uses beside Data Workers.
Does Data Workers trigger our Airbyte syncs? No. Ingestion changes, such as the sync-mode fix in the example, go to the connection's owner with the evidence attached. Data Workers queues dbt rebuilds through your orchestrator once the source is fixed and verifies the result.
Sources
- •Elementary, homepage ("Trusted Data for the AI Era"; Elementary Cloud, AI agents, Elementary Runtime banner), https://www.elementary-data.com/ (checked Oct 3, 2026)
- •Elementary Docs, Elementary AI Agent overview (specialized agents; "Every action the agent takes goes through a pull request or requires explicit confirmation"), https://docs.elementary-data.com/cloud/ai-agents/overview (checked Oct 3, 2026)
- •Elementary Docs, Triage & Resolution Agent, https://docs.elementary-data.com/cloud/ai-agents/triage-resolution-agent (checked Oct 3, 2026)
- •Elementary Docs, Performance & Cost Agent, https://docs.elementary-data.com/cloud/ai-agents/performance-cost-agent (checked Oct 3, 2026)
- •Elementary Docs, Elementary MCP Server (supported operations; coming-soon list), https://docs.elementary-data.com/cloud/mcp/intro (checked Oct 3, 2026)
- •Elementary Docs, MCP Setup Guide (remote endpoint, OAuth 2.1, access tokens), https://docs.elementary-data.com/cloud/mcp/setup-guide (checked Oct 3, 2026)
- •Elementary Docs, MCP Tools, https://docs.elementary-data.com/cloud/mcp/mcp-tools (checked Oct 3, 2026)
- •Elementary Docs, Hex integration (lineage via query history on BigQuery and Snowflake), https://docs.elementary-data.com/cloud/integrations/bi/hex (checked Oct 3, 2026)
- •Elementary Docs, Elementary Runtime (private beta), https://docs.elementary-data.com/cloud/features/elementary-runtime (checked Oct 3, 2026)
- •Elementary blog, "Introducing Elementary Runtime: Securely extending the reliability layer for AI" (Sep 17, 2026), https://www.elementary-data.com/post/introducing-elementary-runtime-extending-the-reliability-layer-for-ai-securely (checked Oct 3, 2026)
- •Elementary OSS repository (v0.26.0, Sep 10, 2026; Apache 2.0), https://github.com/elementary-data/elementary (checked Oct 3, 2026)
- •Elementary dbt package repository (0.26.0, Sep 8, 2026), https://github.com/elementary-data/dbt-data-reliability (checked Oct 3, 2026)
- •Airbyte Docs, sync modes (Incremental Append, Incremental Append + Deduped), https://docs.airbyte.com/using-airbyte/core-concepts/sync-modes/ (checked Oct 2, 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)