You're on MuleSoft: It Connects Your Systems and Governs Your Agents. Data Workers Owns Whether the Data Its Flows Deliver Is Right
MuleSoft connects your systems through APIs and Agent Fabric governs your agents. Data Workers owns whether the data Mule flows deliver to the warehouse and back is right, with approvals and receipts.
Your integration team thinks in API-led layers: system APIs wrap SAP, Workday, the warehouse management system and the mainframe; process APIs combine them; experience APIs serve apps and partners. Each is a Mule application written in DataWeave, versioned in Anypoint Exchange, deployed to CloudHub 2.0 or Runtime Fabric and watched in Anypoint Monitoring. The homepage now leads with MuleSoft Agent Fabric, launched Sep 25, 2025 and generally available, which finds every agent, MCP server and API you run, governs their traffic and caps what they spend. Your developers ask the MuleSoft DX MCP Server to generate flows and deploy applications, and the Platform MCP Server, introduced May 28, 2026, lets an assistant discover and govern services across the estate.
More of those flows end in the warehouse, and some start there: a process API lands order lines in Snowflake; a scheduled flow reads a dbt model and writes the result back to Salesforce. A Mule flow succeeds when the message is delivered without an error. It has no reason to know that a quantity now means cases instead of units, while a fill-rate model, a Looker Explore and a Salesforce field all assume units. MuleSoft connects your systems. Data Workers owns whether the data those flows deliver to the warehouse and back is right, and gets the fix approved before anything downstream acts on it.
Key takeaways
- •MuleSoft keeps its job. Mule applications, deployments, schedules and Agent Fabric policies stay with your integration team. Data Workers works on what the flows land and what reads it.
- •Successful flows get checked too. Data Workers tracks the metrics your team records on landed tables against a baseline, so wrong values from a green flow become an incident before the next sync.
- •Connected over MuleSoft's API or MCP servers today. Data Workers reads the landed data natively in Snowflake, Databricks or BigQuery; the MuleSoft MCP servers sit next to the Data Workers agents in the same client.
- •Every fix goes through a named person. The integration owner runs the Anypoint side; the data owner approves the dbt side; each step leaves a receipt.
- •Autonomy is set per domain. Start at L1 observe, move to L2 propose, and open L3 act reversibly for narrow classes once the record earns it.
MuleSoft is the connective layer between your systems. Data Workers is the owner of what that layer delivers.
MuleSoft's job is to get every message from the system that has it to the system that needs it, through governed, reusable APIs. The job after delivery is different: notice that a successful flow delivered values that mean something new, size the damage, hold the sync that would ship it, get the cause fixed and replayed, rebuild in order, and prove the result. Here is one evening at a food service distributor. This is an illustrative example.
| Time | System | What happens |
|---|---|---|
| Tue 15:30 | Anypoint Exchange | To support case picking in the Manhattan Active WMS, the integration team publishes wms-shipments-sapi 2.0. For case-picked items, shippedQuantity now comes back in the pick unit, with a new quantityUom field saying which. The spec documents the change |
| 16:40 | CloudHub 2.0 | order-fulfillment-papi 1.8.0 is deployed against the new system API. Its DataWeave mapping passes shippedQuantity to shipped_qty and ignores quantityUom. Every flow run succeeds; Anypoint Monitoring is green |
| 16:45 | Snowflake | On its 15-minute schedule the Snowflake Connector merges delivery lines into RAW_MULE.DELIVERY_LINES. By 18:00, 3,180 case-picked lines carry case counts where units used to be: 2 instead of 48 |
| 18:00 | dbt Cloud | The hourly supply_chain job builds fct_fill_rate, shipped over ordered units by account. 212 accounts drop under the 95% service level on their 7-day fill rate. Every dbt test passes: the values are positive, not null and unique per line |
| 18:06 | Data Workers + Snowflake | The team records units_per_delivery_line as a metric; monitor_metrics flags 1.1 against a 30-day norm of 17.6 for lines landed since 16:45. Nulls and row counts are normal, and no column changed in the dbt manifest. Data Workers opens an incident |
| 18:12 | Data Workers + Runtime Manager | The integration lead confirms in Runtime Manager that 1.8.0 went live at 16:40. diagnose_incident ties the metric drop to that window, and the analytics owner confirms that the new quantities match case packs in dim_item. blast_radius_analysis and trace_cross_platform_lineage map what reads it: fct_fill_rate, the Looker "Service level" Explore, and the account-health-sync Mule flow the context graph lists as a consumer, which writes Fill_Rate_7d__c to 2,900 Salesforce accounts at 19:00. Below 95%, a Salesforce flow opens a service recovery case |
| 18:15 | Jira SM + Slack | Data Workers opens a Jira Service Management ticket with the diagnosis and sends the approval request to the integration lead and the supply chain analytics owner in Slack |
| 18:20 | Spellbook | One plan with its blast radius: hold the 19:00 run of account-health-sync; a DataWeave change, proposed as a diff for the integration owner to merge, that converts shippedQuantity to units using quantityUom and the case pack; a replay of every line since 16:40; a dbt test that fails when units per line leave the recorded range; then the rebuild and the sync, in that order |
| 18:41 | Spellbook | The integration lead approves the hold, the mapping change and the replay. The analytics owner approves the dbt test |
| 18:45 | Runtime Manager | The integration lead disables the schedule on account-health-sync before it fires |
| 19:30 | GitHub + CloudHub 2.0 | An integration developer merges the DataWeave diff with an MUnit test for case-picked lines and deploys 1.8.1. He resets the flow's watermark to 16:40; the fixed application re-reads those shipments and the connector's merge on delivery_line_id replaces all 3,180 lines with unit counts |
| 19:50 | dbt Cloud | The analytics engineering owner queues the approved supply_chain run in dbt Cloud, recorded in Spellbook; the new test runs with it |
| 20:10 | Data Workers + Snowflake | Data Workers verifies: units per line at 17.9 against the 17.6 norm, nulls and row counts normal, no duplicate delivery_line_id, and the accounts-under-95% metric the team records back at 9, as on Monday. remediate re-checks the assertions and would send any failure to a person |
| 20:15 | Manhattan Active WMS | The supply chain analyst spot-checks ten accounts against the WMS shipment confirmations. They match |
| 20:20 | Runtime Manager + Salesforce | The integration lead re-enables and runs account-health-sync. Salesforce gets the right fill rates; no service recovery cases open |
| 20:30 | Jira SM | Data Workers adds the receipt to the ticket as a comment: cause, approvals, runs, checks passed and the undo. The service desk agent resolves it |
| Wed 08:30 | Agentforce | An account manager asks the Agentforce sales agent which of her accounts fell under 95% this week. It answers from Fill_Rate_7d__c: two, both real |
Every part of MuleSoft did its job. Catching this takes knowledge an integration platform was never meant to hold: that shipped_qty is read as units by a fill-rate model, that 2 is a plausible but wrong value, and that a flow writes the result into 2,900 Salesforce accounts at 19:00.
| Job | What MuleSoft does | What Data Workers does |
|---|---|---|
| The move | Runs Mule applications on CloudHub 2.0 or Runtime Fabric, through system, process and experience APIs and hundreds of connectors | Reads what the flows land, natively in the warehouse; connects to MuleSoft over its API or MCP servers |
| The signal | Runtime Manager and Anypoint Monitoring report app health, errors and throughput; a delivered message is a success | Checks the landed data: the metrics the team records against a baseline, plus nulls and volume |
| The diagnosis | Explains a failed flow from its logs and monitoring | Joins the metric drop, the deployment time and lineage into one cause, with the blast radius across dbt models, dashboards and flows that write back to Salesforce |
| The fix | Runs whatever DataWeave mapping and application version the team deploys | Proposes the mapping change as a diff, the dbt test and the hold to the owners, who approve and apply them |
| The replay | Re-reads and redelivers from a watermark or queue | Proposes the replay in order with the rebuilds and the sync after it; the owner runs the replay, and Data Workers queues the approved downstream runs |
| The proof | Keeps deployment history, logs and API analytics | Re-checks the tables and writes a receipt: what changed, who approved it, how it was checked, how to undo it |
Why doesn't MuleSoft just do this itself?
Because MuleSoft is built to connect systems through governed, reusable APIs, and its idea of success fits that job. A flow succeeds when the message is delivered. Anypoint Monitoring tells you whether an application is healthy; MUnit proves the mapping does what the developer meant; governance rulesets check that APIs follow your standards. None of that is meant to know that a field which kept its name now means cases, that a dbt model divides by it, or that a scheduled flow writes the answer into Salesforce an hour later.
MuleSoft's AI features follow the same scope, and they are good at it. The DX MCP Server generates flows and MUnit tests and deploys applications; MuleSoft Vibes, the assistant in Anypoint Code Builder, drafts specs and integrations. Agent Fabric discovers agents, MCP servers and LLM calls, enforces policies on their traffic through its gateway (the unified AI Gateway on the homepage, Omni Gateway in the docs), carries trusted identity, can stop a rogue agent and caps model spend. On Aug 31, 2026 the Platform MCP Server added lineage for agents, MCP servers and APIs and classification for data assets from its Context Catalog. All of it governs the integration and agent estate MuleSoft runs.
Owning whether delivered data is right across six systems is a different product with different liability: a context graph of every table and consumer, blast-radius scoping, named approvers, a recorded undo and receipts an auditor can read. That is Data Workers. More in is it safe to let AI agents change production data.
Every tool owns a slice. Data Workers covers the whole lifecycle
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, and builds on the Mule applications already there.
| Stage | Data Workers | MuleSoft | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 5 | Anypoint Exchange, Agent Registry and the Context Catalog describe APIs, agents, MCP servers and data assets. Data Workers keeps one governed context graph of what each table means, who owns it and what reads it. |
| Analytics & Insights | 8 | 2 | Not MuleSoft's job: it moves records between systems, and business numbers live in BI. Data Workers answers data questions from governed definitions with lineage behind every number. |
| Data Quality | 8 | 3 | DataWeave and MUnit test the mapping a developer wrote. Data Workers checks what the flows actually landed in the warehouse and tracks the metrics the team records against a baseline. |
| Observability & Incidents | 8.5 | 5 | Anypoint Monitoring and Runtime Manager show whether a Mule application is healthy and its flows succeed. Data Workers diagnoses the data incident when every flow succeeded, proposes the fix and verifies it. |
| Pipelines & Ingestion | 8.5 | 9 | MuleSoft's home stage: API-led connectivity, hundreds of connectors, Mule applications on CloudHub 2.0 or Runtime Fabric, and the DX MCP Server to build and deploy them. Data Workers plans the replay and reruns for the owner. |
| Schema & Migration | 8 | 4 | API specs are versioned in Exchange and checked against governance rulesets. Data Workers traces a changed field from the flow to every model, dashboard and job that reads it. |
| Governance & Access | 8.5 | 7 | Agent Fabric governs agents, MCP servers and LLM calls with policies, trusted identity and a kill switch. Data Workers routes every data change to a named approver. |
| Security & Privacy | 8 | 6 | AI Gateway policies detect and mask PII in agent traffic, with secrets kept in your vault. Data Workers leaves a receipt on every data change. |
| Cost / FinOps | 8 | 4 | Agent Fabric routes requests to cheaper models and caps LLM spend with prepaid wallets. Data Workers traces Snowflake credits to the dbt model behind them. |
| MLOps & Models | 7.5 | 2 | Agent Fabric connects agents to systems; it doesn't watch training data. Data Workers keeps the data under models and agents healthy. |
How MuleSoft and Data Workers work together
Data Workers connects to MuleSoft over its API or MCP servers today. What it needs from each flow sits in the warehouse the flow writes to, which it reads natively, with the dbt Cloud jobs, the Looker Explores (read) and the consumers in its context graph. Mule applications, mappings, deployments, schedules and Agent Fabric policies stay with your integration team: Data Workers never edits, deploys or replays a Mule application, and the Salesforce write-back stays with the flow's owner. The rest of the incident runs on native connections (Snowflake, dbt Cloud, Looker, Slack, Jira Service Management) among 50+ connectors.
The MuleSoft MCP servers and the Data Workers agents run side by side in one client. The Platform MCP Server is remote and signs in through an Anypoint connected app; MuleSoft supports manual client registration only, so you create the app first. The Data Workers side follows the documented client setup: clone the open-source repo and add each agent's start-agent.sh entry.
# Example: MuleSoft MCP servers plus Data Workers agents in Claude Code
# MuleSoft Platform MCP Server (remote; Anypoint connected app with a fixed callback port)
MCP_CLIENT_SECRET=<YOUR_CLIENT_SECRET> claude mcp add --transport http \
--callback-port 32493 --client-id <YOUR_CLIENT_ID> --client-secret \
mulesoft-platform https://omni.mulesoft.com/mcp
# MuleSoft DX MCP Server (local; deploys and updates Mule applications)
claude mcp add mulesoft-dx \
--env ANYPOINT_CLIENT_ID=<YOUR_CLIENT_ID> --env ANYPOINT_CLIENT_SECRET=<YOUR_CLIENT_SECRET> \
-- npx -y mulesoft-mcp-server start
# Data Workers agents, from a clone of the open-source repo
claude mcp add --scope user dw-incidents -- "$(pwd)/start-agent.sh" dw-incidents
claude mcp add --scope user dw-quality -- "$(pwd)/start-agent.sh" dw-quality
claude mcp add --scope user dw-catalog -- "$(pwd)/start-agent.sh" dw-context-catalog
claude mcp add --scope user dw-schema -- "$(pwd)/start-agent.sh" dw-schema
claude mcp add --scope user dw-connectors -- "$(pwd)/start-agent.sh" dw-connectorsList the tools with your client's own command (/mcp in Claude Code). In this incident: monitor_metrics, diagnose_incident and remediate (dw-incidents); run_quality_check (dw-quality); blast_radius_analysis and trace_cross_platform_lineage (dw-context-catalog); create_jira_sm_ticket (dw-connectors). On the MuleSoft side, list_applications and update_mule_application cover the owner's part.
Agent Fabric documents registering any MCP server in its portfolio by URL or schema file, so a team that governs every agent there can add Data Workers' agents and apply its own policies to that traffic. In production the agents run in your infrastructure and hold the warehouse credentials and model key. Your data stays in your systems; the hosted Conductor sees workflow metadata only. More in where does our data go.
One incident, L0 to L4, set per domain:
- •L0 manual. At 19:00 wrong fill rates reach 2,900 accounts and 212 service recovery cases open.
- •L1 observe. Data Workers flags the drop at 18:06 with the cause and blast radius. Nothing changes.
- •L2 propose. Data Workers proposes the hold, the mapping diff, the replay plan and the dbt test; nothing moves until the named owners approve.
- •L3 act reversibly. For a class with a clean record, Data Workers queues the approved rebuilds itself. Deployments and replays stay with the integration owner.
- •L4 autonomous. For a scoped domain, Data Workers runs the whole downstream sequence on its own, so the owner's fix is waiting before the next sync runs.
Who sets those levels: who owns the agents, how approvals work for AI data agents and autonomy levels L0 to L4 explained.
What changes for your team
- •Integration and data teams share one incident. The integration lead sees the deployment that caused it; the analytics owner sees the models it reached. Both read the same receipt in Spellbook Data Catalog (in preview), linked from the Jira ticket.
- •A new API version gets a downstream check. The first loads after a deployment are checked against the metrics the data team cares about.
- •Flows that write back get a guard. When a warehouse number just went wrong, a hold is proposed before the flow pushes it into Salesforce.
- •Agents answer from verified numbers. Agentforce and every other agent that reads those fields read values that passed the checks. See you're on Salesforce Agentforce and you're on Salesforce Data 360.
For the definitions behind the category, see data ingestion vs data integration.
Keep MuleSoft, or consolidate?
Keep MuleSoft if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
For most MuleSoft teams the answer is keep it: years of reusable APIs and now Agent Fabric are hard to replace and shouldn't be. What teams consolidate is the tooling around the delivered data: a separate observability tool, row-count scripts and "redeploy and check the dashboard" runbooks. Salesforce has also owned Informatica since Nov 18, 2025, and many estates run a second mover beside MuleSoft: see you're on Informatica, you're on Boomi and you're on Fivetran. One incident record spans them, and Data Workers integrations lists what connects natively.
Weighing a build on the MuleSoft MCP servers and a coding agent? Read build it ourselves with Claude Code and MCP servers: the context graph, the approvals, the undo and the receipts are the work.
The case for your CFO
The outcome. When a Mule flow delivers values that mean something new into the tables behind service levels, revenue or inventory, it is caught before the next sync ships it, and corrected with a record of how it was checked.
The risk story. At L0 and L1, agents only read. At L2 they propose and a named person approves; an unanswered request expires and escalates, never auto-grants. At L3 they act on reversible changes inside the domains you open; L4 is a later choice per domain. Deployments, replays and schedules stay with the integration owner in Anypoint. No agent can promote its own work, and an org-wide stop halts all autonomous dispatch. Every change carries a receipt: what changed, who approved it, the blast radius and the undo.
Why now. MuleSoft is turning your APIs into MCP tools and Agentforce actions, so the numbers your flows deliver now feed agents that act on them.
The first win. L1 on the flows that land in the warehouse and the flows that write back from it: a new API version that changes a field's meaning becomes a diagnosed incident before the next sync runs.
What stays the same. Nothing migrates: MuleSoft, your Mule applications and API specs, Agent Fabric, your dbt project, your warehouse and your on-call rota. For the numbers, see the ROI of agentic data operations.
The sentence for upstairs: "MuleSoft connects our systems and governs our agents; Data Workers makes sure the data those connections deliver is right, and gets it fixed with our approval when it isn't, before a customer or an agent acts on it."
Getting started
Start with a pilot. Pick the Mule flows that land the numbers leaders, customers and agents read, plus any flow that writes back to Salesforce, give Data Workers read access to those schemas, record the two or three metrics that define "right", and run at L1 for a few weeks. Then turn on L2 for one domain, and open L3 for a narrow class once the receipts show the agents were right. The pilot path is on the pricing page, and the pilot is credited in full against the first year.
FAQ
How does Data Workers connect to MuleSoft? Over MuleSoft's API or MCP servers today. Data Workers reads what your flows land natively in Snowflake, Databricks or BigQuery, whether your applications run on CloudHub 2.0 or Runtime Fabric.
Our Mule flows all succeeded. How can the data be wrong? A flow succeeds when it delivers the message. If an upstream API changes what a field means while keeping its name and type, every message arrives and every value is wrong for the model that reads it. Only a check on the values catches it.
Isn't this what Agent Fabric does? Agent Fabric governs agents: it finds them, applies policies to their calls and caps model spend. Data Workers owns whether the data in your warehouse and the systems fed from it is right. Agent Fabric documents registering any MCP server, so your team can bring Data Workers' agents under the same policies.
Will Data Workers deploy, replay or stop our Mule applications? No. Deployments, DataWeave changes, schedules, replays and the write-back to Salesforce stay with the integration owner, in Anypoint or through the MuleSoft MCP servers. Data Workers proposes them in order, with the mapping change as a diff, queues approved downstream runs through your orchestrator and records the dbt Cloud reruns the owner queues.
We're also on Data 360 and Agentforce. Where does Data Workers sit? Under them, on the warehouse data they read, so segments, insights and agent answers start from verified numbers.
Should we let agents deploy Mule applications through the DX MCP Server? MuleSoft scopes each tool to your connected app's Anypoint permissions, a good start. Keep applications that feed money, customers or agents behind an approval; Data Workers adds the context, the named approver and the receipt.
Sources
- •MuleSoft, homepage ("MuleSoft with Agent Fabric"; Agent Registry, Agent Governance, unified AI Gateway, Agent Connectivity, Cost Management; "Agent Fabric is generally available today"; Agent Fabric vs Agentforce), https://www.mulesoft.com/ (checked Oct 3, 2026)
- •Salesforce newsroom, "Salesforce Launches MuleSoft Agent Fabric to Orchestrate and Govern Any AI Agent Across the Agentic Enterprise" (Sep 25, 2025), https://www.salesforce.com/news/press-releases/2025/09/24/mulesoft-agent-fabric-announcement/ (checked Oct 3, 2026)
- •Salesforce newsroom, Salesforce completes acquisition of Informatica (Nov 18, 2025), https://www.salesforce.com/news/press-releases/2025/11/18/salesforce-completes-acquisition-of-informatica/ (checked Oct 3, 2026)
- •MuleSoft docs, Agent Fabric overview (Omni Gateway as runtime enforcement point, rogue agent detection and kill switch, model wallets, MuleSoft Vibes in Anypoint Code Builder), https://docs.mulesoft.com/general/agent-fabric-overview (checked Oct 3, 2026)
- •MuleSoft docs, Adding Services to Your Portfolio (register MCP servers with an MCP URL or schema file), https://docs.mulesoft.com/general/exp-services-add-to-portfolio (checked Oct 3, 2026)
- •MuleSoft docs, MuleSoft MCP Servers overview (DX MCP Server and Platform MCP Server), https://docs.mulesoft.com/mulesoft-mcp-server/ (checked Oct 3, 2026)
- •MuleSoft docs, MuleSoft MCP Servers release notes (Platform MCP Server introduced May 28, 2026; DX rename;
get_asset_lineageandget_data_asset_classificationAug 31, 2026), https://docs.mulesoft.com/release-notes/mulesoft-mcp-server/mulesoft-mcp-server-release-notes (checked Oct 3, 2026) - •MuleSoft docs, DX MCP Server tool reference (
deploy_mule_application,update_mule_application,list_applications, required Anypoint permissions), https://docs.mulesoft.com/mulesoft-mcp-server/reference-mcp-tools (checked Oct 3, 2026) - •MuleSoft docs, Getting started with MuleSoft DX MCP Server (
npx -y mulesoft-mcp-server start, connected app credentials), https://docs.mulesoft.com/mulesoft-mcp-server/getting-started, and with MuleSoft Platform MCP Server (connected app, Claude Code command, manual client registration only), https://docs.mulesoft.com/mulesoft-mcp-server/getting-started-platform (checked Oct 3, 2026) - •Data Workers open-source repository (tool registrations in dw-incidents, dw-quality, dw-context-catalog, dw-schema, dw-connectors), https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)
- •Data Workers client setup guide, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)