You're on Cursor. Here's how Data Workers builds on it

Your engineers already live in Cursor. They open Agent for a quick refactor, switch to Plan Mode when a change touches many files, and hand longer tickets to Cloud Agents (formerly Background Agents) from Linear, Slack or a GitHub comment. Since September, Projects (in beta) lets a coordinator agent take on months-long work such as a migration through subagents. Project rules in .cursor/rules encode how your team writes code, an admin distributes approved MCP servers from the dashboard, and run modes decide what Cursor may do without asking. For writing and shipping code, that setup is excellent. The open question for a data team is what happens when the code Cursor writes changes a table that a dashboard, a finance export and three other models depend on.

That's where Data Workers comes in. Cursor is where your engineers write the change. Data Workers, the agentic data platform, knows what that change touches and carries it into production: scoped, approved, verified and recorded. Connected over MCP, Cursor answers data questions from Data Workers' governed context, and every change to data goes through Data Workers' approvals and receipts. Nothing about Cursor changes. Your engineers keep the editor they chose.

Key takeaways

• •Cursor writes the code; Data Workers carries the data change. Cursor stays the place engineers ask, plan and delegate. Data Workers supplies lineage, owners and blast radius, then applies the approved change and verifies it downstream.
• •Two files to start. One entry per agent in .cursor/mcp.json connects Data Workers, and a project rule in .cursor/rules/ tells Cursor's agent when to check lineage, freshness, quality, PII and schema impact before it edits.
• •Two locks on every write. Cursor's own approval prompt and run modes gate the tool call; Data Workers' per-domain guardrail gates the change to the warehouse. No agent approves its own work.
• •Cloud Agents get the same context. Team MCP servers configured in Cursor's dashboard reach Cloud Agents, so a ticket picked up from Linear carries the same impact checks as a change typed in the editor.
• •Climb one domain at a time. Start at L1 observe (answers, lineage, impact reports on pull requests), move to L2 propose, then L3 act reversibly where the record earns it.

Cursor is the editor. Data Workers is the data crew behind it.

Cursor knows your codebase. It indexes the repo, reads your rules and AGENTS.md, edits across files and runs commands in a sandbox. What it can't see from the repo alone is the live estate: which Snowflake objects a dbt model really feeds, which Looker Explore still reads a column, which Airflow task exports it to finance, and who owns each one. Data Workers keeps that in one governed context graph and does the data side of the work through 20+ specialist agents.

Here is one change, end to end. This is an illustration, not a customer case.

Without that context, the same ticket is a clean-looking pull request that passes CI and breaks a finance export at month end. With it, the engineer approved one pull request, the owner approved one change, and nobody chased anyone in Slack.

Why doesn't Cursor just do this itself?

Focus and risk. Cursor built a superb product for one job: helping engineers write, review and ship code. Its design reflects that. The agent works on files and a branch, checkpoints are "stored locally and separate from Git", and every MCP tool call goes through an approval prompt or a run mode the team controls. That is exactly right for an editor.

Changing production data across systems is a different product. It needs to know that a column is read by a Looker Explore in another repo and a DAG run that only fires at month end. It needs a blast radius before anything runs, an approval routed to the owner of that domain rather than to whoever is at the keyboard, a rollback path inside Snowflake, a check that the dashboard is right afterwards, and a receipt an auditor can read. It also means taking responsibility for changes in systems Cursor doesn't run. A sensible editor vendor leaves that to the server on the other end of the MCP connection. That server is Data Workers.

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

Cursor goes deepest on writing and refactoring pipeline code. Data Workers covers every stage of the data lifecycle around that code. 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.

How Cursor and Data Workers work together

Cursor stays on top, where engineers ask, plan, delegate and approve. Data Workers sits underneath over MCP: the Data Context Wizard answers from the governed graph, the Data-Agents Swarm does the work, the Autonomous Data-Conductor runs each fix end to end, and Spellbook Data Catalog (in preview) is where people review, roll back and audit.

