You're on Windsurf (now Devin Desktop). Here's how Data Workers builds on it

Your engineers picked Windsurf, and on June 2, 2026 Cognition shipped it as Devin Desktop through a standard over-the-air update. The plan, the pricing, the extensions and the keybindings stayed the same. What moved is the center of gravity. The Agent Command Center is now the default surface, a Kanban board of every local and cloud agent an engineer has running. Spaces group the sessions, pull requests, files and context for one task. Devin Local, Cognition's successor to Cascade, is the built-in local agent; since September 8, 2026 it has fully replaced Cascade. It plans in Plan mode, works in its own worktree, spawns subagents and asks before it calls an MCP tool. Through the Agent Client Protocol, Codex, Claude Agent and OpenCode run inside the same board. For writing and shipping code, that is a strong setup. The open question for a data team is what happens when one of those agents changes a dbt model that a revenue dashboard, a finance export and three marts depend on.

That's where Data Workers comes in. Devin Desktop is where your engineers run their coding agents. Data Workers is the data crew those agents call: it knows what a change touches and carries it into production, scoped, approved, verified and recorded. Connected over MCP, Devin Local answers data questions from Data Workers' governed context, and every change to data goes through Data Workers' approvals and receipts. Nothing about Devin Desktop changes, and your engineers keep the editor they chose.

Key takeaways

• •The agents write the code; Data Workers carries the data change. Devin Local, subagents and cloud Devin sessions stay where engineers plan and delegate. Data Workers supplies lineage, owners and blast radius, then applies the approved change and verifies it downstream.
• •One file to start. Each Data Workers agent is a standard MCP stdio server, so one mcpServers entry per agent in mcp_config.json connects it. Devin Local also imports the MCP servers your engineers already set up under Windsurf.
• •Two locks on every write. Devin Local asks before any MCP tool call by default, and permission rules decide which Data Workers tools run without a prompt. Data Workers' per-domain guardrail then gates the change to the warehouse. No agent approves its own work.
• •Admins keep the controls they already use. The MCP allowlist, MCP registries and team permission rules in Devin Desktop's enterprise settings decide who can reach Data Workers and how.
• •Climb one domain at a time. Start at L1 observe (answers, lineage, incident diagnosis in the session), move to L2 propose, then L3 act reversibly where the record earns it.

Devin Desktop is the agent command center. Data Workers is the data crew behind it.

Devin Desktop knows your codebase. Its context engine indexes the repo, Devin Local reads your rules, AGENTS.md and skills, and the agent edits across files and runs commands inside a sandbox the admin can enforce. 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 DAG run 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 morning, end to end. This is an illustration, not a customer case.

Without that context, the engineer gets a correct-looking cast fix and still has to find every reader, chase the owner in Slack and run the backfill by hand. With it, the engineer approved one pull request, the owner approved one backfill, and the receipt explains the whole morning.

Why doesn't Devin Desktop just do this itself?

Focus and risk. Cognition built Devin Desktop for one job: giving engineers a single home for every coding agent they run, with a full IDE for reading and debugging what those agents ship. Its design reflects that. Devin Local reads and edits files inside the workspace by default, works on a branch or a worktree, and runs under a permission system and an OS-level sandbox that admins can enforce. Every MCP tool call asks first unless a rule says otherwise. That is exactly right for a coding agent.

Changing production data across systems is a different product. It needs to know that a column feeds a Looker Explore in another repo and a DAG run that only matters at month end. It needs a blast radius before anything runs, an approval routed to the owner of that data 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 Devin Desktop doesn't run. A sensible agent 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

Devin Desktop 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 Devin Desktop and Data Workers work together

Devin Desktop 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 servers. Every Data Workers agent is a standard MCP stdio server, so the same pattern from our client setup docs works in Devin Desktop. For Devin Local, put the entries in .devin/mcp_config.json to share them with the repo, in .devin/mcp_config.local.json for a personal override that stays out of git, or in ~/.config/devin/mcp_config.json to make them global for one engineer. Example:

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

Devin Local shares these files with Devin CLI, so engineers who prefer the terminal can run devin mcp add to write the same entries and devin mcp list to confirm they loaded. Coming from Windsurf? Devin Local imports MCP servers from the old ~/.codeium/windsurf/mcp_config.json, plus rules from .windsurf/rules/ and Windsurf skills, by default, so data servers your team set up before the rename carry over.

Set the gates. Devin Local prompts before every MCP tool call until a rule says otherwise. Most teams pre-approve the read tools and keep the rest of an agent on ask. Rules live in the permissions section of .devin/config.json, and a specific allow wins over a server-wide ask at the same level. Example:

{
  "permissions": {
    "allow": [
      "mcp__dw-incidents__diagnose_incident",
      "mcp__dw-context-catalog__trace_cross_platform_lineage"
    ],
    "ask": [
      "mcp__dw-incidents__*",
      "mcp__dw-schema__*"
    ]
  }
}

