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

If you're an architect at any reasonably large Salesforce shop in 2026, you've probably already lost count of the AI agents floating around your enterprise. There's the Agentforce Service Agent your CX team launched last quarter. There's the Sales Coach agent your RevOps team built in a weekend. Marketing has something running on AWS Bedrock that summarises campaign performance. Finance has a Copilot Studio bot that reads invoice exceptions. Engineering is experimenting with a custom Vertex AI agent for log triage. And nobody — not security, not IT, not the CIO — has a complete inventory of any of it.

This is the problem MuleSoft Agent Fabric was built to solve.

Salesforce announced Agent Fabric as the governance and control plane for the multi-agent enterprise. It's not another agent builder. It's not a competitor to Agentforce. It's the layer that sits above all the agent platforms you already use — Agentforce, Bedrock, Vertex AI, Copilot Studio, custom LangChain stacks — and gives you a single way to discover them, govern their LLM calls, control what tools they can use, enforce budgets and policies, and produce the audit logs your security team has been begging for.

If you came up through MuleSoft the traditional way — building API-led integrations for years — Agent Fabric is the natural next chapter. The same principles that made API-led connectivity work (discoverability, reusability, governance, security) are now being applied to AI agents. This guide walks through what Agent Fabric actually is, how each of its five pillars works in practice, and how to roll it out without melting your platform team.