Connect the MCP server. Every Data Workers agent is a standard MCP stdio server, so the same server works in Cursor, Claude Code, Codex and OpenCode. Clone the open-source core (dataworkers-claw-community, Apache 2.0), run npm install, and add the agents you want to the project's .cursor/mcp.json (or add them through Cursor Settings to use them in every project), as our client setup docs describe. Restart Cursor after editing. Example:

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

For a team, run Data Workers as a remote server over Streamable HTTP and add it under Team MCP Servers in Cursor's dashboard (Plugins & MCPs). Team MCP servers are available to Cloud Agents, and adding the server to the team marketplace lets every engineer install it in the editor and CLI too. Keep the token out of the repo with Cursor's ${env:NAME} interpolation. Example (placeholder host):

{
  "mcpServers": {
    "data-workers": {
      "url": "https://<your-data-workers-host>/mcp",
      "headers": { "Authorization": "Bearer ${env:DW_TOKEN}" }
    }
  }
}

Add a Data Workers rule. Cursor's project rules are .mdc files in .cursor/rules, versioned with the repo. One short rule tells Cursor's agent when to call Data Workers: trace lineage before editing a dbt model, check load lag against its baseline before trusting a query, run a quality check before merge, diagnose before patching anything described as broken, check policy on code that touches personal data, and assess schema impact on migrations and DDL. Example:

---
description: Data Workers checks for data changes
globs: models/**/*.sql, migrations/**, dags/**
alwaysApply: false
---
- Before editing a dbt model or DDL, call assess_impact and list every downstream reader.
- Before trusting a query result, call explain_table on the tables it reads.
- Before merge, call run_quality_check on changed models.
- When something is described as broken, call diagnose_incident before patching.
- On code that adds a column holding personal data, annotate the column and ask the data owner before merge.

Prefer one file? Put the same lines in AGENTS.md, which Cursor also reads. On Team and Enterprise plans, an admin can promote the guidance to Team Rules, which take precedence over project rules.

Set the gates. Cursor asks for approval before using MCP tools by default, and MCP calls follow the same run modes as terminal commands. We recommend putting read tools such as lineage, freshness and impact on Cursor's allowlist so they run without a prompt, and keeping anything that changes data behind Cursor's approval and Data Workers' guardrail. On Enterprise, the MCP Allowlist approves Data Workers by command or URL pattern, a tool allowlist sets which of its tools run automatically, and team settings take precedence over individual and project configuration.

One request, from L0 to L4. Take one request an engineer types into Cursor: "the orders_daily freshness check failed again, fix it". Here is what happens at each level, set per domain.

Our Claude Code, Cursor and Codex integration guide walks through the wiring for all three coding agents side by side, our earlier Cursor + Data Workers overview covers the agents from inside the IDE, and the Cursor for data engineering MCP guide covers MCP basics in Cursor.

What changes for your team

Engineers keep their editor and their habits. What changes is the work around each data change: the hunt for who reads a column, the Slack thread to find an owner, the manual backfill, the evidence an auditor asks for months later.

The data platform team stops being the human lookup service for lineage and ownership. Analytics engineers ship dbt changes with the impact already attached. Owners approve changes in one place with the blast radius in front of them. And the audit trail builds itself from receipts instead of screenshots.

Keep Cursor, or consolidate?

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

For most data teams, Cursor stays. It is the editor engineers chose, and Data Workers is built to sit underneath it. What teams tend to consolidate are the extra tools around data changes: the separate lineage lookup, the impact-analysis script someone maintains, the spreadsheet of who owns what, the manual runbook for backfills. Data Workers runs that work with one context, one approval flow and one audit trail, and it serves Claude Code, Codex and every other MCP client from the same agents. If parts of your team work in other tools, read You're on Claude and You're on Codex, or start from the hub, Your company just rolled out AI assistants. Now what?.

The case for your CFO

You already pay for Cursor seats, and your engineers ship code faster because of them. The outcome Data Workers adds is that the data changes they ship are right the first time: fewer broken dashboards, fewer month-end surprises in finance exports, and less senior engineering time spent tracing who reads what.

The risk story is plain. At L1, agents only read and explain. At L2, they propose and a named owner approves. At L3, they act only on pre-approved, reversible classes of change, with rollback ready. Every action leaves a receipt with who asked, who approved, what changed and how to undo it. Our safety guide covers exactly what an agent can and can't do at each level, and the security and deployment guide covers where your data goes.

Why now: your engineers already ask Cursor's agent to touch data code every day. The question is whether those changes land with context and an approval trail or without them. Building that layer in house is possible, and our build-vs-buy guide lays out what it takes.

The first win is impact reports on every dbt pull request in one repo, at L1, with no change to how anyone works. What stays the same: Cursor, Snowflake, dbt, Airflow, Looker and your permission systems. Nothing is migrated. Our ROI guide shows how to size the return.

The sentence to repeat upstairs: "Our engineers keep Cursor; Data Workers makes every data change it writes scoped, approved, verified and recorded."

Getting started

Start with a pilot: connect Data Workers to Cursor in one repo, install the rules, and run one domain such as freshness incidents or schema changes from L1 to L2 with your own engineers and owners. See pricing for the pilot terms; the pilot is credited in full against the first year.

FAQ

Does Data Workers replace Cursor's agent or Cloud Agents? No. Cursor's Agent, Plan Mode and Cloud Agents keep writing the code. Data Workers adds the data context and carries the approved data change into the warehouse, then verifies and records it.

Do we put Data Workers in the project `.cursor/mcp.json` or the global one? Project config suits a single repo and travels with it in version control. Global ~/.cursor/mcp.json (or Cursor Settings) suits one engineer across many repos. For a team, add a remote Data Workers server under Team MCP Servers in Cursor's dashboard, where Cloud Agents pick it up, and add it to the team marketplace so every engineer installs the same one.

Can our Cursor admins control whether engineers use Data Workers? Yes. On Enterprise, the MCP Allowlist approves servers by command or URL pattern, tool allowlists decide which Data Workers tools auto-run, and team run-mode settings take precedence over individual and project settings.

Can Cursor's agent change production data on its own? Only within the autonomy level you set for that domain. Cursor's approval prompt or run mode gates the tool call, and Data Workers' guardrail gates the change itself. At L2 a named owner approves every change; at L3 only pre-approved, reversible classes run, each with rollback ready and a receipt.

What do the Data Workers rules add if Cursor can already call the MCP tools? They tell the agent when to call them. Without a rule, the agent may edit a dbt model without checking who reads it. With the rule in place, lineage, freshness, quality, PII and schema checks run at the moments they matter.

How do we keep credentials out of the repo? Use Cursor's ${env:NAME} interpolation or envFile for local stdio servers, and OAuth or a bearer token read from the shell environment for the remote server (Cursor's envFile applies to stdio servers only). Data Workers uses its own scoped credentials to each platform, so engineers never paste warehouse keys into Cursor.

Which data platforms does this work with? Data Workers runs control-plane connectors for Snowflake, Databricks and BigQuery, and reads dbt manifests and runs. For Airflow, Looker and the rest of your stack, Data Workers connects over each tool's API or MCP server today.

Sources

Cursor capabilities and statuses are current as of October 2, 2026, from Cursor's own documentation: Model Context Protocol (config locations, transports, approvals, MCP Allowlist, team distribution; checked 2026-10-02), Cloud Agents (formerly Background Agents; checked 2026-10-02), Agent overview (tools and checkpoints; checked 2026-10-02), Plan Mode (checked 2026-10-02), Run modes (checked 2026-10-02), Rules (project, team and user rules, AGENTS.md; checked 2026-10-02), Pricing (Teams and Enterprise features; checked 2026-10-02) and the changelog (Self-hosted machines, Sep 2, 2026; Cursor Projects in beta, Sep 10, 2026; Rollouts and Security Review, Sep 23, 2026; checked 2026-10-02). Data Workers setup follows the client setup docs and the open-source dataworkers-claw-community repository (start-agent.sh, docs/setup/cursor.md and the agent tool definitions for assess_impact, check_freshness, run_quality_check, diagnose_incident, scan_pii and rollback_migration; checked 2026-10-02). Product names and statuses change quickly; if we've got something wrong, tell us and we'll fix it.