You're on Writer: Add Data Workers as a Custom Connector So Every Brief, Deck and Dashboard Runs on Governed Numbers
Your teams build agents and playbooks in Writer. Add Data Workers as a custom MCP connector so every brief uses governed, verified numbers and data breaks get fixed with a receipt.
Your marketing and revenue teams live in Writer now. Someone describes the outcome in WRITER Agent and it plans the work, pulls from connectors and hands back a finished deck, brief or spreadsheet. The best of that work becomes a playbook in the team library that runs on a schedule-based trigger, and since September 15, 2026 a playbook step can pause for a reviewer's approval and WRITER Agent can build shareable dashboards on live data from your connectors. Enterprise Brain keeps the voice and the standards, Knowledge Graph holds the documents, and AI Studio gives IT one place to govern connectors, guardrails and spend. Writer is where your business teams build agents that write and act. Data Workers is the data team behind the numbers those agents use.
A Writer playbook turns a number into a polished, on-brand asset that reaches a CRO, a board or a customer, so the number underneath has to be right. Data Workers gives every agent a governed definition and fresh, verified data over MCP, and fixes the data when it breaks.
Key takeaways
- •Writer keeps its job. WRITER Agent, playbooks, Enterprise Brain, Knowledge Graph and AI Studio stay as they are. Data Workers is one custom MCP connector an admin adds under Connectors & Tools.
- •Every number gets a definition and a freshness signal. Before a playbook drafts, it asks Data Workers what the metric means, whether it is fresh and whether an incident is open.
- •Fixes pass two locks. In Writer, admins choose which tools are on and a step approval holds the run for a reviewer. In Data Workers, each data change goes to a named approver in Spellbook, stays reversible and leaves a receipt.
- •The MCP gateway covers it from day one. Every call to Data Workers flows through Writer's MCP gateway, which validates identity against your organization's access controls, and can travel over a private endpoint.
- •Setup is an admin task. Create custom connector, MCP server, server URL, authentication, teams, read tools on. Write tools follow one domain at a time.
- •Start with a pilot. One scheduled playbook, read-only, then one write class in one domain, on the autonomy ladder from L0 manual to L4 autonomous.
Writer is where your business teams build agents that write and act. Data Workers is the data team behind the numbers those agents use.
Writer's connector library reads like a revenue team's stack: Salesforce, HubSpot, Gong, ZoomInfo, PitchBook, FactSet, and on the data side Snowflake, Databricks and Google BigQuery. Writer's own connector page pitches Snowflake as a way to "access customer data and metrics automatically from WRITER playbooks." That is exactly where governed definitions matter: the warehouse returns whatever last night's models produced, and only lineage and checks can tell a real drop from a broken filter.
Here is a Monday morning with Data Workers connected. This is an illustration, not a customer case.
| Time | System | What happens |
|---|---|---|
| Sun 23:00 | Salesforce | RevOps renames the Closed Won stage to Closed Won New and adds Closed Won Expansion |
| 01:00 | Fivetran | The nightly sync lands the new stage values in Snowflake |
| 02:00 | Snowflake + dbt | The job succeeds; fct_bookings still filters on the old stage name, so 312 won deals drop out and Q3 bookings look down 38% |
| 02:15 | Data Workers | A volume check against Salesforce finds the gap; Data Workers traces it through lineage to the filter and opens an incident |
| 07:00 | WRITER Agent | The Weekly revenue brief playbook starts on schedule for the CRO's 09:00 forecast call |
| 07:01 | Data Workers | The playbook's first step calls Data Workers. The answer: bookings are not down; an open incident since 02:15 explains the gap, with the metric definition, lineage and model owner |
| 07:02 | WRITER Agent | The playbook's step approval pauses the run and notifies the RevOps reviewer |
| 07:10 | Data Workers | Asked for the fix, Data Workers proposes a dbt diff that maps both new stage values, with its blast radius: three models, the Tableau bookings dashboard and this brief |
| 08:00 | Spellbook | The analytics engineer who owns the model reviews the diff and approves; dbt CI passes |
| 08:20 | Snowflake + dbt | Data Workers reruns the affected models; totals match Salesforce to the deal |
| 08:30 | WRITER Agent | The reviewer approves the step; the brief resumes and reaches the CRO before 09:00, with the receipt linked |
WRITER Agent did its job well: it knows when to act and when to ask, and the step approval gave a person the final say. Data Workers was already on the break at 02:15, so the 07:01 question got a true answer and the fix went through the model's owners.
| Job | What Writer does | What Data Workers does |
|---|---|---|
| The work | Plans and executes briefs, decks, dashboards and spreadsheets in WRITER Agent | Gives each piece of work one governed data tool instead of raw tables |
| The repeat | Turns proven work into playbooks with triggers, schedules and version history | Keeps the metrics those playbooks read correct between runs |
| The context | Enterprise Brain for voice and standards, Knowledge Graph for documents | One context graph of tables, metrics, lineage, owners and freshness across every platform |
| The break | Reports what the connected data returns, with each user's permissions | Detects the break and traces the cause across Salesforce, Fivetran, dbt and Snowflake |
| The fix | Runs only the tools an admin enabled; step approvals hold a run for review | Proposes the change with its blast radius, routes it to a named approver, applies it reversibly |
| The proof | Event logs, session logs and analytics for agent activity | Verifies downstream with checks and baselines on the changed tables and writes a receipt for the data change |
| The guardrails | MCP gateway identity checks, guardrails, tool-level control per connector | Autonomy per data domain on the ladder from L0 to L4 |
Why doesn't Writer just do this itself?
Writer built a governed agent platform for business work, and made sensible choices for that job. Its Snowflake connector docs say it plainly: "Users have the same permissions in Writer that they have in Snowflake." That is the right design: your warehouse stays the system of record for who may do what, and Writer doesn't own decisions about data it doesn't run.
Repairing data is a different product category. When bookings look wrong, the fix lives in a dbt model, a Fivetran schema or a Salesforce picklist mapping. Doing it safely takes blast-radius scoping across systems Writer doesn't operate, approvals routed to the people who own each model, rollback for every change class, receipts that tie a change to its cause, and liability for changes inside other vendors' tools. Writer stays focused on helping marketers and sellers delegate work, which is the right call. The playbook's builder shouldn't need to know which dbt filter maps stage names; Data Workers carries that knowledge and the change control.
Every tool owns a slice. Data Workers covers the whole lifecycle
Writer owns one slice, and owns it well: turning company data and knowledge into finished work, governed by IT. Each point tool adds another console, another contract and another handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail, and builds on Writer where your business teams already work.
| Stage | Data Workers | Writer | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 4.5 | Knowledge Graph (graph-based retrieval over files, Confluence, SharePoint and websites) and Enterprise Brain hold company knowledge and standards. Data Workers keeps one governed context graph of tables, metrics, lineage and owners across every data platform. |
| Analytics & Insights | 8 | 8.5 | Writer's home stage: WRITER Agent turns connected data into briefs, decks and, since September 2026, shareable dashboards, and playbooks repeat that work on a schedule. Data Workers supplies the governed definition and freshness behind each number. |
| Data Quality | 8 | 2 | A playbook can call any tool a connector exposes, and step approvals let a reviewer check output. Data Workers writes, runs and repairs data checks and dbt tests across the estate. |
| Observability & Incidents | 8.5 | 2.5 | AI Studio observes agents: event logs, session logs, analytics and feedback. Data Workers detects data breaks, traces them across systems, fixes and verifies them. |
| Pipelines & Ingestion | 8.5 | 3 | Playbooks with schedule-based and event-based triggers automate business workflows across connectors. Data Workers builds, reruns and backfills data pipelines behind approvals and verifies the output. |
| Schema & Migration | 8 | 1.5 | Writer reads the tools and schemas a connector declares. Data Workers detects upstream schema changes, assesses blast radius and plans migrations in parity-checked waves. |
| Governance & Access | 8.5 | 6.5 | Strong over its own surface: connectors per team, tool-level enable and disable, admin roles, playbook access controls. Data Workers proposes and applies least-privilege grants on your data platforms. |
| Security & Privacy | 8 | 8.5 | A second home stage: the MCP gateway checks identity on every connector call, with guardrails, prompt-injection defense, BYOK encryption and private endpoints. Data Workers leaves a receipt on every data change. |
| Cost / FinOps | 8 | 3 | AI Studio tracks token spend and can block spend above limits. Data Workers traces Snowflake credits to the dbt model behind them and drafts the fix for its owner. |
| MLOps & Models | 7.5 | 4 | Palmyra X6 (the WRITER Agent default since August 6, 2026), external models and guardrails are configured centrally, and playbooks are tested before rollout. Data Workers keeps the data under your own models healthy and connects to MLflow and W&B. |
How Writer and Data Workers work together
Writer stays on top, where business teams delegate work and reviewers approve playbook steps. Spellbook Data Catalog (in preview) is where the data team looks: each proposed change, its approver and its rollback. Between them, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm does the work with more than 20 specialist agents, the Autonomous Data-Conductor runs each fix end to end (detect, diagnose, fix, review, verify, remember), and per-domain guardrails hold approvals, receipts and rollback.
Setup in Writer. Every Data Workers agent is an MCP server, and the same tools are served over Streamable HTTP for remote clients like WRITER Agent. The simplest path is Data Workers' API-key mode: the remote endpoint reads the key as an HTTP Bearer token, and each key maps server-side to a named user and tenant, so every call from the Writer connection is tied to it. If you want each person to sign in, Writer's custom connectors also take user-level OAuth: your identity provider, such as Okta or Microsoft Entra ID, is the authorization server, and Data Workers' remote endpoint runs in OAuth mode, verifying every access token's signature, issuer and audience against your provider's published keys. If Data Workers runs inside your VPC, register a private endpoint (AWS PrivateLink or GCP Private Service Connect) and attach it to the connector. Then, using the labels in Writer's docs this month:
- •In AI Studio, open Connectors & Tools, select Create custom connector, then MCP server.
- •Enter the MCP server URL, a Connector name and the About this connector text. Write the description carefully: it is how WRITER Agent decides when to call Data Workers.
- •Keep or edit the Profile name and choose who has access: start with the RevOps and finance teams that run data-heavy playbooks. Other teams can request access, which an admin approves.
- •Choose API key and enter the Data Workers key, or OAuth with your provider's client ID, client secret and scopes.
- •Enable the read tools only. Writer lets admins switch individual tools on and off within a connector, so write tools stay off until a domain is ready.
- •In each data-heavy playbook, make the first step a Data Workers check, and add a step approval before the step that publishes or sends.
Example: Data Workers as a Writer custom connector
Connector type: MCP server (AI Studio > Connectors & Tools > Create custom connector)
Server URL: https://<your-data-workers-host>/mcp (Streamable HTTP)
Auth: API key (sent as a Bearer token), or OAuth through your IdP
Access: RevOps and Finance teams first
First tools: resolve_metric, monitor_metrics, explain_table,
trace_cross_platform_lineage, get_quality_score
Later: assess_impact, diagnose_incident,
remediate (one domain at a time)Those tools are registered by the dw-context-catalog, dw-quality, dw-schema and dw-incidents agents. For a data engineer's local client, the client setup docs cover the same agents over stdio. For IT, there is nothing new to learn: every call runs through Writer's MCP gateway, which validates the user against your organization's access controls, and disabling the connector in AI Studio revokes access for everyone at once.
One request end to end, L0 to L4. The request: "Draft this week's revenue brief for the CRO." The autonomy ladder is set per domain.
- •L0 manual. The playbook reads Snowflake as it does today; when a number looks off, an analytics engineer traces it by hand.
- •L1 observe. The playbook's first step calls Data Workers read tools:
resolve_metricreturns the governed bookings definition,monitor_metricsconfirms the model's last load is inside its baseline, and an open incident surfaces before a slide is drafted. - •L2 propose. Data Workers proposes the dbt fix with its blast radius. The playbook waits at its step approval, and nothing reaches production until the model owner approves in Spellbook and CI passes.
- •L3 act reversibly. For change classes with a proven record, such as rerunning dbt models for affected partitions, Data Workers applies the change, re-runs the checks on the changed tables and records the undo for the owner.
- •L4 autonomous. For a scoped domain like bookings freshness, Data Workers fixes overnight, and the Monday playbook runs on correct data.
Each step up is a per-domain decision backed by receipts, and you can step back down at any time. The safety model is in is it safe to let AI agents change production data, where data and credentials live is in where does our data go, and the warehouse side is in Data Workers on Snowflake.
The same server serves every assistant your company runs, so the data team builds one integration: see you're on ChatGPT Enterprise, you're on Microsoft Copilot Studio, you're on Salesforce Agentforce and the hub, AI assistants are rolled out, now what.
What changes for your team
Writer gave marketing and revenue teams a way to delegate whole pieces of work. Data Workers gives the data team a crew, so those playbooks never become a queue of "is this number right?" tickets.
- •Incidents. Breaks are traced, fixed and verified overnight, so the Monday playbook reads correct data.
- •Data quality. Every break that nearly reached a brief becomes a check or dbt test at the source.
- •Cloud spend. Snowflake credits are traced to the query and dbt model behind them, and each fix goes to its owner drafted.
- •Access. "Can the playbook use the pipeline table?" becomes a scoped, time-boxed grant proposal to the data owner.
- •Audits. AI Studio logs agent activity; Data Workers logs who changed what in the data, why, and how to undo it.
- •Migrations. A warehouse move runs in approved, parity-checked waves while every playbook keeps reading the same governed metrics.
Keep Writer, or consolidate?
Keep Writer if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Most companies keep it: Writer is where business teams do their work, with the voice, standards and governance they trust. What teams consolidate is the tangle around it: one-off warehouse queries wired into individual playbooks, a separate data-quality tool, an observability console and a ticket queue, replaced by one governed Data Workers connector and one audit trail. If you are weighing building this layer yourself on Writer's custom connectors, read build it ourselves with Claude Code and MCP servers: the MCP endpoint is the easy part; the context graph, approvals and rollback are the work.
The case for your CFO
The outcome: the company invested in Writer so marketing and revenue teams ship more work with the same people. Data Workers makes the numbers in that work correct, current and auditable, and a scheduled playbook multiplies every number it reads.
The risk story has two locks. In Writer, admins decide which teams use the connector and which tools are on, and step approvals put a person in front of anything that ships. In Data Workers, autonomy is set per domain from L0 manual to L4 autonomous; each change goes to a named approver, is applied reversibly, verified downstream and recorded in a receipt. There is zero migration: Salesforce, Fivetran, dbt, Snowflake and Tableau stay where they are.
Why now: playbooks run on triggers, build dashboards and act through connectors, so a wrong number ships before anyone notices. The first win is one scheduled playbook, such as the weekly revenue brief, checking Data Workers before it drafts. What stays the same: Writer, its admins, your warehouse permissions and your dbt review process. For the numbers, see the ROI of agentic data operations. Start with a pilot (pricing); the pilot is credited in full against the first year.
The sentence to repeat upstairs: "Our teams ship briefs and decks from Writer; Data Workers makes sure every number in them comes from a governed definition and fresh, verified data, and fixes the data when it breaks, with an approval and a receipt."
Getting started
Start with a pilot. Pick one playbook that already reads warehouse data, such as the weekly revenue brief, add Data Workers as a custom MCP connector with read tools for that team, and make a Data Workers check the playbook's first step. Then turn on the first write class in that domain. Plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
Writer already has Snowflake, Databricks and BigQuery connectors. Why add Data Workers? Those connectors are the right way to query your warehouse, with each user's own permissions. Data Workers adds what sits around the query: the governed metric definition, lineage, owner, freshness and open incidents, plus the fixes when data breaks. Many teams keep both: the playbook checks Data Workers first, then queries.
Can we keep Data Workers read-only in Writer? Yes. Writer's docs give exactly this example: enable read-only tools for a connector while disabling tools that modify or delete data. Enable a write tool for one domain when the receipts give you confidence.
Does this work in Agent Builder or the Writer API? Writer's docs state that MCP connectors are currently available for WRITER Agent, which is where playbooks, triggers and dashboards run and where most data-heavy work in Writer happens. Writer also publishes its own WRITER MCP server, so other MCP clients can run published playbooks.
Our data platform is in a private VPC. How does Writer reach Data Workers? Over a private endpoint: AWS PrivateLink or GCP Private Service Connect between Writer's MCP gateway and your VPC, enabled on a custom connector during setup. Writer also publishes its gateway's static egress IPs for firewall allowlists.
Who approves a data fix that a playbook asks for? Two people, by design. The playbook's step approval goes to its designated reviewer, usually in RevOps or marketing ops. The data change goes to the owner of the affected model in Spellbook, with the diff and blast radius. Neither can skip the other.
How do we audit what happened? AI Studio event logs and WRITER Agent session logs record agent activity and export for review. Data Workers writes a receipt for every data change: the cause, the approver, the diff, the downstream verification and the rollback path.
Sources
- •WRITER homepage, "The enterprise AI platform for agentic work", https://writer.com/ (checked Oct 2, 2026)
- •WRITER Agent product page, https://writer.com/product/writer-agent/ (checked Oct 2, 2026)
- •Playbooks product page, https://writer.com/product/playbooks/ (checked Oct 2, 2026)
- •AI Studio product page, https://writer.com/product/ai-studio/ (checked Oct 2, 2026)
- •Enterprise Brain product page, https://writer.com/product/enterprise-brain/ (checked Oct 2, 2026)
- •Connectors product page, https://writer.com/product/connectors/ (checked Oct 2, 2026)
- •Palmyra X6 models page, https://writer.com/models/ (checked Oct 2, 2026)
- •What's new at WRITER (step approvals and dashboards in WRITER Agent, Sep 15, 2026; Palmyra X6, Aug 6, 2026; Routines renamed triggers, Feb 2026; last updated Oct 1, 2026), https://support.writer.com/article/40-whats-new-at-writer (checked Oct 2, 2026)
- •Writer docs, Writer AI Studio, https://dev.writer.com/home/introduction (checked Oct 2, 2026)
- •Writer docs, Configure connectors (MCP gateway, access control, tool-level control), https://dev.writer.com/home/mcp-gateway (checked Oct 2, 2026)
- •Writer docs, Custom connectors (MCP server type; No auth, API key or OAuth at user or org level), https://dev.writer.com/home/custom-connectors (checked Oct 2, 2026)
- •Writer docs, Private endpoints, https://dev.writer.com/home/private-endpoints (checked Oct 2, 2026)
- •Writer docs, Snowflake connector, https://dev.writer.com/connectors/snowflake (checked Oct 2, 2026)
- •Writer docs, Knowledge Graph concepts, https://dev.writer.com/home/knowledge-graph-concepts (checked Oct 2, 2026)
- •Writer docs, Event logs, https://dev.writer.com/home/event-logs (checked Oct 2, 2026)
- •Writer docs, Models (Palmyra X6 default for WRITER Agent), https://dev.writer.com/home/models (checked Oct 2, 2026)
- •Writer docs, WRITER MCP, https://dev.writer.com/home/writer-mcp (checked Oct 2, 2026)
- •Data Workers client setup docs, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 2, 2026)
- •Data Workers open-source repository, tool registrations under
agents/*/src/tools(checked Oct 2, 2026) - •Data Workers agent swarm repository: remote Streamable HTTP transport with API-key (Bearer) and JWKS-verified OAuth modes (checked Oct 2, 2026)