AI & Innovation · MuleSoft · Agentforce

    MuleSoft Agent Fabric: Connect, Govern and Coordinate Your Enterprise AI Agents

    From disconnected agents to a governed network: how the fabric works, where it creates customer value, and how KVP recommends adopting it.

    10 min read•Published October 23, 2026•KVP Expert Team

    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.

    Real network switch with connected Ethernet cables, illustrating enterprise connectivity
    Illustrative infrastructure photograph from Pexels, used under the Pexels licence. Not a product screen or customer deployment.

    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.

    1. 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.

    2. 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.

    3. 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.

    4. 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.

    5. 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.

    Slide deck

    Agent Fabric in six slides

    KVPAgent Fabric1 / 6

    One connected agent ecosystem

    • •Discover agents, APIs and MCP tools.
    • •Map owners and connected platforms.
    • •Reuse capabilities instead of creating silos.

    Validate interfaces, governance coverage and entitlements · kvpcorp.com

    1 of 6

    Shareable infographic

    A one-page guide to connected, governed AI agents

    KVP · Agent Fabric

    One connected agent ecosystem

    Discover agents, APIs and MCP tools. Map owners and connected platforms. Reuse capabilities instead of creating silos.

    Govern runtime communication

    Apply policies through the gateway. Check identity and downstream permissions. Identify calls outside policy coverage.

    Coordinate specialist capabilities

    Use brokers and explicit routing logic. MCP connects tools; A2A connects agents. Guided determinism is not infallible AI.

    Focus on customer outcomes

    Reduce broken handovers and repeated work. Verify transactions in the business system. Measure completion, quality, latency and cost.

    KVP approach: start bounded

    Inventory one valuable customer journey. Test permissions, failure paths and approvals. Expand only after evidence supports it.

    Complement Observability

    Fabric connects and governs the ecosystem. Observability examines Agentforce sessions. Confirm access, telemetry and costs separately.

    Validate interfaces, governance coverage and entitlements · kvpcorp.com

    Closing perspective

    Agent Fabric vs Agentforce Observability: different jobs, complementary value

    Agent Fabric asks how the agent ecosystem connects and is governed. Agentforce Observability asks what happened in an Agentforce session and how to improve its quality. Fabric also provides visibility; Observability also provides proactive alerts. Describing one as purely “active” and the other as purely “passive” misses those overlapping capabilities.

    Primary question

    Agent Fabric: Which agents and tools exist, how do they connect, and which policies govern their calls?

    Observability: What happened in an Agentforce session, how good was the outcome, and what should be improved?

    Scope and emphasis

    Agent Fabric: Connected enterprise agent ecosystem across platforms, APIs, MCP tools and agent networks.

    Observability: Agentforce analytics and session-level evaluation, including supported multi-agent traces and configurations.

    Core capabilities

    Agent Fabric: Registry, gateway policies, broker orchestration, MCP/A2A bridges and network visualization.

    Observability: Session tracing, intent clusters, quality and outcome scores, dashboards, alerts and consumption visibility.

    Operational use

    Agent Fabric: Design and govern runtime communication; inspect dependencies and policy coverage.

    Observability: Investigate failures and quality, prioritize alerts, and validate configuration changes.

    What it does not prove

    Agent Fabric: No universal governance coverage, deterministic AI answers or automatic compliance.

    Observability: No infallible correctness score, access to every private reasoning step or guaranteed business value.

    Commercial boundary

    Agent Fabric: Confirm Agent Fabric access, component entitlements and all runtime/integration costs.

    Observability: Salesforce describes standard Observability as unmetered; net-new customization and external data can remain metered. Agent execution is separate.

    Use Agent Fabric when the challenge is cross-platform discovery, tools, agent delegation and runtime governance. Use Agentforce Observability when the challenge is diagnosing Agentforce sessions, assessing quality and understanding consumption. Use both when the journey needs both disciplines—but validate correlation, telemetry and access rather than assuming a seamless combined console.

    Read our Agentforce Observability guide

    Build a connected agent journey with clear accountability

    Discuss your Salesforce, MuleSoft and cross-platform agent priorities with KVP.

    Talk to KVP

    We value your privacy

    We use cookies to enhance your browsing experience, analyse site traffic, and personalise content. You can choose which cookies you'd like to allow. Learn more