You're on OpenCode: give it governed data context and approved data changes

Your engineers already work in OpenCode. They run opencode in the terminal, press Tab to switch between the Build agent and the Plan agent, and hand searches to subagents like Explore. They pick the model: a frontier model through their own API key, a local model, or your company's AI gateway. The project's opencode.json sits in Git next to AGENTS.md, so the whole team shares the same agents, MCP servers and permission rules, and your platform team can pin settings in managed config that nobody can override. OpenCode, the open-source coding agent from Anomaly (the team behind SST; the repository moved from sst/opencode to anomalyco/opencode), is good at the job it was built for: reading a repository, writing the change and running it, asking before the actions you mark. Data Workers is the agentic data platform that sits behind it. Connected over MCP, OpenCode answers from your governed data context, and every change to production data goes through Data Workers' approvals and leaves a receipt.

Key takeaways

• •OpenCode is the coding agent. Data Workers is the data team it calls. OpenCode writes and runs the code with any model; Data Workers brings the context, owns the change in production and proves it worked.
• •One file wires it in. Data Workers agents are local MCP servers in the mcp block of opencode.json, and OpenCode is one of the four clients Data Workers tests against.
• •Two locks on every write. OpenCode's allow, ask and deny rules decide which Data Workers tools run without a prompt; Data Workers applies its per-domain guardrail, keeps a rollback point and writes the receipt.
• •A data agent for data work. Define a data agent in opencode.json with read tools allowed and change tools on ask, and engineers Tab into it when the question is about data, not code.
• •Nothing to migrate. OpenCode, your model provider, your repositories, Airbyte, Databricks, Dagster and Looker all stay. Data Workers works through each system's own API.

OpenCode is the coding agent. Data Workers is the data team it calls.

OpenCode reads your dbt project, your Dagster assets and your SQL, and writes the change you ask for. What it doesn't hold is the state of the estate: which table is canonical, when it last loaded, who owns it, what reads it downstream and who must approve a fix to sales data. That is what Data Workers holds. The Data Context Wizard keeps one governed context graph across ingestion, the lakehouse, orchestration and BI. The Data-Agents Swarm (20+ specialist agents) does the data work. The Autonomous Data-Conductor runs each fix end to end: detect, diagnose, fix, review, verify, remember. Spellbook Data Catalog (in preview) is where people review, approve, roll back and audit.

Here is one request, end to end. It is an illustration, not a customer case.

The engineer never left the terminal. OpenCode took the question, picked the tools, showed what it wanted to run and asked where the rules said to ask. Data Workers did the data work: it traced the stale table back through Dagster to the paused Airbyte connection, measured the blast radius into Looker, sent the secret to its owner, routed the backfill to the sales data owner, made the change reversibly and proved it with row counts. Meanwhile the Build agent can write the lasting fix, a freshness check on the Dagster asset, as a pull request your team reviews as usual.

Why doesn't OpenCode just do this itself?

Focus and risk. Anomaly built OpenCode as an open, model-agnostic coding agent, and its design is right for that job. It runs where the engineer runs it, talks to whichever model provider you configure and, in its own words, does not store your code or context data. Its permission system decides whether each tool call runs, asks or is blocked, per tool and per agent, and admins can lock those rules in managed config. Every one of those controls is about the session: what this agent, in this project, on this machine, may do.

Changing production data is a different product. A backfill into bronze.hubspot_deals touches systems OpenCode doesn't run, owned by people outside the session, with downstream readers nobody in the repository can see. Doing it safely takes context about every other system, a blast radius, an approver per domain, a rollback plan, verification and a receipt an auditor can read next quarter, plus liability for changes in tools Anomaly doesn't own, across whatever model each engineer picked. A general coding agent is right not to take that on. That is the product Data Workers is, and OpenCode is a great place for your engineers to ask for it.

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

Each point tool adds another console, another contract and another handoff. Data Workers covers the whole data lifecycle with one context, one approval flow and one audit trail. OpenCode owns a valuable slice of it: writing and running code with any model. It leads where that is the work: pipeline code.

