You're on Warp: give its agents governed data context and approved data changes

Data engineers live in the terminal, and many of yours now live in Warp. They run dbt build, open a Snowflake session and tail Airflow DAG runs in one window, and when something breaks they hand the job to Warp Agent, which runs commands in a real terminal, reads the live output and drives REPLs and database shells. Project conventions sit in AGENTS.md as Rules. Runbooks and shared commands live in Warp Drive as Notebooks and Workflows. MCP servers are added under Settings > Agents > MCP servers or in .warp/.mcp.json, and each Agent Profile decides what the agent may do on its own: apply code diffs, execute commands, call MCP servers. Cloud agents on Warp's Automation Platform (formerly Oz) pick up work from Slack, Linear, GitHub or a schedule. Warp calls itself an Agentic Development Environment, and it is very good at that job: taking an engineer from a prompt to a command that ran and a diff that landed. Warp is the agentic terminal; Data Workers, the agentic data platform, is the data team behind it. Connected over MCP, Warp's agents answer from your governed data context, and every change to production data goes through Data Workers' approvals and leaves a receipt.

Key takeaways

• •Warp is the agentic terminal. Data Workers is the data team behind it. Warp Agent runs the commands and writes the code; Data Workers brings the context, owns the change in production and proves it worked.
• •A few CLI server entries connect them. Add the Data Workers agents in Warp's MCP servers page or in .warp/.mcp.json, start them, and Warp lists their tools.
• •Two locks on every write. Warp's Agent Profile decides when Warp Agent asks before a call; Data Workers applies its per-domain guardrail, keeps a rollback point and writes the receipt.
• •Engineers stop carrying production credentials for data fixes. Data Workers acts with its own scoped access, and the engineer's name goes on the receipt.
• •Climb the ladder one domain at a time. Start at L1 observe, move to L2 propose, then L3 act reversibly, and let trusted domains run at L4 autonomous.

Warp is the agentic terminal. Data Workers is the data team behind it.

Warp Agent can read your dbt project, edit an Airflow DAG, run dbt build and read the failure, and query Snowflake from a database shell. What it doesn't hold is the state of the estate: which table is canonical, who owns it, what reads it downstream, what changed overnight in a source system, and who must approve a fix to revenue data. That is what Data Workers holds. The Data Context Wizard keeps one governed context graph across warehouses, dbt, 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 Warp. Warp took the question, chose the tools and asked before the write, as the profile says. Data Workers did the data work: it found the cause upstream in Fivetran, measured the blast radius through dbt into Tableau, routed the change to the person who owns revenue data, made the fix reversibly and proved it against the source. Meanwhile Warp Agent writes the lasting fix in the repository: a dedupe step in the staging model and a unique test on the opportunity key, opened as a pull request. That split, code in the repo and the data change in production, is the one our dbt integration guide walks through.

Why doesn't Warp just do this itself?

Focus and risk. Warp built an agentic development environment around the terminal, and its design is right for that job. Its controls are built around the agent and the machine. Agent Profiles set each permission (apply code diffs, read files, create plans, execute commands, call MCP servers) to "Agent decides", "Always ask", "Always allow" or "Never". A command denylist that includes rm, curl and eval takes precedence over the allowlist. Project MCP servers found in a cloned repo never start on their own, MCP config edits need approval, and shared configs have their secrets scrubbed. Business and Enterprise add SSO, admin data controls and governance. Those controls answer one question: what may this agent, in this terminal, run right now?

Changing production data is a different product. A fix to fct_pipeline touches systems Warp doesn't run, owned by people who aren't at the keyboard. Doing it safely takes context about every other system, a blast radius, an approver per domain, a rollback plan, verification after the fact and a receipt an auditor can read next quarter. It also means carrying the liability for changes in Fivetran, Snowflake and Tableau, tools Warp doesn't own. A development environment is right to leave that to a server built for it. That is the product Data Workers is, and Warp 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. Warp owns a valuable slice of it: running and writing code in the terminal. It leads where that is the work, in pipeline code.

How Warp and Data Workers work together

