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

Your engineers already work in Cline. They start a task in Plan mode, let Cline read the repo and argue through the approach, then flip to Act mode and approve each file edit and command as it comes. Some run it in VS Code, some in JetBrains or Cursor, some in the Cline Desktop app, some from the CLI in a terminal or a GitHub Action, and a few run several agents at once on a Kanban board (a research preview), each card in its own worktree. Rules in .clinerules/ encode how your team writes code, servers from the MCP Marketplace sit in cline_mcp_settings.json, and Auto Approve decides what Cline may do without asking. Cline itself is free and open source for individual developers. Teams that need SSO, central billing and governance move to Cline Enterprise, where admins set inference providers, MCP servers and YOLO Mode for everyone from one remote configuration, with your own inference behind it. For writing and shipping code, that setup is excellent. The open question for a data team is what happens when the code Cline writes changes a column that a finance job, a dashboard and three other models depend on.

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

Key takeaways

• •Cline writes the code; Data Workers carries the data change. Cline stays the place engineers plan, act and approve. Data Workers supplies lineage, owners and blast radius, then applies the approved change in the warehouse and verifies it downstream.
• •Two files to start. A few entries in Cline's MCP settings connect Data Workers, and one rule in .clinerules/ tells Cline when to check impact, freshness, quality and PII before it edits.
• •Two locks on every write. Cline's approval prompt and autoApprove list gate the tool call; Data Workers' per-domain guardrail gates the change to the data. No agent approves its own work.
• •Admins set it once. On Cline Enterprise, remote configuration pushes Data Workers to every engineer as an always-enabled server, and the MCP allowlist keeps everything else out.
• •Climb one domain at a time. Start at L1 observe (answers and impact reports on pull requests), move to L2 propose, then L3 act reversibly where the record earns it.

Cline is the coding agent. Data Workers is the data crew behind it.

Cline is careful by design. It runs client side, reads files on demand rather than indexing your repository, and asks before it acts. What it can't see from the repo alone is the live estate: which Databricks jobs read a column, which Tableau workbook extract depends on it, which dbt models sit downstream, 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 tidy pull request that passes CI and breaks a reconciliation job 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 Cline just do this itself?

Focus and risk. Cline built an excellent product for one job: an open-source agent that helps engineers write, run and ship code with a human approving each step. Its design follows from that. Code and context stay on the engineer's machine, nothing is indexed or used for training, every action asks first, and checkpoints keep a shadow Git snapshot of the project files so any edit can be undone. That is exactly right for a coding agent.

Changing production data across systems is a different product. A checkpoint can restore files; it can't restore a Databricks table or a Tableau extract. The job needs to know that a column is read by a finance job in another repo, compute a blast radius before anything runs, route the approval to the owner of that domain rather than to whoever is at the keyboard, keep a rollback path inside the platform, check the numbers afterwards and leave a receipt an auditor can read. It also means taking responsibility for changes in systems Cline 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

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

Cline stays on top, where engineers plan, act 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 Cline, Cursor, Claude Code and Codex. Clone the open-source core (dataworkers-claw-community, Apache 2.0), run npm install, and add the agents you want under mcpServers, as our client setup docs describe. In the VS Code extension, open the MCP Servers icon in the Cline panel, go to Configure and choose Configure MCP Servers; that opens cline_mcp_settings.json. In the CLI, run cline mcp or edit ~/.cline/mcp.json. Example:

{
  "mcpServers": {
    "dw-context-catalog": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-context-catalog"],
      "disabled": false,
      "autoApprove": ["explain_table", "trace_cross_platform_lineage"]
    },
    "dw-schema": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-schema"],
      "disabled": false,
      "autoApprove": ["assess_impact"]
    },
    "dw-incidents": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-incidents"],
      "disabled": false,
      "autoApprove": ["diagnose_incident"]
    },
    "dw-quality": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-quality"],
      "disabled": false,
      "autoApprove": []
    },
    "dw-governance": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-governance"],
      "disabled": false,
      "autoApprove": []
    }
  }
}

The autoApprove lists hold only tools that read and analyse; none of them changes your data, which follows Cline's own advice to limit autoApprove to safe tools. Cline's global Auto Approve toggle for MCP servers stays off, as its docs recommend. Anything that changes data stays behind Cline's prompt and Data Workers' guardrail.

Roll it out with remote configuration. For a team, run Data Workers as a remote server over Streamable HTTP and push it from Cline Enterprise's remote configuration. remoteMCPServers with alwaysEnabled puts it in every engineer's Cline with the disable control locked, allowedMCPServers admits only the local servers you have vetted (the ids match the names in the example above), blockPersonalRemoteMCPServers keeps shadow servers out, and yoloModeAllowed: false keeps every write behind an approval. Example (<your-data-workers-host> is a placeholder for your own deployment; set the header from your secret store):

{
  "allowedMCPServers": [
    { "id": "dw-context-catalog" }, { "id": "dw-schema" }, { "id": "dw-incidents" },
    { "id": "dw-quality" }, { "id": "dw-governance" }
  ],
  "remoteMCPServers": [
    {
      "name": "Data Workers",
      "url": "https://<your-data-workers-host>/mcp",
      "alwaysEnabled": true,
      "headers": { "Authorization": "Bearer ${DW_TOKEN}" }
    }
  ],
  "blockPersonalRemoteMCPServers": true,
  "yoloModeAllowed": false
}