How OpenCode and Data Workers work together

OpenCode stays on top, where engineers ask, plan, build and approve. Data Workers sits underneath as MCP servers: the Context Wizard, the Swarm, the Conductor and the guardrails. Spellbook is where people look: data owners review and approve changes, roll them back and read the audit trail.

Setup over MCP today. Every Data Workers agent is a standard MCP stdio server. Following the client setup docs, clone the repository and add the agents you need to the mcp block of opencode.json; in OpenCode's format, command is one array rather than a command plus args. OpenCode names each MCP tool <server>_<tool>, so remediate on the dw-incidents server is dw-incidents_remediate, and permission rules can target a whole server (dw-incidents_*) or a single tool. Example, in the OpenCode 1.x config format (opencode-ai 1.18.34, Sep 30, 2026):

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "dw-context-catalog": {
      "type": "local",
      "command": ["/path/to/dataworkers-claw-community/start-agent.sh", "dw-context-catalog"],
      "enabled": true,
      "timeout": 20000
    },
    "dw-incidents": {
      "type": "local",
      "command": ["/path/to/dataworkers-claw-community/start-agent.sh", "dw-incidents"],
      "enabled": true,
      "timeout": 20000
    }
  },
  "permission": {
    "dw-*": "ask"
  },
  "agent": {
    "data": {
      "description": "Data questions and data changes through Data Workers",
      "mode": "primary",
      "permission": {
        "edit": "ask",
        "dw-context-catalog_trace_cross_platform_lineage": "allow",
        "dw-context-catalog_blast_radius_analysis": "allow",
        "dw-incidents_diagnose_incident": "allow"
      }
    }
  }
}

Read it from the top. Every Data Workers tool asks by default in every agent, including Build and Plan. The data agent allows three read tools by name (trace_cross_platform_lineage, blast_radius_analysis and diagnose_incident) and still asks before remediate or any tool that changes something. Name read tools one by one rather than allowing a whole server, because a server like dw-context-catalog also carries tools that write. When the prompt appears, the engineer can approve once, approve for the rest of the session or reject. Keep remediate on approve once: Data Workers adds its own per-domain approval on top either way.

On OpenCode v2 (the @opencode/cli package, first released Sep 11, 2026), the same setup takes a new shape: servers go under mcp.servers, agents under agents, and rules become an ordered permissions list of action, resource and effect, where the last match wins. Tool names keep the <server>_<tool> form, so a rule like action dw-incidents_remediate, resource *, effect ask carries straight over.

Where the config lives is a rollout choice. A project opencode.json in Git gives everyone in the dbt repository the same agent and rules; a global ~/.config/opencode/opencode.json covers one engineer across projects. For a rule nobody can loosen, your platform team puts the Data Workers entries and dw-* permissions in managed config (/etc/opencode/ on Linux, /Library/Application Support/opencode/ on macOS, or an MDM profile), which OpenCode loads at the highest priority. For a shared Data Workers deployment, OpenCode also connects to remote MCP servers by url, with headers or OAuth through opencode mcp auth. The Data Workers on OpenCode page covers the open-source agents on OpenCode, and Data Workers + Claude Code, Cursor and Codex covers the same wiring in other coding agents.

The same request on the autonomy ladder. Autonomy is set per domain, on the ladder L0 manual, L1 observe, L2 propose, L3 act reversibly, L4 autonomous.

• •L0 manual. The engineer queries Databricks by hand and reads Airbyte and Dagster logs. OpenCode helps with the SQL; nobody has the lineage.
• •L1 observe. The data agent calls Data Workers and gets the stale table, the paused connection, the blast radius and the owners. Nothing changes.
• •L2 propose. Data Workers drafts the backfill with its blast radius and rollback plan. The sales owner approves in Spellbook; OpenCode asks the engineer before the tool call.
• •L3 act reversibly. For a domain you trust, Data Workers backfills missed sync windows on its own with the undo recorded first and writes the receipt. The engineer reads it in OpenCode.
• •L4 autonomous. The Conductor sees bronze.hubspot_deals go stale at 00:15, before Dagster runs, routes the credential to its owner, backfills once the connection is healthy and verifies it. An engineer reads the receipt in OpenCode the next morning.

