Walk into any enterprise IT meeting in 2026 and ask a simple question: how many AI agents are running in your environment right now? You will get one of two answers. Either a confident “around 30, give or take,” which is almost always wrong, or an honest shrug. Both answers point to the same problem.

Marketing has an Agentforce SDR agent. Service has a triage bot built on Amazon Bedrock. Finance is piloting something on Microsoft Foundry. The SaaS apps everyone uses are quietly shipping their own agents inside their products. And somewhere in engineering, a team built a custom agent on OpenAI last quarter that nobody outside that team knows about. Each one looked like a productivity win in isolation. Together, they look like 2014’s SaaS sprawl, except now the rogue tools can write to your database.

Andrew Comstock, SVP and GM of MuleSoft, called this out plainly. The reality is that most enterprises live in a multi-vendor world, and AI will not change that. The strategic challenge is no longer building a single agent. It is making all of them work together without burning down the house.

Salesforce launched MuleSoft Agent Fabric in September 2025 as a direct response. At TDX 2026 in mid-April, they expanded it significantly with new discovery, authoring, and governance capabilities. The pitch is simple: a single control plane for every agent in your enterprise, regardless of where it was built or which LLM powers it. The execution, as always, is more complicated than the pitch.

If you have spent any time with MuleSoft, the four-pillar structure of Agent Fabric will feel familiar. That is intentional. The team behind Agent Fabric took the API management playbook (Anypoint Exchange, API Manager, Flex Gateway, Anypoint Monitoring) and applied it to a new asset type: AI agents. The naming is different, the protocols are new, but the architectural logic is the same one MuleSoft has been refining for over a decade.

Here is what each pillar actually does, and why each one matters when you are running 50 agents instead of 5.

The pillars are designed to work together, but they do not have to. You can adopt Agent Fabric purely as a registry and governance layer while keeping your existing orchestration. You can use Agent Broker for orchestration while routing governance through a different platform. The modularity is the point. Most enterprises will start with one pillar and expand outward, which is exactly the right approach.

The Two Protocols You Need to Care About

Agent Fabric is built on two open standards that together define how agents talk to anything else: MCP (Model Context Protocol) and A2A (Agent-to-Agent). The distinction matters more than the marketing makes it sound.

Most teams skim past this part of the documentation, which is a mistake. Agent Fabric uses a specification-first model: every agent network is defined in a YAML file, and that YAML is what gets registered, deployed, governed, and versioned. The execution runtime is decoupled from the definition, which is the same pattern that made Kubernetes manifests and OpenAPI specs so durable.

Here is what that looks like in practice. You open Anypoint Code Builder, run the “Create an Agent Network Project” command, and get two files: agent-network.yaml and exchange.json. The YAML defines your brokers, the agents and MCP servers they can call, the LLM providers they use, and the policies that apply. That single file becomes the source of truth.

YAML# Simplified agent-network.yaml structure
brokers:
  - name: order-fulfillment-broker
    card:
      name: "Order Fulfillment Broker"
      skills: ["verify-customer", "allocate-inventory", "calculate-shipping"]
    spec:
      llm: claude-sonnet-4
      tools:
        - mcp: inventory-mcp-server
          allowed: ["check_stock", "reserve_units"]
      links:
        - agent: salesforce-customer-agent
        - agent: stripe-payment-agent
      policies:
        - pii-detector
        - prompt-guard
        - schema-validation

The reason this matters: portability. The same YAML can move between dev, staging, and production. Roles, regions, and subsidiaries can fork the definition without rebuilding flows. Versioning is built in. Audit trails are inherent. When the SOC team asks which agent had access to PII last Tuesday, you have an answer instead of a search party.

What Goes in a Broker Definition

A broker definition has two main sections: card and spec. The card follows the A2A specification and describes the broker’s contract: skills, capabilities, and how other agents can find it. The spec is where the actual logic lives.