What MuleSoft Agent Fabric Is (and What It Isn't)

MuleSoft Agent Fabric is a unified governance, discovery, and orchestration plane for AI agents across your enterprise — regardless of which platform those agents were built on. It treats agents the way MuleSoft has always treated APIs: as managed assets with owners, contracts, policies, and audit trails.

Let's be precise about scope. Agent Fabric is not:

• A replacement for Agentforce. Agentforce is still where you build Salesforce-native agents that reason over Data Cloud and execute Flows and Apex.
• A new LLM. It doesn't host models; it governs traffic to whichever models you're already using (OpenAI, Anthropic, Google, Salesforce's xGen, etc.).
• A no-code agent builder. It assumes agents already exist somewhere and gives you a way to manage them collectively.

Agent Fabric is:

• A control plane that intercepts, governs, and audits AI agent activity across platforms.
• A discovery system that auto-detects agents you didn't know existed.
• A bridge that turns your existing MuleSoft API catalog into agent-ready tools using the Model Context Protocol (MCP).
• A deterministic workflow engine for the steps where you can't afford an LLM to "figure it out."

If your CIO is asking "how many AI agents do we actually have, who owns them, what data do they touch, and how much are they costing us per month?" — Agent Fabric is the answer to that question.

The Five Pillars of Agent Fabric

MuleSoft organises Agent Fabric into five capabilities that work together. You can adopt them incrementally — most customers start with Scanners and Registry to get visibility, then layer in AI Gateway for control, then MCP Bridge for actionability.

The mental model: Scanners feed the Registry. The Registry tells the AI Gateway what to govern. The Gateway routes to either probabilistic agents or the deterministic Broker depending on the workflow. And MCP Bridge makes sure that whatever an agent decides to do, it does it through a governed, auditable, well-defined tool — not by hallucinating its way through a SQL query.

Deep Dive: Agent Registry and Scanners

The Agent Registry is, on the surface, the least exciting pillar. It's a catalog. But anyone who's tried to do shadow IT cleanup knows that you can't govern what you can't see, and most enterprises have no idea what AI agents are running where.

The Registry is a system of record for every agent in your enterprise. For each agent, it stores:

• Identity & ownership: who built it, who owns it, what business unit it belongs to
• Technical metadata: which platform it runs on (Agentforce, Bedrock, etc.), which model(s) it calls, which tools/MCP servers it has access to
• Risk posture: what data domains it touches (PII, PHI, financial records), what permissions it has, whether it can write or only read
• Cost telemetry: token usage, monthly spend, rate per call
• Lifecycle status: development, staging, production, deprecated

That's the data layer. The hard part is keeping it accurate, which is where Agent Scanners come in.

How Scanners Work

Scanners are connectors that point at each agent platform you run and continuously discover what's there. MuleSoft ships Scanners for the main platforms enterprises actually use:

• Agentforce Scanner — reads your Salesforce orgs and registers every Agentforce agent, topic, action, and prompt template
• AWS Bedrock Scanner — discovers Bedrock agents, knowledge bases, and action groups across accounts
• Google Vertex AI Scanner — finds Vertex AI agents, reasoning engines, and tools
• Microsoft Copilot Studio Scanner — detects bots, topics, and connectors
• Generic MCP Scanner — discovers any MCP server registered on your network

When a developer spins up a new Agentforce agent in a sandbox, the Agentforce Scanner picks it up on its next sweep, registers it in the Registry, and tags it as environment: sandbox, owner: <user who created it>, status: development. If that same agent gets promoted to production without going through governance review, the Registry flags it. This is how you stop shadow agents.

Practical Setup Pattern

For a typical enterprise rollout, here's a sane Scanner configuration sequence:

1. Run a one-time discovery sweep across all production tenants to populate the Registry baseline.
2. Reconcile the discovered list against your "known" agents. There will be surprises. There are always surprises.
3. Assign owners to every unowned agent. Anything still unowned after 30 days gets a Scanner-generated remediation ticket.
4. Configure continuous discovery on a 4–24 hour cadence depending on platform.
5. Wire the Registry's "new agent detected" event to your ITSM tool so security gets notified the moment something new appears.

Anti-pattern to avoid: treating the Registry as a manual spreadsheet replacement. If your team is hand-typing agent metadata into the Registry, you've missed the point. Scanners do the work; humans curate metadata that Scanners can't see (business owner, compliance classification, etc.).

Deep Dive: AI Gateway

If the Registry is the inventory, the AI Gateway is where governance is actually enforced. Think of it as a reverse proxy that sits between your agents and the rest of the world — every LLM call, every MCP tool invocation, every external API request from an agent flows through it.

The AI Gateway does five jobs:

1. LLM Traffic Governance

Every call from an agent to a model provider (OpenAI, Anthropic, Google, xGen) is intercepted. The Gateway can:

• Route — send certain workloads to cheaper models, route PII-heavy prompts only to compliant regional endpoints, fall back to a secondary provider if the primary is rate-limited
• Cache — semantic cache identical or near-identical prompts to avoid paying for the same answer twice
• Redact — strip credit card numbers, SSNs, or custom regex patterns from prompts before they hit a third-party model
• Inject context — automatically attach grounding context from Data Cloud or other sources

2. Identity Propagation

A common failure mode of enterprise AI is that agents call backend systems as a service account, losing the identity of the human who originated the request. The AI Gateway propagates user identity end to end so that when an Agentforce agent calls a MuleSoft API on behalf of a sales rep, the downstream system sees that rep, not "agentforce-svc."

This is critical for any agent that touches systems with row-level or field-level security. Without identity propagation, you either run wide open (security nightmare) or you can't access anything user-specific (useless agent).

3. Budget Enforcement

The Gateway tracks token consumption per agent, per user, per business unit, and per model. You set budgets and the Gateway enforces them — soft warnings, hard caps, fallback-to-cheaper-model behaviours. This is the single most requested feature from FinOps teams that have just received their first six-figure OpenAI bill.

A practical budget structure looks like:

4. Policy Enforcement

Policies are declarative rules: "no agent in the EU may call a US-region model with prompts containing customer data," "agents tagged risk: high must use models with content filtering enabled," "after 6pm UTC, route to lower-cost models for all non-production agents." The Gateway evaluates every call against the policy bundle and blocks or modifies traffic accordingly.

5. Audit Logging

Every prompt, every response, every tool call, every model used, every cost, every policy decision — logged. Audit logs land in whatever sink you configure (S3, Splunk, Salesforce's own log infrastructure). This is what unlocks SOX, HIPAA, and GDPR conversations because for the first time you have a defensible record of what your AI agents actually did.

Configuration Pattern

You don't deploy a single AI Gateway; you deploy a fleet, typically one per region or per major business domain, all centrally managed from MuleSoft Anypoint. Agents in your registry are bound to a Gateway via configuration, and the Gateway pulls policy from a central policy store. The architecture mirrors the API Manager pattern MuleSoft architects already know — same control-plane / data-plane split, same policy-as-code workflow, same observability story.

Deep Dive: MCP Bridge and Actionability

This pillar is the one that's going to matter most to MuleSoft developers. Actionability, delivered via the MCP Bridge, is how MuleSoft turns its 20-year head start in integration into an unfair advantage in the agent era.

The Problem MCP Bridge Solves

Agents need tools. An Agentforce Service Agent that can answer questions but can't actually do anything (refund an order, update a shipping address, escalate a case) is a chatbot, not an agent. To act, agents need a vocabulary of well-described, well-secured tools.

The standard for describing tools to agents is the Model Context Protocol (MCP) — an open spec originally proposed by Anthropic and now broadly adopted across the industry, including by Salesforce. An MCP server exposes tools (functions) and resources (data) in a format that any MCP-aware agent can consume.

The problem: writing MCP servers from scratch for every backend system you have is enormous work. You'd need MCP servers for SAP, Workday, your shipping providers, your billing system, your custom microservices — and each one needs auth, rate limiting, error handling, and proper tool descriptions.

What MCP Bridge Does

MCP Bridge inspects your existing MuleSoft API catalog — every API spec, every System API, every Process API, every Experience API you've built over the years — and projects them as MCP tools automatically. An OpenAPI spec for "create-shipping-label" becomes an MCP tool called create_shipping_label with the right input schema, the right output schema, and the right description (derived from your API docs) for an LLM to know when to call it.

This is API-led connectivity becoming agent-led actionability. The same three-layer model still works:

• System APIs — connections to systems of record (SAP, Workday, Salesforce, custom DBs)
• Process APIs — orchestrations and business logic
• Experience APIs — channel-specific shapes for web, mobile, partners

What changes: you now have a fourth consumer in addition to web, mobile, and partners — AI agents. And MCP Bridge handles the translation.

Practical Implications

• You don't have to rebuild your integrations. If you've spent the last five years building a clean MuleSoft API estate, MCP Bridge is mostly free leverage.
• Tool quality depends on API documentation quality. Sparse OpenAPI descriptions produce confused agents. Investing in clear, semantic API descriptions pays off twice — once for human developers, once for agents.
• Authorization scopes still apply. When an agent calls an MCP tool, MCP Bridge enforces the same OAuth scopes, the same client credentials, the same identity context that the underlying API was always protected by. Agents don't get a free pass.
• Versioning works. New tool versions get exposed alongside old ones. Agents in the Registry can be pinned to specific tool versions, so a model update doesn't accidentally break a workflow.

Anti-pattern: exposing every internal API as an MCP tool indiscriminately. The result is an agent with a vocabulary so vast it can't reliably pick the right tool. Curate your tool surface area. Ten well-described tools beat a hundred mediocre ones.

Agent Broker: When Determinism Beats Probabilism

The fifth pillar, the Agent Broker, addresses a problem most production AI teams have already discovered the hard way: LLMs are great at fuzzy reasoning, terrible at strict procedural compliance.

If your refund workflow legally requires (1) verifying customer identity, (2) checking that the order is within the refund window, (3) ensuring no chargeback is in flight, (4) calculating partial vs full refund per a complex rules table, and (5) writing a compliance log entry — you do not want an LLM "deciding" how to do any of that. You want a deterministic workflow.

The Agent Broker is essentially MuleSoft's flow engine repackaged for agent contexts. When an agent decides "I need to process a refund," instead of the LLM trying to orchestrate the five steps itself by chaining tool calls (with all the failure modes that implies), it invokes the Agent Broker, which runs a deterministic, versioned, auditable flow that does exactly the right thing every time.

The decision boundary looks like this:

In practice, well-designed agents are hybrids. The LLM handles the conversation, the intent extraction, the natural language understanding. The Broker handles the consequential mutations. This pattern aligns directly with how senior architects already think about Salesforce: Flow for declarative business rules, Apex for procedural logic, and now Agent Broker as the third option for cross-system deterministic workflows that an LLM should not be improvising.

How Agent Fabric Plugs Into Agentforce and the Einstein Trust Layer

For Salesforce-centric architects, the most important question is: how does Agent Fabric fit alongside Agentforce and the Einstein Trust Layer?

The relationship is layered, not overlapping:

• Einstein Trust Layer governs LLM calls originating from Salesforce — Agentforce, Prompt Builder, Einstein Copilot. It handles PII masking, prompt defence, zero-retention agreements with model providers, and toxicity filtering. Trust Layer is excellent at what it does, but its scope is Salesforce-originated traffic.
• MuleSoft AI Gateway governs LLM calls originating from anywhere — Bedrock agents, Vertex agents, custom Python services, third-party SaaS bots. It's the cross-platform equivalent.
• Agent Fabric Registry unifies inventory across both worlds. An Agentforce agent and a Bedrock agent both show up in the same Registry, with the same metadata schema.
• MCP Bridge is the bidirectional connector. Agentforce agents can call MuleSoft APIs as MCP tools through MCP Bridge. Non-Salesforce agents can call into Salesforce data and actions through Salesforce-published MCP servers.

This means the answer to "do I need Agent Fabric if I'm only using Agentforce?" is "probably yes, but the priorities are different." Even Agentforce-only shops benefit from MCP Bridge (your existing MuleSoft APIs become Agentforce tools without custom work) and from the Registry (audit-grade inventory). They benefit less from AI Gateway since Trust Layer covers Salesforce-originated traffic. As soon as you add a second agent platform — and most enterprises will — Agent Fabric becomes essential rather than optional.

Implementation Roadmap

Here's a phased rollout that's worked for early adopters:

Phase 1: Visibility (Weeks 1–4)

• Stand up the Registry in your MuleSoft Anypoint Platform tenant.
• Deploy Agent Scanners for every platform you know you have agents on. Start with read-only access.
• Run discovery and reconcile against known inventory. Expect 20–40% more agents than you thought existed.
• Assign owners. Get every agent into the Registry with at least owner, environment, and status fields populated.

Exit criteria: every production agent has an entry in the Registry with a named human owner.

Phase 2: Governance (Weeks 5–10)

• Deploy AI Gateway in your most regulated region first.
• Pick one high-traffic agent — typically the customer service agent — and route its LLM traffic through the Gateway. This is where you'll find your first integration bugs.
• Configure baseline policies: PII redaction, audit logging, cost tracking.
• Roll out budgets gradually — soft warnings for two weeks, then throttling, then hard caps.

Exit criteria: you can produce a per-agent cost report and a per-agent prompt audit log on demand.

Phase 3: Actionability (Weeks 11–16)

• Stand up MCP Bridge against your existing MuleSoft API catalog.
• Curate the first set of tools — start with 10–20 high-value, well-documented APIs.
• Wire your top Agentforce or Bedrock agent to consume these MCP tools.
• Establish an internal certification process for "agent-ready APIs" — what description quality, what auth posture, what error handling.

Exit criteria: a measurable shift of agent actions from custom tool implementations to MCP Bridge-served tools.

Phase 4: Determinism (Weeks 17+)

• Identify the top three workflows where LLM probabilism is causing risk (refunds, account changes, compliance reporting are common).
• Build deterministic Agent Broker flows for these.
• Refactor the relevant agents to delegate to the Broker rather than orchestrate via tool chaining.

Exit criteria: the workflows that require deterministic execution actually execute deterministically, with audit logs that prove it.

Common Pitfalls

A few things that go wrong if you're not careful:

• Skipping the Registry. Teams that jump straight to AI Gateway end up governing traffic without knowing whose traffic it is. Owners and metadata first, controls second.
• Over-policing in week one. If you turn on hard cost caps and aggressive PII redaction on day one, you'll break agents and burn political capital. Soft warnings, then enforcement.
• Treating MCP Bridge as a magic wand. A poorly documented API becomes a poorly described MCP tool, which becomes a confused agent. Bridge amplifies whatever quality your API estate already has.
• Forgetting identity propagation. Service-account-only agent calls are a security finding waiting to happen. Configure user identity passthrough early.

FAQ

Q: Do I need MuleSoft Agent Fabric if I only use Agentforce?

A: It's not strictly required, but you'll still benefit from MCP Bridge (turning your MuleSoft APIs into Agentforce tools without custom development) and from the Registry (defensible inventory and audit). The AI Gateway pillar is largely redundant with Einstein Trust Layer for Agentforce-only shops. The moment you add a second agent platform — Bedrock, Vertex, Copilot Studio — Agent Fabric becomes the only sensible governance approach.

Q: How does Agent Fabric pricing work?

A: Agent Fabric is licensed as part of the MuleSoft Anypoint Platform with usage-based components for AI Gateway traffic and Scanner discovery. Salesforce typically bundles it in larger Agentforce + MuleSoft + Data 360 deals. Pricing details change frequently, so check with your account executive for current SKUs.

Q: Is MCP a Salesforce/MuleSoft proprietary protocol?

A: No. MCP (Model Context Protocol) was originally introduced by Anthropic as an open specification, and Salesforce has adopted it for both Agentforce and MuleSoft Agent Fabric. Tools you expose via MCP Bridge are consumable by any MCP-aware agent — Anthropic's Claude, OpenAI agents, Bedrock agents, and others — not just Agentforce.

Q: What's the difference between Agent Broker and a regular MuleSoft flow?

A: Architecturally, they're closely related — Agent Broker uses MuleSoft's flow engine under the hood. The difference is contextual integration. Agent Broker flows are first-class citizens in the Agent Registry, expose themselves to agents via MCP, accept agent-friendly inputs (often natural-language-derived structured data), and produce outputs the agent can reason over. A regular MuleSoft flow can be wrapped to do the same, but Agent Broker handles that wrapping for you.

Q: How does Agent Fabric handle multi-tenant Salesforce orgs?

A: Each org appears as a separate scope in the Registry, and Scanners can sweep multiple orgs in parallel. Policies in the AI Gateway can be scoped at the global, org, business unit, or individual-agent level. For ISVs and consulting firms managing many client orgs, this multi-tenant scope hierarchy is one of the strongest reasons to adopt Agent Fabric early — manual inventory of agents across dozens of customer orgs is not sustainable.

The pattern that's emerging across early Agent Fabric implementations is that the enterprises winning with AI agents aren't the ones with the cleverest prompts or the biggest models. They're the ones who treat agents like every other enterprise asset — with owners, with budgets, with policies, with audit trails, and with the same operational discipline they apply to APIs and databases. Agent Fabric is the toolkit that makes that discipline possible. If your AI strategy in 2026 is going beyond a single Agentforce deployment, this is the layer that turns enthusiasm into something a CISO can actually sign off on.