OpenCode permissions and Data Workers guardrails stack. Turning one up never turns the other down, and an explicit deny in OpenCode holds even when an engineer starts a session with --auto.

What changes for your team

Engineers keep the agent and the model they already use. What changes is the work behind it: jobs that waited for a person with the right access and context now run through Data Workers, at the autonomy level each domain sets.

Data owners stop being pinged in Slack for "is this table fresh?" and start approving scoped changes in Spellbook. On-call stops starting from zero, because the first question typed into OpenCode already returns the cause and the blast radius. The platform team stops hand-rolling MCP setups per team: one opencode.json pattern in Git or managed config, one set of permission rules, one audit trail.

Keep OpenCode, or consolidate?

Keep OpenCode if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too. With a coding agent, keeping it is the usual answer: OpenCode is where your engineers write code with the model they trust, and Data Workers governs every data question and data change they send from it. The same Data Workers servers also answer in Claude, Codex and Gemini CLI, so teams that use more than one agent share one context and one audit trail. For the whole category, see Your company just rolled out AI assistants. Now what?.

The case for your CFO

Your engineers chose OpenCode and already use it on data work. The outcome to buy is governed answers to their questions and safe execution of the changes they ask for: fewer wrong numbers reaching leadership, incidents closed the same morning, and an audit trail for every change to production data, whichever model sits behind the terminal.

The risk story is plain. At L1, Data Workers reads and explains. At L2, it proposes and a named owner approves. At L3, it acts only where a change is reversible and keeps the rollback point. L4 is for domains you've trusted on evidence. Every action leaves a receipt: who asked, who approved, what changed, what it touched and how to undo it. OpenCode keeps its own allow, ask and deny rules, so every write has two locks. Nothing migrates. The cost model is on the ROI page; deployment and data handling are on the security page.

Why now: coding agents are already the front door for data work, and open-source agents put any model in that door. Every week without governed context means engineers guessing which table is fresh and production changes made with personal credentials and no receipt. The safety page covers what agents may do at each level, and the build-vs-buy page what it takes to wire this yourself.

The first win is small and visible: read-only Data Workers tools allowed in a data agent for one domain, so "why is this number wrong?" gets a traced answer. Start with a pilot; pricing has the details, and the pilot is credited in full against the first year.

The sentence to repeat upstairs: "Our engineers keep OpenCode and their model of choice; Data Workers gives it our governed data context and routes every data change through one approval flow with a receipt."

Getting started

Start with a pilot. Pick one domain where engineers already ask OpenCode about data, often sales or product analytics, add the Data Workers servers and a data agent to the project's opencode.json with read tools on allow and change tools on ask, and run it at L1 for the first weeks. Move that domain to L2 when the answers hold up, and to L3 for the fixes your team approves every time. See pricing; the pilot is credited in full against the first year.

FAQ

Does Data Workers bypass OpenCode's permission rules? No. OpenCode still decides whether each Data Workers tool runs, asks or is blocked, using the rules you set globally, per agent and in managed config. Explicit deny rules hold even in auto mode. Data Workers adds its own per-domain guardrail on top, so a change needs both.

Does it matter which model our engineers use in OpenCode? No. The model decides which tool to call; Data Workers decides what is true about your data and what a change is allowed to do. Context, approvals and receipts are the same whether the session runs on a frontier model, a local model or your internal AI gateway.

Can our admins make the Data Workers setup and rules mandatory? Yes. On OpenCode 1.x, put the mcp entries and the dw-* permission rules in the managed config directory or an MDM profile, which users and projects can't override; organizations can also publish default MCP servers through their .well-known/opencode endpoint. On v2, global and Console-managed policies can hard-deny a tool that a repository would allow.

