How Salesforce tames agent sprawl with Agent Fabric

The problem enterprises are running into

Every enterprise racing into agentic AI is hitting the same wall: agent sprawl. Teams stand up agents on whatever platform suits their use cases — Agentforce here, a custom Python service there, a Bedrock agent somewhere else — and each one works in isolation. That creates three concrete problems:

• Siloed execution. Agents built on different platforms don’t talk to each other by default. Getting anything done across them means manual handoffs between tools and, often, between people.
• No task routing. Without an orchestration layer, there’s no intelligence deciding which agent or tool should handle which part of a request. Every integration is bespoke.
• No trace when things break. When a multi-agent workflow fails, there’s no record of which agent did what, in what order, or why.

Agent Fabric exists to solve exactly this: a single orchestration and governance layer that discovers agents and tools wherever they live, governs access to them with the same policy framework MuleSoft already uses for APIs, and orchestrates them into unified, auditable workflows — without requiring anyone to rebuild the agents themselves.

Just like other enterprises, Salesforce is also experiencing these challenges. Our own Internal IT team turned to Agent Fabric to manage multi-agent systems. In this article, we will tell you a real internal deployment — the MuleOps Intelligence Broker — to show what that looks like in practice.

Implementing Agent Fabric for Production Support

Salesforce’s own IT team has already been leveraging MuleSoft’s capabilities, running more than 2,000 APIs and integration applications across internal business units. The trigger for this build wasn’t agent sprawl itself — it was a plain operational problem upstream of it: our operations engineers were switching between three separate tools — PagerDuty for alerts, Splunk for logs, and Anypoint Platform/CloudHub for application status — just to triage a single production incident. Most of the time spent on an incident was spent navigating tools, not analyzing issues and solving the problem.

We used Agent Fabric to build the MuleOps Intelligence Broker: an agent network that orchestrates three specialist agents — one each for PagerDuty, Splunk, and CloudHub application data — behind a single conversational entry point in Slack. Here’s how the three pillars show up in that build.

1. Discover

Just as MuleSoft developers already discover API assets in Anypoint Exchange, agentic assets — A2A agents, LLMs and MCP servers — are published and discoverable the same way through Agent Registry.

Agent Fabric centralizes discovery into one authoritative catalog, the Agent Registry, which stores every agentic asset such as AI agent, LLM model or MCP server across the enterprise with standardized metadata – “What exists, where it lives, and how it connects.” Once registered, assets are “ready to be reused or composed into solutions” by developers or agents.

There are two paths to agentic asset registration – an automatic registration via Agent Scanner or a flexible manual registration:

• Automated discovery via Agent Scanners – connectors that point at each agent supported platform (e.g. AWS, Bedrock/AgentCore, Google Vertex AI, Microsoft, Databricks, Kong, Agentforce, etc), run on a schedule or on demand, and automatically register any agents, APIs and MCP servers they find into the matching catalog. Discovered agents can then be reviewed and added to the registry with standardized metadata. You can see last-run results and how many assets each scan finds.
• Flexible manual registration – for homegrown agents and MCP servers that the scanner cannot reach, you register them by simply pasting a URL to the agent card or MCP server schema into the register or simply by uploading their spec yaml files (note: registering it via uploading the schema file requires on-going review and maintenance when the schema is changed).

In our use case, after publishing our agent network, the broker itself has a discoverable card describing its skills in plain language (PagerDuty incident management, Splunk log search, CloudHub monitoring). Each specialist agent underneath it is independently discoverable too: a team that only needs Splunk log search for an unrelated workflow can request access to that agent directly, without going through the broker at all. Build once, reuse everywhere.

As you can see, the discovery model works at every level — broker, agent, and tool. All visible, all governed, all in one place.

2. Govern

Agentic assets in Agent Fabric are governed by the same API Manager and Omni Gateway policy — the same gateway that protects and manages APIs today; there’s no separate governance layer to learn. Every agent, MCP server, and sub-agent proxy in the network shows up as a first-class managed instance.

As a concrete example, the Splunk MCP server in this network has four inbound policies enforced at the gateway: Client ID Enforcement (no valid credentials, no access), Message Logging (for troubleshooting and audit), a custom threat-prevention policy (monitoring for and blocking suspicious traffic) in Wallarm, and Rate Limiting (preventing any single consumer from overwhelming the endpoint). An outbound policy separately injects the credentials needed to reach the upstream Splunk MCP runtime — the broker itself never has to hold or manage that secret.

The key point here is that many of these are the same policies you would apply to any API. Agents and MCP servers get the same level of security that your mule enterprise APIs already have.

3. Orchestrate — the deep dive

This is where the MuleOps Intelligence Broker itself lives, and where the rest of this post focuses.

Inside the orchestration: what the broker actually does

The broker is defined as declarative YAML plus an Agent Script, a Salesforce’s open-source scripting language that combines the flexibility of natural language instructions for handling conversational tasks with the reliability of programmatic expressions for handling business rules — no custom orchestration framework, no hand-rolled routing code. Here’s the shape of it.