Warp stays on top, where engineers run commands, ask, delegate 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, so Warp runs it as a CLI server like any other. Clone the open-source core (dataworkers-claw-community, Apache 2.0), run npm install, and add a start-agent.sh entry for each agent you want, as our client setup docs describe. In Warp, open Settings > Agents > MCP servers (or "Open MCP Servers" from the Command Palette), add a server and paste the JSON. To keep it with the project, put the same block in .warp/.mcp.json at the repository root; for every project, use ~/.warp/.mcp.json. 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-quality": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-quality"]
    },
    "dw-incidents": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-incidents"]
    }
  }
}

Warp detects a project's .warp/.mcp.json in a cloned repo but never auto-spawns it, so start each server once from the MCP servers page, where Warp also lists its tools. If your engineers already use Data Workers in Claude Code or Codex, Warp reads those configs (~/.claude.json, ~/.codex/config.toml) and lists the same servers for you to enable. Then set the Agent Profile. Put the read servers (dw-context-catalog with trace_cross_platform_lineage and blast_radius_analysis, dw-schema with assess_impact, dw-quality with get_quality_score) on the MCP allowlist, and put dw-incidents, which carries remediate, on the MCP denylist, so Warp Agent asks before any call there. Add snowsql, dbt run --full-refresh and your warehouse write commands to the command denylist so Warp Agent asks before running them, and route production data changes through Data Workers instead of a personal login.

The open-source agents ship with built-in seed data, so the flow works on day one; your Data Workers deployment points the same tools at Snowflake, dbt, Airflow, Fivetran and Tableau with per-domain guardrails, approvals and receipts. For a shared deployment, Warp connects to a Streamable HTTP server by URL, with headers or OAuth. Share the server with your team from Warp Drive: Warp scrubs the env values and replaces them with variables, and teammates find it under Shared and fill in their own. Cloud agents on the Automation Platform take MCP servers from a central configuration applied across runs, so a scheduled or Slack-triggered agent reaches the same governed tools.

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 Snowflake by hand, diffs row counts and reads the Fivetran sync log. Warp Agent helps write the SQL; nobody has the lineage or the upstream change.
• •L1 observe. Warp Agent calls Data Workers and gets the cause, the blast radius and the owner. Nothing changes.
• •L2 propose. Data Workers drafts the fix with its blast radius and rollback plan. The revenue operations owner approves in Spellbook; Warp asks the engineer before the call.
• •L3 act reversibly. For a domain you trust, Data Workers handles duplicate replays like this one on its own, with a rollback point and a receipt. The engineer reads it in Warp.
• •L4 autonomous. The Conductor catches the duplicates at 02:05, before the 05:00 DAG run, fixes them and verifies the counts. A Warp cloud agent on a morning schedule posts the receipt to the team's Slack channel.

Warp's Agent Profiles and Data Workers' guardrails stack; turning one up never turns the other down.

What changes for your team

Engineers keep the terminal they already use. The jobs that used to wait for a person with the right access and context now run through Data Workers, at the autonomy level each domain sets.

Data owners stop answering "is this table right?" in chat and approve scoped changes in Spellbook. On-call starts with the cause and the blast radius from the first question typed into Warp. The platform team stops handing out warehouse write credentials to laptops for one-off fixes: one shared MCP server in Warp Drive, one Agent Profile, one approval flow and one audit trail.

Keep Warp, or consolidate?

Keep Warp if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too. With a terminal, keeping it is the usual answer: Warp is where your engineers write and run code, and Data Workers governs every data question and data change they send from it. The same Data Workers servers also answer in Claude and Gemini CLI, and Warp runs Claude Code, Codex and OpenCode inside it too, so teams that mix agents 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 already run data work from Warp, increasingly through Warp Agent. The outcome to buy is governed answers to their questions and safe changes to production: fewer wrong numbers reaching the forecast, incidents closed in the same morning, and an audit trail for every change to production data.

