For dbt
Data Workers runs the detect, diagnose, fix, review and verify loop on a dbt project when nobody is at the keyboard. A failing test is diagnosed against the model that caused it, a fix is proposed as a change to the project, and a named human approves anything irreversible, with the downstream blast radius attached.
For a team whose transformation layer is dbt, on Snowflake, BigQuery or Databricks, where a model that compiles is not the same thing as a model that is right.
Last updated: September 10, 2026 · Dhanush Shetty, founder, Data Workers
None of these is a dbt defect. They are the failures a busy estate produces, and the hours between one of them starting and somebody verifying a fix are what this platform is for.
A model that compiles and still ships wrong numbers
Valid SQL, green tests, and a join that fans out because an upstream table stopped being unique on its key. Nothing fails, and the error reaches a dashboard before it reaches a person.
A source freshness failure nobody triages
Freshness has been failing on one source for a week. It is in the run log every day. Because nothing downstream has visibly broken yet, it has become part of the scenery.
A pull request whose downstream blast radius nobody can see
The diff is four lines in a staging model. What it touches is eleven models, two exposures and a dashboard that the finance team reads on Mondays. The reviewer approving it cannot see that from the diff.
A model with no description that everyone depends on
It has been the busiest node in the DAG for two years. Its description field is empty, the person who wrote it has left, and the next change to it will be made by somebody guessing.
Alerts are not fixes. Detection tells you the first of those sentences. The rest is the work.
Runs the loop
Autonomous Data-Conductor
The Conductor watches run and test outcomes and starts work without waiting for a human. On a failed run it reads the model, the compiled SQL, the test that failed and the lineage around it, forms a diagnosis, and produces the change to the project it believes fixes it. An autonomy dial governs how far it goes on its own: at the lowest setting it stops at a proposal, higher up it may run the dry run and open the change for review, and anything irreversible always waits for a named approver regardless of the setting. The dial is a policy you set, not a claim about what it has already done unattended in production.
Does the work and writes
Data-Agents Swarm, 20 specialised agents
On a dbt project the data change review agent is the one teams notice first: it reads a proposed change and reports what it breaks downstream, across models, exposures and the dashboards beyond them, which is the thing a diff cannot show you. Alongside it the incident debugging, data quality and schema evolution agents handle the failures that reach the run log, and the catalog agent fills in the descriptions nobody has written.
What the agents reason on
Data Context Wizard
The Context Wizard holds the column-level lineage that dbt's own graph stops short of, extended past the exposures into what actually consumes the data, plus ownership, metric definitions and the record of past corrections, every fact provenance-stamped. That is what makes a blast radius real rather than a list of model names.
Where humans approve and audit
Spellbook Data Catalog, in preview
Spellbook is the catalog the agents write and keep current, and the plane where a human approves a change and reads back what happened. It complements the docs dbt generates rather than replacing them. Spellbook is in preview, so treat it as a direction rather than a shipped surface.
What each module has to do to qualify as this kind of product, stated generically so you can use it on any vendor: the autonomous agentic data platform.
The first three steps need no form, no account and no key we issue. The open-source core is Apache-2.0: 11 agents and 160+ MCP tools that read, analyse and recommend.
The full list of who we are not for, including the cases where the honest answer is to buy something else: should you use Data Workers.
Is this a replacement for dbt?
No. dbt stays your transformation layer and your runs stay your runs. Data Workers reads the project, the compiled SQL, the run and test results and the lineage, and produces changes to the project that a named human reviews and approves, with the downstream blast radius attached.
How is change review different from a pull request reviewer?
A pull request reviewer is a merge gate on a change a human already wrote. It reviews one step. Data Workers also detects the problem that motivated the change, proposes the change itself, and verifies the outcome after it lands, which is the rest of the loop. Recce and similar tools do the review step well; this is a superset and is priced as a platform, so if a merge gate is all you need, buy the merge gate.
Which warehouses does this work with?
Snowflake, BigQuery and Databricks, with dbt as the transformation layer, and the context graph spans them rather than being native to one. There are dedicated pages for each warehouse linked at the foot of this one.
Two next steps
Run the read-only agents on dbt yourself, free: clone the open-source core.
Or bring one real incident to a 45-minute session and watch the approval gate stop the agent: book a time. Pilot Program $7,500 one-time, then Scale from $1,000 per month, no usage meter, as published on 10 September 2026. Pricing.