Declarative by design – No Custom Orchestration Code to Write

This is the point that matters most for anyone picturing what it’s actually like to build with Agent Fabric: you don’t write orchestration code. You describe the orchestration.

A network is a YAML file (agent-network.yaml) that registers each agent and connection, plus an Agent Script file that lays out the broker’s own reasoning as a small set of named steps — a classifier, a router, a subagent per specialist, and the responses each path ends in. What you’re actually authoring is system prompts and instructions: what the classifier should watch for, what each specialist is allowed to do, how a response should be worded. MuleSoft’s tooling takes that description and turns it into a running, visualized graph — Anypoint Code Builder renders the network as an interactive canvas alongside the YAML, so you can see the trigger, the classifier, the router’s branches, each specialist subagent, and every terminal response as connected nodes, live, as you edit.

MuleSoft handles everything the YAML doesn’t spell out: deploying the network, binding the security policies to every connection, and wiring up the intelligent routing between nodes. The developer’s job is describing intent — not building a routing engine, not writing glue code between agents, not managing the plumbing that gets a request from one specialist to the next. That’s the same shift APIs went through with declarative connectors years ago, now applied to orchestrating agents.

After an agent network is deployed to CloudHub, teams can leverage the Agent Network Tracer to test out and validate the capabilities of the agent network with stakeholders before spending their time building out the user experience to interact with the broker. The Agent Network Tracer uses the same Anypoint login and it shows the details for each agent interaction.

The topology

The network wires together:

• PagerDuty Specialist — incidents, alerts, services, teams, on-call schedules, escalation policies.
• Splunk Specialist — SPL log search, index/sourcetype discovery, error investigation, and Application Data Observability (ADO) alert lookups.
• Integration System Agent — CloudHub application status, deployment guidance, vCore optimization.
• A Gemini LLM connection that powers the broker’s own reasoning.

What’s notable isn’t just what’s connected — it’s where those pieces actually run. The PagerDuty MCP server runs on Heroku. The PagerDuty and Splunk agents run on AWS. The Splunk MCP server runs on internal infrastructure managed by our internal SRE team. The Integration System agent is an Agentforce agent running inside a Salesforce instance. Four different runtimes, four different operating teams — and Agent Fabric governs and orchestrates all of them as one governed network. It genuinely does not matter where an agent or MCP server lives.

There are five things worth calling out for anyone evaluating this pattern.

1. Agent memory and multi-turn conversation

Ops incidents rarely resolve in a single question. The broker preserves conversation context across turns via a contextId: a user can ask “who’s on-call for DET-Wallarm service?” and then, in the same thread, follow up with “check the Default escalation policy” without re-stating the service name — the broker carries that context forward automatically. This turns the broker from a stateless Q&A bot into something closer to an actual conversational teammate.

// Turn 1 — response (illustrative) { "jsonrpc": "2.0", "id": "1", "result": { "task": { "contextId": "ctx-7f3a9c21", "status": { "state": "TASK_STATE_COMPLETED", "message": { "parts": [ { "text": "Jane Doe is on-call for DET-Wallarm-Prod, per the Default escalation policy." } ] } } } } }

# Turn 2 — reuse the contextId from turn 1, new messageId CTX='ctx-7f3a9c21'

curl -X POST "$BROKER_BASE/" \ -H "Content-Type: application/json" \ -H "Accept: application/json" \ -H "A2A-Version: 1.0" \ -H "client_id: $MAF_CLIENT_ID" \ -H "client_secret: $MAF_CLIENT_SECRET" \ -d '{ "jsonrpc": "2.0", "id": "2", "method": "SendMessage", "params": { "message": { "role": "ROLE_USER", "contextId": "'"$CTX"'", "messageId": "test-0002", "parts": [ { "text": "Check the Default escalation policy." } ] } } }'

// Turn 2 — response (illustrative). No service name repeated — the broker // carried "DET-Wallarm-Prod" forward from turn 1's context. { "jsonrpc": "2.0", "id": "2", "result": { "task": { "contextId": "ctx-7f3a9c21", "status": { "state": "TASK_STATE_COMPLETED", "message": { "parts": [ { "text": "The Default escalation policy for DET-Wallarm-Prod escalates to Jane Doe first, then the on-call manager after 15 minutes." } ] } } } } }

2. A2A support for Agentforce agents, governed by policy

The Integration System Agent isn’t something we built for this project — it’s an Agentforce service agent we built and shipped 2 years ago, well before Agent Fabric existed as an option. We didn’t rebuild it or change a single line of it. We brought it into the network as-is, over the A2A protocol via an A2A policy for Agentforce, and its existing skills became available alongside the PagerDuty and Splunk specialists with no rework on the Agentforce side.

That’s a significant part of the pitch for enterprises with agents already scattered across vendor platforms: Agent Fabric doesn’t require standardizing on one agent framework. Any agent that speaks A2A — regardless of where it was built or who owns it — can be governed with the same Omni Gateway policies as everything else and slotted into an orchestration graph.