This is the part of Agent Fabric most teams will get wrong on the first try. The intuitive design, when you have a handful of specialist agents, is to put a single super-broker at the top with access to all of them. Every request hits the super-broker, the super-broker picks the right agent, and the agent does its thing. Clean. Simple. Wrong.

The Salesforce architecture team is direct about this in their MuleSoft Agent Fabric Deep Dive: a flat, unrestricted architecture proves detrimental to overall efficiency and reliability as soon as the system grows. The reason is the LLM context window. The broker has to load the description and capability metadata for every agent it might call. Past about 20-25 entries, decision quality drops noticeably. The broker suffers from option paralysis, routing slows down, and consistency breaks.

The Hierarchical Alternative

The recommended pattern is a multi-level hierarchy that mirrors how real organizations work. A top-level broker delegates to domain-level sub-brokers, which delegate to specialist brokers, which finally call leaf agents that do the actual work. Each layer only loads the agents directly beneath it into context, which keeps token usage under control and decision quality high.

Salesforce architects describe two ways to slice the hierarchy. The first follows Conway’s Law: model the agent network on your real-world org chart. The C-suite, VPs, directors, and managers map to broker layers. Specialists and individual contributors map to leaf agents. Intuitive, easy to explain to business stakeholders, and matches the way humans already think about delegation.

The downside of the org chart approach is that companies reorganize. Every reorg becomes an agent network rebuild. The alternative is Domain-Driven Design: organize agents by business capability rather than by team. New employee onboarding crosses HR, IT, and Security, so the onboarding agent network spans those domains regardless of which VP owns which team this quarter.

Guided Determinism: The Honest Acknowledgement

One of the more intellectually honest parts of the TDX 2026 announcement was the introduction of “guided determinism.” It is Salesforce admitting publicly what most experienced architects already suspected: fully autonomous multi-agent orchestration is not enterprise-ready. The architecture works as a hybrid. You define fixed handoff rules, escalation paths, and decision boundaries. The LLM handles reasoning within those guardrails, not around them.

This matters because it changes who needs to be in the room when you design your agent network. The architecture is sound. The institutional readiness is the harder part. Most organizations rushing to adopt Agent Fabric have not actually written down their escalation rules, defined what a good agent handoff looks like in their context, or identified who owns those decisions when they need to change.

Agent Fabric solves real problems, but it is not magic. Here are the issues you should expect to encounter and plan for, in roughly the order they tend to surface.

The Cost Conversation You Need to Have Early

Token costs in multi-agent systems compound in ways that single-agent systems do not. Every broker invocation consumes tokens for routing decisions, even before the underlying work happens. Multi-step workflows can easily traverse five or six agents, each making its own LLM calls. A flow that costs $0.02 in a single-agent system can cost $0.20 in a multi-agent one. Multiply by production traffic.

Per-agent token tracking is in the Agent Visualizer roadmap and is rolling out incrementally. Until it is fully there, set hard token rate limits at the Flex Gateway layer. The “AI Basic Token Rate Limiting” policy is one of the most important guardrails available, and most teams forget to enable it.

Observability is Still Maturing

Agent Visualizer is good. It is also clearly an early-version product. Basic logs, traces, and the a2a_total_calls and mcp_total_calls metrics are available today. Detailed request tracing through the full prompt and reasoning chain, agent health monitoring, agent session playback, and DAG visualization are all on the roadmap. If your security team requires immutable cognitive traces for audit before you go live, plan around the gap.

The mistake teams make with Agent Fabric is treating it as a big-bang initiative. “We will roll out Agent Fabric across the entire org in Q3.” That framing fails because it requires aligning too many stakeholders before you have anything concrete to show. The teams getting this right are starting smaller and earning permission to expand.

Here is the sequence that works in practice.

For architects evaluating Agent Fabric in your org right now, the question is not “should we adopt this?” The question is: “Do we know what agents are already running, and do we have a control plane for them, or are we trusting that nothing has gone wrong yet because we cannot see when it does?”

If the answer is the second one, you know where to start.