Won't more tools crowd OpenCode's context? OpenCode's docs note that every MCP server adds to the context. Enable only the Data Workers agents a team needs, and use permission rules to keep a server's tools to the data agent. Many teams start with the context and incident agents and add more as domains move up the ladder.

Whose credentials touch Databricks? Data Workers' own credentials, scoped per domain, so no personal lakehouse tokens sit in a terminal. The engineer's identity is recorded on the receipt as the person who asked and approved, and secrets like the HubSpot token stay with the people who own them.

We could wire a Databricks MCP server into OpenCode ourselves. Why buy? You can connect a lakehouse. The hard parts are the context across systems, the blast radius, the approvals by domain, the rollback and the receipts. The build-vs-buy page walks through it.

Does OpenCode's /undo roll back a data change? /undo reverts file changes in the OpenCode session, which is the right scope for code. Data changes roll back through Data Workers: every change keeps a rollback point, and the receipt says how to undo it. Owners can do that from Spellbook.

Sources

• •Anomaly, OpenCode docs, "Intro" (open-source AI coding agent; terminal, desktop app, IDE extension; Build and Plan; /undo; AGENTS.md): https://opencode.ai/docs/ (checked Oct 2, 2026)
• •OpenCode homepage (any model, 75+ providers, privacy): https://opencode.ai/ (checked Oct 2, 2026)
• •OpenCode docs, "MCP servers" (mcp key, local and remote, command array, timeout, OAuth and opencode mcp auth, .well-known/opencode defaults, tools registered with the server name as prefix, e.g. my-mcp_search; context caveat): https://opencode.ai/docs/mcp-servers/ (checked Oct 2, 2026)
• •OpenCode docs, "Permissions" (allow, ask, deny; once, always, reject; --auto keeps explicit deny; defaults): https://opencode.ai/docs/permissions/ (checked Oct 2, 2026)
• •OpenCode docs, "Agents" (primary agents and subagents; per-agent permissions; permission keys match MCP tool names): https://opencode.ai/docs/agents/ (checked Oct 2, 2026)
• •OpenCode docs, "Config" (precedence, managed config files, macOS managed preferences via MDM): https://opencode.ai/docs/config/ (checked Oct 2, 2026)
• •OpenCode docs, "Enterprise" (does not store code or context data; share setting; central config with SSO and AI gateway): https://opencode.ai/docs/enterprise/ (checked Oct 2, 2026)
• •OpenCode docs, "IDE": https://opencode.ai/docs/ide/ (checked Oct 2, 2026)
• •OpenCode changelog (v1.18.31 to v1.18.34, Sep 14 to Sep 30, 2026): https://opencode.ai/changelog (checked Oct 2, 2026)
• •OpenCode v2 docs, "MCP servers" and "Permissions" (mcp.servers, <server>_<tool> names, ordered permissions rules, policies): https://opencode.ai/v2/docs/mcp-servers and https://opencode.ai/v2/docs/permissions (checked Oct 2, 2026)
• •npm, @opencode/cli (v2; 2.0.0 published Sep 11, 2026, 2.0.22 on Oct 2, 2026) and opencode-ai (1.18.34): https://www.npmjs.com/package/@opencode/cli (checked Oct 2, 2026)
• •OpenCode repository (MIT; moved from sst/opencode): https://github.com/anomalyco/opencode (checked Oct 2, 2026)
• •Data Workers, "Client Setup" (OpenCode is a tested client; mcp key; command array; agents start as MCP stdio servers via start-agent.sh): https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 2, 2026)
• •Data Workers, "Data Workers on OpenCode": https://dataworkers.io/on/opencode/ (checked Oct 2, 2026)
• •Data Workers open-source repository (tool definitions diagnose_incident and remediate in agents/dw-incidents; trace_cross_platform_lineage and blast_radius_analysis in agents/dw-context-catalog; start-agent.sh): https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 2, 2026)