Let admins pin it down. On Teams and Enterprise, Devin Desktop's enterprise settings hold the controls that matter: turn MCP on or off, list Data Workers in Allowlisted MCP Servers, or publish it in your own MCP registry with enforcement on. Team permission rules carry the highest precedence, so an organization-level ask on Data Workers' write tools can't be relaxed by a project file. On Enterprise plans, an admin turns Devin Local on for members first. Legacy Windsurf Enterprise admins manage the same settings from the Windsurf dashboard.

One request, from L0 to L4. Take one request an engineer types into a Devin Local session: "the revenue_daily DAG run failed again, fix it". Here is what happens at each level, set per domain.

Our Windsurf for data engineering guide covers the agents from inside the editor, and the Claude Code, Cursor and Codex integration guide walks through the same wiring for the agents that also run inside Devin Desktop over ACP.

What changes for your team

Engineers keep their editor, their Agent Command Center 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 Devin Desktop, or consolidate?

Keep Devin Desktop 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, Devin Desktop stays. It is where engineers already run their agents, 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 every agent on the board from the same servers. If your team also hands whole tickets to cloud Devin, read You're on Devin, which covers the autonomous agent rather than the desktop. Teams that split across editors can read You're on Cursor and You're on Claude, or start from the hub, Your company just rolled out AI assistants. Now what?.

The case for your CFO

You already pay for Devin Desktop seats, and your engineers ship code faster because of them. The outcome Data Workers adds is that the data changes their agents 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: the move to Devin Desktop put more agents in front of each engineer, and each one can touch data code. 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 incident diagnosis and lineage answers inside Devin Local for one domain, at L1, with no change to how anyone works. What stays the same: Devin Desktop, 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 Devin Desktop; Data Workers makes every data change its agents write scoped, approved, verified and recorded."

Getting started

Start with a pilot: connect Data Workers to Devin Desktop in one repo, set the permission rules, and run one domain such as pipeline 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

Is Windsurf the same product as Devin Desktop? Yes. Cognition renamed Windsurf to Devin Desktop on June 2, 2026 and delivered it as an over-the-air update, keeping plans, pricing and extensions the same. windsurf.com now redirects to devin.ai/desktop, and Windsurf Enterprise admins can still manage settings from the Windsurf dashboard.

What happened to Cascade, and where do the Data Workers servers go now? Cognition retired Cascade on September 8, 2026, and Devin Local is now the built-in agent in Devin Desktop; a Continue in Devin Local prompt moves existing conversations over. Configure Data Workers once in Devin Local's mcp_config.json files. MCP servers your team had in the old Windsurf config are imported automatically.

Is this different from using Data Workers with Devin? Yes. This page covers Devin Desktop, where engineers run local agents and review their work. You're on Devin covers the autonomous cloud agent that takes tickets end to end. Both connect to the same Data Workers servers.

Can our admins control whether engineers use Data Workers? Yes. Enterprise settings for Devin Desktop let admins turn MCP on or off, allowlist specific servers, enforce an MCP registry and set team permission rules that sit above every user and project file. Where organization-level overrides are enabled, an organization's override replaces the enterprise baseline for that one control, so a stricter rule for the data organization stays scoped to it. List controls are replaced rather than merged, so copy any baseline entries you still want into the override.

Can Devin Local change production data on its own? Only within the autonomy level you set for that domain. Devin Local's permission prompt 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.

How do we keep credentials out of the repo? Put shared server entries in .devin/mcp_config.json and personal keys in .devin/mcp_config.local.json, which is gitignored. Data Workers uses its own scoped credentials to each platform, so engineers never paste warehouse keys into Devin Desktop.

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

Devin Desktop capabilities and statuses are current as of October 2, 2026, from Cognition's own pages: Windsurf is now Devin Desktop (June 2, 2026; checked 2026-10-02), Devin Desktop (checked 2026-10-02), Devin Local Agent (default agent, MCP permissions, enterprise controls; checked 2026-10-02), Cascade MCP Configuration (legacy agent, allowlist, registries; checked 2026-10-02), MCP Configuration (mcp_config.json locations and fields; checked 2026-10-02), Permissions (rule syntax and MCP patterns; checked 2026-10-02), Configuration Import (Windsurf config import; checked 2026-10-02), Local Agent Controls and Team Settings (admin controls; checked 2026-10-02), Agent Command Center (checked 2026-10-02), Devin Desktop changelog (Cascade removed in v3.9.19, September 8, 2026; checked 2026-10-02) and Context Awareness (context engine; checked 2026-10-02). Data Workers details come from our client setup docs, the published dw-claw package and the open-source Data Workers repository (checked 2026-10-02). Product names and statuses change quickly; if we've got something wrong, tell us and we'll fix it.