MuleSoft Agent Fabric: The Complete 2026 Guide to AI Agent Governance at Enterprise Scale

The first wave of enterprise AI agents has already happened, and most IT leaders did not see it coming. According to the Salesforce 2026 Connectivity Benchmark report, the average enterprise now operates twelve AI agents in production, with multi-agent adoption projected to grow another 67% by 2027. Half of those agents are running in isolation: built on different platforms, governed by different teams, paying for different model tokens, and almost never sharing context with each other. The result is a familiar pattern in enterprise software history. We have entered the "shadow AI" phase, where adoption races ahead of governance, and architects are left to clean up the sprawl.

This is the gap that MuleSoft Agent Fabric is designed to close. Announced by Salesforce in September 2025 and rolling into general availability across 2026, Agent Fabric repositions MuleSoft from an iPaaS into the "agentic infrastructure layer" of the enterprise — the connective tissue that governs AI agents regardless of which vendor built them. For Salesforce admins, developers, architects, and IT leaders, Agent Fabric is the most consequential MuleSoft release since the Salesforce acquisition in 2018. This guide walks through what it is, how its five pillars work together, how it complements Agentforce 360, and what your 2026 developer workflow actually looks like.

Why Agent Fabric Exists: The Multi-Agent Problem

Before getting into pillars and product features, it is worth being precise about the problem. The 2026 Connectivity Benchmark report describes a familiar pattern. A customer service team stands up an Agentforce agent for case deflection. A supply chain team builds a demand-forecasting agent on Google Vertex AI because their data scientists already live there. Risk and fraud teams adopt an Amazon Bedrock agent because it is closest to their data lake. Sales operations builds a coaching assistant in Microsoft Copilot Studio because that is where the sellers spend their day. Each of these is a reasonable, defensible decision in isolation. Together, they create five problems at once.

First, discoverability collapses. No one in the organization can answer the simple question "how many agents do we have?" The CIO certainly cannot. Second, redundant automations multiply. Two teams independently build agents that summarize cases, call the same backend systems, and produce slightly different answers. Third, cost visibility disappears. Token consumption is split across vendor bills, and finance has no way to attribute spend back to a business outcome. Fourth, trust posture fragments. Each platform has its own guardrails, its own logging, and its own data residency rules. Fifth, agents cannot collaborate. The fraud agent cannot ask the case agent what the customer was complaining about, because they do not share an identity model, a tool registry, or a wire protocol.

MuleSoft is unusually well-positioned to solve this because it has spent more than a decade solving the analogous problem for APIs. Salesforce acquired MuleSoft in 2018 for $6.5 billion specifically to extend integration beyond the CRM, and Anypoint Platform has now been recognized in the Gartner Magic Quadrant for iPaaS for the tenth consecutive year in 2026. Agent Fabric applies the same playbook — registry, gateway, governance, reusability — to the new agent layer.

A Quick Refresher on the MuleSoft Foundation

If you are coming to Agent Fabric without a deep MuleSoft background, the rest of this guide will land better with a quick orientation. MuleSoft's Anypoint Platform is a unified iPaaS — a single environment for designing, deploying, securing, and managing integrations and APIs. Three concepts matter most.

The first is API-led connectivity, MuleSoft's signature architectural pattern. Instead of point-to-point integrations, you design three layers of APIs: System APIs that abstract underlying systems of record (Salesforce, SAP, Workday, your data warehouse), Process APIs that orchestrate business logic across systems, and Experience APIs that shape data for a specific channel (mobile app, partner portal, or — increasingly — an AI agent). The pattern produces composable, reusable building blocks rather than spaghetti.

The second is the Anypoint toolchain. Anypoint Code Builder is the modern VS Code-based IDE (also available in the browser) where developers author flows, RAML or OAS API specs, and DataWeave transformations. CloudHub 2.0 is the Kubernetes-based runtime where those flows are deployed with auto-scaling replicas. Anypoint Exchange is the marketplace where teams publish and discover connectors, templates, and reusable assets — and there are now roughly 300 prebuilt connectors covering databases, SaaS platforms, and proprietary APIs.

The third is Flex Gateway, MuleSoft's lightweight API gateway. Originally built to govern API traffic at the edge, Flex Gateway is the infrastructure on which Agent Fabric's AI Gateway is built. That lineage matters: every governance pattern MuleSoft customers already know for APIs — rate limiting, JWT validation, mTLS, policy enforcement, observability — is being extended to agent traffic.

With that foundation, Agent Fabric's design choices stop looking novel and start looking inevitable.

