Quick Answer
What is Agent Fabric?
MuleSoft Agent Fabric is a control plane for discovering, connecting, governing and observing AI agents, APIs and MCP tools across connected enterprise platforms. Its registry, gateway, brokers and visualizer help organizations reuse capabilities and coordinate work with clearer runtime controls. It is not another standalone customer-service agent: it is the connective and governance layer around a network of agents and tools.

Why an enterprise needs more than individual AI agents
A sales assistant may work in Salesforce, a stock-check capability in an ERP system and another specialist agent on a different AI platform. Each can be useful in isolation. The difficulty begins when a customer journey needs them to cooperate: who owns each capability, what can it access, how is the task handed over, and where can a failed request be traced?
The Salesforce Agent Fabric overview addresses this fragmented estate. The goal is not to move every agent into one vendor’s runtime; it is to create a connected, governed ecosystem around supported interfaces. Existing APIs remain important because they provide a controlled route into systems that hold the authoritative business records.
For existing Salesforce customers, that can extend an Agentforce journey beyond CRM while preserving responsibility for the underlying integration and permissions. For multi-platform organizations, it offers a way to manage shared capabilities without pretending that all agents have the same interface, security model or operational behavior.
Six core Agent Fabric capabilities
Registry: discover what already exists
Catalog agents, MCP servers, APIs and related services across connected platforms. Document capabilities, ownership and versions so teams can find a suitable existing asset rather than build another disconnected agent. Registry views can include conformance and instance-health information. An inventory is only as complete as its connected sources and registration process; discovery does not automatically place every asset under runtime control.
Gateway: govern the calls that cross boundaries
Omni Gateway provides a runtime path for applying configured policies to agent, MCP-server and LLM traffic. Teams can manage access and other supported controls centrally instead of relying only on prompts inside each agent. Coverage depends on the actual traffic path: an agent calling an ungoverned endpoint directly can sit outside those protections. Identity, credentials and the downstream system’s permissions still need explicit design.
Broker: coordinate specialist agents
Agent networks compose agents, brokers, LLMs and MCP servers. A network definition and Agent Script routing logic describe how work is delegated. A broker can coordinate specialist capabilities rather than require one agent to know everything. MuleSoft describes guided determinism: explicit routing can constrain the workflow, but downstream LLM responses remain probabilistic. This is not a promise of deterministic answers or error-free autonomous execution.
MCP bridges: turn selected APIs into tools
Model Context Protocol gives an AI application a structured way to discover and call tools. MuleSoft’s MCP bridge can expose selected operations from an existing API without changing that underlying API. Start with narrowly scoped read operations and deliberately approve any write or delete operation. Tool availability does not mean unrestricted access: validate inputs, enforce authorization and check the transaction result.
A2A bridges: connect different agent interfaces
Agent-to-Agent supports task communication between agents. Not every agent is natively A2A-compliant; MuleSoft documents a bridge that presents an A2A facade and translates to the source agent’s interface, including task lifecycle handling. Confirm compatibility for each platform and version instead of assuming every Salesforce or third-party agent connects without adaptation.
Visualizer: see the network and governance gaps
Agent Visualizer maps connected agents, MCP servers and LLMs, their call relationships and real-time call volume. It can help identify agents without Omni Gateway policy coverage. That helps operators investigate dependencies and gaps across the estate. A network graph is not a complete record of private model reasoning, and the available signals depend on connected runtime and monitoring configuration.
How Agent Fabric works, step by step
A typical adoption sequence connects discovery, interfaces, policies, delegation and operational review. These are architecture steps—not a claim that every request always passes through a fixed five-stage product pipeline.
- 01
Register capabilities and accountable owners
Identify the agents, APIs and tools needed for one journey. Record what each can do, the data it may access and who maintains it. Reuse trusted assets where possible, and mark unsupported or ungoverned endpoints before connecting them.
- 02
Expose only the required tools and interfaces
Use an MCP bridge for selected API operations and an A2A bridge where an agent needs interface adaptation. Keep tool descriptions clear and validate arguments against the underlying business contract. A connector does not remove the need for integration testing.
- 03
Apply policies on the runtime path
Route the relevant calls through the configured gateway. Test identities, permissions, limits and failure handling. Business approvals must be implemented in the workflow and authoritative system; do not assume a built-in mobile sign-off applies to every high-risk action.
- 04
Coordinate a bounded task
Configure the broker to delegate work to the appropriate specialist agents and tools. Define how tasks pass context, time out, escalate and recover. Keep financial commitments and sensitive changes behind explicit approval rather than granting open-ended autonomy.
- 05
Observe, verify and improve
Review the network’s activity and policy coverage, correlate evidence with actual transaction results and investigate failures. Add Agentforce Observability for deeper Agentforce session and quality analysis where appropriate. Use the evidence to make tested, reversible changes.
An example: coordinating a manufacturing service request
A customer asks for a replacement component and an engineer visit. An Agentforce service agent captures the equipment reference and case context. A configured network delegates a stock lookup to an ERP-backed tool and a scheduling check to a specialist capability. MCP can expose the approved lookup operations; A2A can support the agent task handover where the interfaces require it.
Calls follow the configured gateway policies and downstream authorization. If the request involves a chargeable order, the workflow asks an authorized person to approve it before the business system creates the transaction. Failure to retrieve inventory should produce a clear escalation—not an invented delivery promise.
Operators then inspect the call relationships and governance coverage in Agent Fabric. They can use Agentforce Observability to investigate the Salesforce agent’s session, actions and quality signals. The order and appointment records—not an agent’s confident reply—confirm completion.
Illustrative architecture, not a reported KVP deployment, prebuilt integration or measured customer result. Exact capabilities depend on configuration and entitlements.
How Agent Fabric can benefit customers
Customers: a more connected service journey
A service request can draw on CRM context, inventory information and a specialist scheduling capability without requiring the customer to repeat the same information at each handover. The benefit depends on correct identity matching, fresh data and reliable integration. Measure completed requests, repeat contacts and handover quality—not just the number of agent calls.
Business leaders: reuse instead of agent sprawl
A shared catalogue makes existing capabilities easier to find. A well-defined stock-check tool or policy agent can serve multiple journeys, reducing unnecessary duplication. Assign ownership and track reuse, maintenance effort and adoption; do not assume adding a registry will automatically reduce operating cost.
Security and governance: clearer control coverage
Central policies and a visible network help teams ask which agent can invoke which tool, where sensitive data travels and which calls bypass the intended gateway. This supports review and remediation. It does not certify compliance, eliminate prompt injection or replace privacy, retention and least-privilege controls.
IT and finance: manageable dependencies and spending
A cross-platform view can support capacity planning, incident diagnosis and review of AI usage. Consider gateway/runtime costs, model calls, downstream APIs and implementation effort together. Agree a cost per verified business outcome and validate which cost controls and monitoring capabilities are available in your deployment.
KVP view: connect a valuable journey, not every agent at once
Start with the business boundary. Choose a journey that genuinely needs multiple systems or specialist agents. If one well-scoped Agentforce agent and a secure API action already solve the problem, do not add a broker simply to make the diagram more sophisticated. Agent Fabric becomes more relevant as reuse, cross-platform coordination and governance complexity increase.
Treat integration design as an AI foundation. Clear API contracts, consistent identifiers and data ownership still matter. KVP recommends reviewing these before exposing tools to agents. An AI layer cannot repair missing inventory records or a permission model that grants excessive access.
Separate decisions from commitments. An agent can collect information and suggest a next step. Pricing, order creation, financial adjustments and sensitive changes need validation and the appropriate approval. Design that boundary into the workflow and system of record—not just a natural-language instruction.
Prove the failure paths as well as the happy path. Test tool denial, missing data, timeouts, malicious instructions in external content and duplicate requests. Define escalation, rollback and ownership. Compare verified completion, error rates, latency and total cost against a baseline before adding more agents.
Where KVP can help. Scope the journey, inventory the existing Salesforce and MuleSoft estate, map agent/tool interfaces, design gateway policies and approvals, test a bounded pilot and establish run operations. This is KVP’s recommended engagement approach, not a claim that the architecture described here has already delivered quantified results.
Readiness, licensing and cost: check before committing
MuleSoft’s getting-started documentation requires appropriate product access and permissions. AI-assisted features require generative AI enablement; linked Salesforce organizations and individual components can have their own setup requirements.
Confirm component availability, regional access, platform compatibility and contractual entitlements with Salesforce or MuleSoft. Do not assume Agent Fabric is bundled with every MuleSoft or Agentforce licence, that all documented features are enabled in your organization, or that standard Observability pricing applies to Agent Fabric.
Include model calls, gateway and runtime use, downstream API charges, implementation and ongoing operations in the business case. Review data residency, credentials, retention and logging before sending sensitive customer information across platforms. Governance coverage depends on the actual integration and traffic paths you deploy.
Frequently asked questions
What is MuleSoft Agent Fabric?
MuleSoft Agent Fabric is a control plane for discovering, connecting, governing and observing agents, APIs and MCP tools across connected platforms. It combines asset discovery, runtime policies, agent coordination and network visibility; it does not replace the agents or authoritative business systems.
How does Agent Fabric work with Agentforce?
Agent Fabric can connect Agentforce capabilities into a wider agent ecosystem using supported interfaces and, where needed, an A2A bridge. Compatibility, credentials, task handling and governance paths need configuration and testing. It is not automatically enabled for every Salesforce organization.
What is the difference between MCP and A2A?
MCP provides a structured interface to tools and contextual capabilities, such as selected API operations. A2A supports agent-to-agent task communication. Agent Fabric can use both; neither protocol by itself grants permission or guarantees a correct business outcome.
Does the Agent Broker make AI deterministic?
No. Explicit network and routing logic can constrain task delegation, which MuleSoft describes as guided determinism. LLM-based actions remain probabilistic, so teams still need evaluation, validation, failure handling and human approval for sensitive work.
Does Agent Fabric replace Agentforce Observability?
No. Agent Fabric emphasizes cross-platform inventory, connectivity, runtime governance and orchestration. Agentforce Observability emphasizes Agentforce sessions, quality, alerts and consumption. Their visibility capabilities overlap, but they answer different operational questions and may be used together after validating telemetry and product access.
Is Agent Fabric included with every MuleSoft or Salesforce licence?
Do not assume it is. MuleSoft documentation requires appropriate product access and permissions, and AI-assisted features require generative AI to be enabled. Confirm component availability, regional access, contractual entitlements and usage costs with Salesforce or MuleSoft before planning a rollout.
Official sources and editorial scope
Published October 23, 2026, using official Salesforce and MuleSoft product documentation. Documentation evolves; confirm current availability and commercial terms for your organization. KVP commentary describes recommended architecture and potential benefits, not guaranteed compliance or realized customer outcomes.
Agent Fabric