Data engineering inside your coding agents
Engineers already work in Claude Code, Cursor and Codex, but those agents see the code, not the data estate. Data Workers connects them over MCP to governed context, lineage and the back-office agents, so a change arrives with its impact, its tests and a named approver.
Before and after
| Today | With Data Workers |
|---|---|
| The coding agent writes SQL from the schema in front of it and guesses which table is the trusted one | It asks for the definition, the trusted source and the owner before it writes a line |
| A model change looks safe in the pull request and breaks a dashboard on Monday | The agent sees every downstream model, dashboard and consumer before the change is proposed |
| Each engineer wires up their own MCP servers and credentials | One shared setup, with the permissions and personal-data rules your platform team sets |
| A write from an agent session has no approver and no record outside shell history | Writes go through the same approval path as everything else and leave a signed record |
| Data back-office work waits in a ticket queue because the coding agent cannot see the estate | Engineers do it from the editor they already use |
Your engineers adopted coding agents without asking the data team, and those agents now touch dbt projects, pipelines and migrations. They are good at code and blind to the estate around it. Connecting them to a governed data layer is a smaller job than most teams expect: the Claude Code, Cursor and Codex setup guide walks through the config for each client, and the coding agents overview covers what they can ask once connected.
How it works
1. Connect the agent your engineers already use
Data Workers plugs into Claude Code, Codex, Cursor and OpenCode with a short config file, not a platform rollout. The open-source core is free to self-host under Apache-2.0: 11 agents and 160+ MCP tools that read, analyse and recommend. Connections start with read-only credentials, and get_connector_status tells the engineer exactly what is missing.
2. Ask with the estate in view
Before the coding agent writes a query, the Data Context & Catalog agent answers from your actual estate: explain_table for what a table means, get_table_schema_for_sql for the trusted columns, get_lineage for where it comes from. blast_radius_analysis shows every downstream model, dashboard and consumer a change would touch.
3. Change through one approval path
When the engineer asks for a write, the request comes back as a proposal with the full change, what it affects and how to undo it. create_quality_tests_for_pipeline adds the tests, request_governance_review sends it to the named approver, and get_audit_trail shows afterwards what ran and who approved it. A coding agent gets no side door: acting on production comes with the paid platform, and goes through approval.
The impact metrics we move
- •Finding the trusted table and its owner: from about 2 h to 1 min
- •Mapping what a model change breaks: from about 4 h to 10 min
- •A change reaching its approver: from about 2 days to 10 min
Where teams start
- •A dbt project. Connect the coding agent for one repo and ask for the impact of the next model change before the pull request opens.
- •Claude Code for the platform team. Engineers ask about tables, lineage and freshness without leaving the terminal.
- •Cursor for analytics engineers. Definitions and trusted sources show up while the SQL is written (see you're on Cursor).
- •Codex or OpenCode on pipelines. New pipelines come with validation and tests, and deploys go through approval to the orchestrator you connect (see you're on Codex).
- •Read-only first. Run the open-source core inside your environment, see what the agents would suggest, then add approved writes for one domain.
What powers it
The coding agent is the front end; the work sits behind it. The Data Context Wizard supplies the shared understanding of your estate that every answer starts from, and the Spellbook Data Catalog holds the owners, definitions and governance rules the agent is held to. The Data Context & Catalog, Quality Monitoring, Pipeline Building and Data Access & Governance agents of the Data-Agents Swarm do the work, and the Autonomous Data-Conductor keeps it inside the autonomy each domain allows. Autopilot Routines, Missions and Standards use the same approvals and audit trail. See how it shows up in one governed data layer for every AI agent, safe agent writes to production, how data platform and fleet data teams go agentic and the data discovery use case.
The climb: from assisted to autonomous to agentic
Every transformation runs on the same ladder from our thesis. L0 to L2 run today: the coding agent answers from governed context, proposes changes, and acts after a person approves, domain by domain. L3 and L4 are where a domain can go on evidence, once its own record of approved changes earns it.
The pilot
- •Scope. One coding agent, one repo and one domain, connected over MCP.
- •First week. Agents start by watching and suggesting. Engineers ask questions from their editor, and the agents show the answer and the proposal they would have made, with receipts.
- •By week two. Questions about tables, lineage, quality and impact are answered on their own for the whole domain; every change still goes to a named approver.
- •At day 30. We review the impact metrics against your baseline:
- •Finding the trusted table and its owner: from about 2 h to 1 min
- •Mapping what a model change breaks: from about 4 h to 10 min
- •A change reaching its approver: from about 2 days to 10 min
- •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.
FAQ
Can the coding agent change production data on its own? No. Agents read freely but write only through one approval path, with no side door. Anything irreversible waits for a named person, and the highest-risk changes need two different people.
Why not build this ourselves with Claude Code and a few MCP servers? You can have a demo in a week. The year goes into lineage, approvals, rollback and receipts, which is the part this post covers.
Which coding agents does it work with? Claude Code, Codex, Cursor and OpenCode, plus other MCP-capable clients. Setup is a short config file for each.
Which model does it use? The one you choose. The open-source core runs inside your environment, and the same permissions and personal-data rules apply to the coding agent as to any other.
What if the agent proposes the wrong change? The approver rejects it, and every proposal shows how to undo it.