The Five Pillars of Agent Fabric

Salesforce's official September 2025 announcement framed Agent Fabric around five capabilities. The naming has stayed remarkably consistent through the 2026 roadmap, and InfoWorld's ongoing coverage has tracked each pillar from beta to GA. Here is what each one actually does.

Agent Registry

The Agent Registry is the easiest pillar to grasp because it is conceptually identical to Anypoint Exchange — but for agents instead of APIs. Every agent in the enterprise gets a record. That record includes its owner, its underlying model, the tools and APIs it has access to, the systems it can read from and write to, its trust classification, its cost-to-date, and its observed reliability. Agents become first-class, discoverable, reusable assets rather than tribal knowledge living in a Slack channel.

For an architect, the Registry is also where reuse begins. If a sales team is about to commission a new "account research" agent, they can search the Registry first and find that the customer success team already built one. The Registry surfaces what tools that existing agent calls, what data it touches, and what its guardrails look like. The default answer becomes "extend the existing agent," not "build another one."

Agent Scanners

The Registry only works if it is populated, and the lesson MuleSoft learned from a decade of API catalogs is that no one fills out the catalog by hand. Agent Scanners solve this by automatically discovering agents wherever they live. As of early 2026, scanners are GA for Salesforce Agentforce, Amazon Bedrock and Bedrock Agentcore, Google Vertex AI, Microsoft Copilot Studio, and GoDaddy. The scanners use platform-native APIs to enumerate deployed agents, pull metadata, and register them in the Agent Registry without any manual data entry.

This is the capability that converts Agent Fabric from a nice-to-have into a board-level story. For the first time, a CIO can run a single query and answer the question "what agents do we operate, who owns them, what do they cost, and what are they doing with our data?" In a world where 50% of agents are estimated to be running in silos, that visibility is the prerequisite for everything else.

AI Gateway

The AI Gateway is where the bulk of the day-to-day governance happens, and it is the pillar most directly built on existing MuleSoft infrastructure. Architecturally, the AI Gateway is a specialized deployment of Flex Gateway that sits in the path of three kinds of traffic: outbound LLM calls, MCP (Model Context Protocol) tool invocations, and agent-to-agent (A2A) messages. Three sub-capabilities sit on top of that.

LLM Governance, GA as of early 2026, gives a single dashboard view of token usage, model costs, latency, and data flows across every third-party model in use — OpenAI, Anthropic, Google, Bedrock-hosted models, and self-hosted open-source models. It enforces per-team budgets, masks sensitive data on the way out, and logs every request for compliance review. For finance teams that have been receiving four separate model-vendor invoices with no chargeback story, this alone has paid back the deployment.

MCP Bridge is, for many MuleSoft customers, the most pragmatic feature of the entire platform. The Model Context Protocol — Anthropic's open standard for exposing tools to AI agents, now broadly adopted across Agentforce, Bedrock, and Vertex AI — defines a clean way for agents to discover and call tools. MCP Bridge makes any REST API or MuleSoft integration callable as an MCP tool, with no rewrite. If you have 200 existing System and Process APIs in Anypoint Exchange, MCP Bridge wraps the catalog so that any compliant agent can discover and invoke them, with policy enforcement, identity, and logging applied at the gateway.

Trusted Agent Identity addresses the high-stakes case. Some agent actions — wiring funds, changing entitlements, deleting records — should not be authorized by an LLM's judgment alone. Trusted Agent Identity supports step-up authorization, including mobile push approval, before the gateway will let a tool invocation through. The pattern combines the Salesforce trust model with classic strong customer authentication.

Agent Broker

Of all five pillars, Agent Broker is the one that has generated the most interest in Salesforce Architects' deep-dive documentation, and for a reason worth pausing on. LLM-driven orchestration is powerful but non-deterministic. For many enterprise workflows — financial transactions, regulated compliance steps, clinical or legal processes — non-determinism is unacceptable. Agent Broker provides a deterministic orchestration layer that lets you script exactly what happens, in what order, with what guardrails, when LLM reasoning alone is not safe enough.

Agent Broker entered Beta in April 2026 and reached GA in June 2026. It includes a visual authoring canvas in Anypoint Code Builder, so architects can compose deterministic flows the same way they compose Mule integrations. In GA, Agent Broker also added native Salesforce model support, including Atlas-aware routing — meaning an Agent Broker workflow can call into the Atlas Reasoning Engine when probabilistic reasoning is appropriate, and stay deterministic everywhere else.