3. Agent Script for deterministic workflows

Not every step in an agentic workflow should be a coin-flip left to an LLM. The broker’s routing is explicitly built as a deterministic state machine, not a single free-form LLM call deciding everything:

• A generator node classifies the incoming query into a typed route (PagerDuty / Splunk / Integration Platform / general question / out-of-scope / needs clarification) — one cheap LLM call, no tool access, so it cannot answer on its own.
• A router node then branches deterministically on that classification — no additional LLM call, no ambiguity about which specialist gets invoked. In this case, the router checks the prefix of the incoming message. If the message satisfies one of the conditions specified in the “fastPath” router, it will route directly to the corresponding subagents without going through the broker LLM call.
• Each specialist has its own dedicated subagent node, hard-instructed to call its bound action and never answer from its own knowledge — which forecloses the common failure mode of an orchestrator “answering” a question without actually checking the source system.

This is deliberate: it gives each specialist its own independently-tunable reasoning budget, keeps each specialist’s prompt isolated from the others, and makes the control flow inspectable and testable rather than an opaque prompt. Deterministic where the logic actually is fixed; probabilistic only where the decision genuinely requires judgment (classifying an ambiguous query).

4. Zero-trust agent-to-agent communication

Every connection in the network authenticates independently — there is no implicit trust between the broker and its own sub-agents just because they’re part of the same network. Concretely: no consumer, including the broker itself, ever calls an agent or MCP server’s implementation runtime directly. Every call passes through a managed Flex Gateway proxy in front of that runtime. The broker holds no credentials for the systems it talks to — Agent Fabric injects the right credentials at the proxy layer at call time, and those secrets live in the Anypoint Control Plane, never in orchestration code.

That gives every agent-to-agent call in the network the same authentication and policy enforcement as a call from an external consumer — including calls the broker makes to its own specialists. It also means each agent can carry its own policies (e.g., a different rate limit for AI traffic than for human developer traffic) without affecting the rest of the network. As enterprises push toward more autonomous, agent-initiated workflows — not just a human asking a question, but one agent or automated process invoking another — this per-call, no-implicit-trust model is what actually makes that safe to scale.

In other words, the broker never holds any secrets. When it needs to talk to the Splunk agent, it does not carry credentials. Agent Fabric automatically injects the right credentials at the proxy layer at runtime. Secrets are managed in the Anypoint Control Plane – never hardcoded in the orchestration logic.

This gives you zero-trust agent-to-agent communication. Even internal calls between the broker and its own sub-agents are fully authenticated. And because each agent has its own proxy, you can apply agent-specific policies – for example, rate-limiting AI traffic differently from human developer traffic – without affecting other consumers.

The bottom line is that every agent becomes a pluggable, self-secured asset. Adding a new agent to the network means registering it and configuring its omni gateway policies. Agent Fabric handles the rest – proxy creation, credential binding and intelligent routing.

5. One Slack interface for everything the broker can do

None of this matters to an ops engineer if it still requires three logins. The broker is fronted by a Slack integration: engineers mention the broker in their existing operations channel, ask a question in plain language, and get an answer in the thread — covering PagerDuty, Splunk, and CloudHub, without ever leaving Slack. They don’t log into PagerDuty. They don’t open Splunk. They don’t browse Anypoint Platform. One interface, three systems’ worth of capability, in the channel where the team already collaborates.

And because every one of those interactions runs through the broker, it also becomes a traceable, auditable unit of work — visible end-to-end in Agent Fabric’s network tracer, showing which specialist was chosen and why. It’s not a black box: every routing decision the broker makes is logged and inspectable after the fact.

Why this matters beyond one broker

Today, a human agent asks the MuleOps Intelligence Broker a question in Slack. Tomorrow, another agent or an automated workflow can invoke the exact same broker programmatically — the plumbing doesn’t change. That’s the point: this isn’t a one-off integration, it’s a reusable pattern. Adding a new agent to the network means registering it and configuring its gateway policies; Agent Fabric handles proxy creation, credential binding, and routing. Every agent becomes a pluggable, self-secured asset — and existing agent investments (like the Agentforce agent we built a year before Agent Fabric existed) don’t get thrown away, they get reused.

For enterprises further behind on agentic transformation, the core message is the same one that showed up building this: it doesn’t matter what platform an agent runs on or who built it. If it can be discovered, governed, and orchestrated through one control plane, it can be part of one coherent, auditable, zero-trust network — instead of one more silo.

For Salesforce, that’s the payoff. Today, support engineers spend about 15 minutes of active effort per alert, roughly 550 hours a month, or 6,600 hours a year. By removing the tool-switching and manual diagnostic gathering described at the start of this post, the MuleOps Intelligence Broker targets an average handling time of 10 minutes per alert. That would return about a third of that effort, roughly 2,200 hours a year, to the team.