The risk story is plain. At L1, Data Workers only 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 reserved 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. Warp keeps its Agent Profiles, denylist and admin controls, so there are two locks on every write. Nothing migrates: Warp, Snowflake, dbt, Airflow, Fivetran and Tableau all stay. The cost case and how to model it are on the ROI page, and deployment and data-handling answers are on the security page.

Why now: agents that execute commands are already in your engineers' terminals, guessing which table is canonical without governed context. The safety page walks through what agents can and can't do at each level, and the build-vs-buy page covers what it takes to wire this yourself.

The first win is small and visible: read-only Data Workers tools in Warp 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 Warp; Data Workers gives its agents 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 Warp Agent about data, often revenue or product analytics, add the Data Workers servers to Warp with the read servers on the Agent Profile's MCP allowlist and dw-incidents on its MCP denylist, 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 Warp's Agent Profiles? No. Warp still decides when Warp Agent asks, from the profile's MCP allowlist and permissions, and the command denylist still wins over the allowlist. Data Workers adds its own per-domain guardrail on top, so a change needs both.

Should we let Warp Agent "Always allow" calls to Data Workers? For the read servers, yes, that is the usual setup. Put the server that carries remediate on the MCP denylist so Warp asks every time, and let Data Workers' guardrail decide who else must approve.

Can Warp's cloud agents use Data Workers too? Yes. The Automation Platform takes MCP servers from a central configuration applied across runs, so a scheduled or Slack-triggered cloud agent calls the same governed tools. Point it at your shared Streamable HTTP deployment.

Whose credentials touch Snowflake? Data Workers' own credentials, scoped per domain, so no personal warehouse write keys need to sit in a terminal. The engineer's identity is recorded on the receipt as the person who asked and approved.

How do we share the setup without leaking secrets? Share the server from Warp Drive. Warp scrubs the env values and replaces them with variables; each teammate supplies their own when they install it. Keep secrets out of a committed .warp/.mcp.json.

Won't more tools crowd the agent's context? Add only the agents a team uses. A good start is lineage, schema, quality and incidents, adding more as domains move up the ladder.

We could point Warp at a Snowflake MCP server ourselves. Why buy? You can connect a warehouse. 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.

Sources

• •Warp, documentation home ("open source Agentic Development Environment"; product areas): https://docs.warp.dev/ (updated Sep 24, 2026; checked Oct 2, 2026)
• •Warp, Agents overview (Warp Agent, GA; Warp Agent CLI; cloud agents; third-party CLI agents): https://docs.warp.dev/agents/ (checked Oct 2, 2026)
• •Warp, Agent Profiles and permissions (permission options, command allowlist and denylist, MCP allowlist): https://docs.warp.dev/agents/using-agents/agent-profiles-permissions (checked Oct 2, 2026)
• •Warp, Model Context Protocol (CLI and URL servers, .warp/.mcp.json, sharing, no auto-spawn, config approval, OAuth): https://docs.warp.dev/knowledge-and-collaboration/mcp (checked Oct 2, 2026)
• •Warp, Rules (Global Rules, AGENTS.md project rules): https://docs.warp.dev/knowledge-and-collaboration/rules (checked Oct 2, 2026)
• •Warp, Warp Drive (Workflows, Notebooks, Prompts, Environment Variables; team sharing): https://docs.warp.dev/knowledge-and-collaboration/warp-drive/ (checked Oct 2, 2026)
• •Warp, cloud agents and the Automation Platform (triggers, environments, MCP, formerly Oz): https://docs.warp.dev/platform/ (checked Oct 2, 2026)
• •Warp, pricing and plans (Business and Enterprise controls, zero data retention): https://www.warp.dev/pricing (checked Oct 2, 2026)
• •Warp, client repository (open source; MIT and AGPL v3): https://github.com/warpdotdev/warp (checked Oct 2, 2026)
• •Warp, 2026 changelog (Warp Agent CLI, cloud runners, Factories Early Access): https://docs.warp.dev/changelog/2026/ (checked Oct 2, 2026)
• •Data Workers, open-source client setup (clone, start-agent.sh entries in mcpServers): https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 2, 2026)
• •Data Workers, open-source core and agent tool definitions: https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 2, 2026)