The architectural pattern is straightforward. You author a Broker workflow that calls deterministic steps (validate the wire transfer amount, check sanctions list, require approval if over threshold), with optional escapes to an LLM-driven agent for tasks that genuinely need reasoning (draft the customer notification email). The workflow itself never depends on the LLM doing the right thing.

Enterprise Actionability

The fifth pillar is less a discrete product than a design promise. Through MCP and A2A support, every existing MuleSoft integration becomes usable in agentic workflows without being rebuilt. The 300+ Anypoint Exchange connectors, every System API a customer has ever published, every CloudHub 2.0 deployment — all of it becomes, by virtue of being on MuleSoft, agent-ready. For organizations that have spent years investing in API-led connectivity, this is the payoff: their integration estate becomes their agent estate, with no second migration.

How Agent Fabric Fits with Agentforce 360

A reasonable question at this point: if Salesforce already has Agentforce 360, why does it need Agent Fabric? The answer comes down to scope. Agentforce 360 is Salesforce's first-party agent platform, built on the Atlas Reasoning Engine and protected by the Einstein Trust Layer. It is the right answer for agents that live close to Salesforce data and Salesforce business processes. Agent Fabric is the multi-vendor agent control plane — it governs agents regardless of where they were built or where they run.

The two are complementary, and Salesforce has been deliberate about the integration points.

In practice, the seam between them is smooth. An Agentforce agent registers in the Agent Registry automatically. The Atlas Reasoning Engine can hand work off to an external agent through Agent Broker. An Agentforce agent can call a tool whose underlying implementation is a MuleSoft Process API exposed via MCP Bridge. Trust is layered: Einstein Trust Layer protects Salesforce-native flows, AI Gateway protects everything else, and the Agent Registry gives a single inventory for both.

Practical Use Cases

The patterns become much more concrete when applied to real situations. Here are four that recur across early Agent Fabric adopters.

A retail company with three agent platforms. A specialty retailer runs Agentforce for customer service, a Google Vertex AI agent for demand forecasting, and an AWS Bedrock agent for fraud detection. Pre-Agent Fabric, each lived in its own console with its own logging and its own trust model. With Agent Fabric, all three are auto-registered by Agent Scanners, all three send LLM traffic through the AI Gateway with consolidated cost reporting, and the demand-forecasting agent can call into Salesforce inventory data via an MCP-wrapped Process API rather than a custom integration.

A bank with a high-value transaction guardrail. A regional bank requires human approval before any agent initiates a wire transfer over $50,000. The implementation uses Agent Broker for the deterministic workflow (validate amount, check counterparty, evaluate risk score) and Trusted Agent Identity for step-up mobile authorization on the approval step. The LLM never has the option to skip the approval — the workflow is deterministic by construction.

An IT team with two years of agent sprawl. An enterprise IT team realizes it has 40-plus agents deployed across business units over the previous two years, with no central inventory. Agent Scanners run for the first time and discover them all in hours. The Agent Registry catalogs ownership, tools, and data access. LLM Governance produces the first cross-vendor cost report the CIO has ever seen, and it turns out three teams are paying for redundant fraud-detection agents. Two get retired in the next quarter.

A developer team exposing the integration estate. A platform engineering team owns roughly 200 existing MuleSoft integrations spanning ERP, HRIS, billing, and product telemetry. The business asks them to make these available to Agentforce agents. With MCP Bridge, the team registers the existing API catalog as MCP tools in a single configuration step. There is no API rewrite, no separate "AI integration" project, and no parallel governance regime — Flex Gateway policies they already had on those APIs apply unchanged.

The 2026 Developer Workflow

For developers and architects, Agent Fabric is best understood through the day-to-day flow of building an integration that an agent will eventually call.

You start in Anypoint Code Builder, either as a VS Code extension or in the browser. You design the API contract first, typically in OAS or RAML. A simple System API definition for a customer-lookup tool might begin like this:

#%RAML 1.0
title: Customer Lookup System API
version: v1
baseUri: https://api.example.com/customers/{version}
mediaType: application/json
/customers/{customerId}:
  uriParameters:
    customerId:
      type: string
      description: Salesforce 18-character ID
  get:
    description: Returns the canonical customer record from the system of record.
    responses:
      200:
        body:
          type: Customer
      404:
        description: Customer not found

You implement the flow in Mule, using DataWeave to shape the response. A minimal flow might look like this in MuleSoft's XML configuration:

<flow name="get-customer-flow">
  <http:listener config-ref="HTTP_Listener_config" path="/customers/{customerId}"/>
  <salesforce:query config-ref="Salesforce_Config">
    <salesforce:salesforce-query>
      SELECT Id, Name, Email, AccountId
      FROM Contact
      WHERE Id = ':id'
    </salesforce:salesforce-query>
    <salesforce:parameters>#[{ 'id': attributes.uriParams.customerId }]</salesforce:parameters>
  </salesforce:query>
  <ee:transform>
    <ee:message>
      <ee:set-payload><![CDATA[%dw 2.0
        output application/json
        ---
        {
          id: payload[0].Id,
          name: payload[0].Name,
          email: payload[0].Email,
          accountId: payload[0].AccountId
        }
      ]]></ee:set-payload>
    </ee:message>
  </ee:transform>
</flow>

You deploy to CloudHub 2.0, which provisions Kubernetes replicas, handles auto-scaling, and gives you health checks and metrics out of the box. You publish the API to Anypoint Exchange so other teams can discover and reuse it. Up to this point, this is the same MuleSoft workflow that has existed for years.

The new step happens at the gateway. You wrap the API as an MCP tool through the AI Gateway MCP Bridge with a small configuration that declares the tool's name, description, input schema, and the underlying API endpoint. Once registered, any compliant agent — Agentforce, Bedrock, Vertex AI, Copilot Studio — can discover and invoke customer-lookup as a tool. The AI Gateway applies policies (rate limits, identity verification, data masking) on every invocation, and the call shows up in the LLM Governance dashboard alongside model token usage. If the action is high-risk, you turn on Trusted Agent Identity and require step-up approval. If you need deterministic orchestration around it, you compose an Agent Broker workflow that uses this tool as one step.

The point is that no part of the integration was rebuilt for AI. The same API serves a mobile app, a partner portal, and an agent. The governance applied is the governance the platform team has always applied. The agent layer inherits the integration estate rather than competing with it.

What This Means for Roles in the Salesforce Ecosystem

The role-by-role implications of Agent Fabric are worth being explicit about.

Salesforce admins will not necessarily configure Agent Fabric directly, but they will increasingly find that the Agentforce agents they configure are governed by it. Knowing that an agent's actions can be inventoried in the Agent Registry, that its tool calls can be guarded by Trusted Agent Identity, and that high-risk steps can be wrapped in deterministic Agent Broker workflows changes what is reasonable to delegate to an agent. The conversations with security and risk teams get shorter.

Salesforce developers, including those who primarily write Apex and build Flows, gain a new pattern: when an agent needs to do something that touches an external system, the answer is rarely a custom Apex callout. It is more often "expose the system through a MuleSoft System API, wrap it as an MCP tool, and let the agent discover it." This shifts gravity toward integration-first thinking earlier in the design process.

Architects get the artifact they have been missing. The Agent Registry is the equivalent of an architectural diagram for the agent layer — a single source of truth that captures ownership, data flow, and trust posture. Combined with API-led connectivity, the result is a layered model that is genuinely auditable: agents call tools, tools call APIs, APIs call systems, and every hop is governed at the right layer.

IT leaders and CIOs finally get cross-vendor visibility into AI spend, AI risk, and AI usage. The 2026 Connectivity Benchmark report's finding that 50% of agents operate in silos is not a theoretical risk; it is a near-certain finding for any organization that runs an Agent Scanner for the first time. The board-level story Agent Fabric supports is straightforward: the enterprise has one inventory, one cost view, one trust model, and one place to enforce policy across all agent platforms.

Looking Ahead

The Salesforce 2026 Connectivity Benchmark report's 67% growth projection through 2027 implies that the average enterprise will be running closer to twenty agents within eighteen months. Without a control plane, that number is unmanageable. With one, it is simply scale. MuleSoft's tenth consecutive year in the Gartner Magic Quadrant for iPaaS is a useful proxy for the durability of the underlying platform, and Agent Fabric is best understood as the natural extension of that platform into a new traffic type — agent traffic — that follows many of the same patterns as API traffic but with new requirements around reasoning, identity, and determinism.

The bet implicit in Agent Fabric is that governance, not novelty, will separate the enterprises that get value out of agents from the ones that get burned by them. That is a familiar bet, and MuleSoft has been right about it before. For Salesforce admins, developers, architects, and IT leaders planning their 2026 agent strategy, the practical advice is the same as it was for APIs a decade ago: stand up the registry, put the gateway in the path of the traffic, get visibility before you scale, and treat reuse as a first-class outcome. The platform to do that with is here.