Engineers adding the remote server by hand set "type": "streamableHttp" in the entry; Cline defaults to legacy SSE when type is left out.

Add a Data Workers rule. Cline reads Markdown rules from .clinerules/ (or .cline/rules/) in the repo, and a paths list in the frontmatter makes a rule apply only to matching files. One short rule tells Cline when to call Data Workers. Example, saved as .clinerules/data-workers.md:

---
paths:
  - "models/**/*.sql"
  - "jobs/**"
  - "migrations/**"
---
- Before proposing a change to a dbt model, job or DDL, call assess_impact and list every downstream reader.
- Before trusting a query result, call explain_table on the tables it reads.
- Before opening a pull request, 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 Cline also reads. The rule fits Cline's Plan and Act flow: the impact check lands while the plan is being made, before Act mode edits a single file.

One request, from L0 to L4. Take one request an engineer types into Cline: "last night's dbt run failed the unique test on dim_customers, fix it". Here is what happens at each level, set per domain.

The same servers serve Cline CLI runs in a GitHub Action, agents on a Kanban board and automations built on the Cline SDK, so headless work carries the same checks as a change typed in the editor.

What changes for your team

Engineers keep their agent, their models 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. Platform admins govern Data Workers through the same Cline remote configuration they already use for models and MCP servers. And the audit trail builds itself from receipts instead of screenshots.

Keep Cline, or consolidate?

Keep Cline 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, Cline stays. It is the agent engineers chose, open source and model-neutral, 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 serves every other MCP client from the same agents. If parts of your team work in other tools, read You're on Roo Code, 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 the inference behind Cline (and, if you run it, Cline Enterprise), 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 reconciliation jobs, 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 Cline to touch data code every day, and many already run it headless in CI. 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: Cline, your inference contracts, Databricks, dbt, Tableau and your permission systems. Nothing is migrated. Our ROI guide shows how to size the return.

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

Getting started

Start with a pilot: connect Data Workers to Cline in one repo, add the rule, push the server through remote configuration, and run one domain such as dbt test failures 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 Cline's Plan and Act modes? No. Cline keeps planning and writing the code. Data Workers adds the data context during planning and carries the approved data change into the warehouse, then verifies and records it.

Where does the Data Workers config go in Cline? In the VS Code extension, Configure MCP Servers in the MCP Servers panel opens the MCP settings JSON (Cline's config docs list it as cline_mcp_settings.json under ~/.cline/data/settings/). The CLI reads ~/.cline/mcp.json and has a cline mcp wizard. For a team, push a remote Data Workers server from Cline Enterprise's remote configuration so every engineer gets the same one.

Which Data Workers tools should we auto-approve? Only tools that read and analyse, such as explain_table, trace_cross_platform_lineage, assess_impact and diagnose_incident. Keep YOLO mode off (Enterprise admins can enforce that with yoloModeAllowed: false) and leave every tool that changes data behind Cline's prompt and Data Workers' guardrail.

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

Can our admins control whether engineers use Data Workers? Yes. On Cline Enterprise, remoteMCPServers with alwaysEnabled pushes it to everyone, allowedMCPServers restricts local servers to approved ids, and blockPersonalRemoteMCPServers stops engineers from adding their own remote servers.

Do Cline checkpoints cover data changes? Checkpoints snapshot the project files, which is what a coding agent should cover. Data changes get their own rollback in Data Workers: every applied migration or rerun keeps a rollback path inside the platform and a receipt that says how to undo it.

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 Tableau, Jira and the rest of your stack, Data Workers connects over each tool's API or MCP server today.

Sources

Cline capabilities and statuses are current as of October 2, 2026, from Cline's own documentation: Cline overview (applications, editors, Enterprise; checked 2026-10-02), Installing Cline (Desktop, IDE, CLI, Kanban; checked 2026-10-02), Config (cline_mcp_settings.json location; checked 2026-10-02), MCP (config fields, transports, autoApprove, cline mcp; checked 2026-10-02), Auto Approve and YOLO Mode (checked 2026-10-02), Plan and Act (checked 2026-10-02), Checkpoints (checked 2026-10-02), Rules (.clinerules, paths, AGENTS.md; checked 2026-10-02), Kanban (research preview; checked 2026-10-02), Cline Enterprise (checked 2026-10-02), MCP Server Controls (checked 2026-10-02), Enterprise YOLO Mode controls (checked 2026-10-02), pricing (Open Source and Enterprise plans; checked 2026-10-02), Remote configuration (checked 2026-10-02), GitHub Actions integration (checked 2026-10-02), Cline SDK (checked 2026-10-02), Cline releases (Desktop, CLI and SDK releases through 2026-10-02; checked 2026-10-02) and the MCP Marketplace repository (checked 2026-10-02). Data Workers setup follows the client setup docs and the open-source dataworkers-claw-community repository (start-agent.sh and the agent tool definitions for assess_impact, check_freshness, trace_cross_platform_lineage, 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.