--- schema_version: "1" id: fb44c9794fdb111a36740b50815b29dce5ab0bff02fecd35689b1020a29491f7 title: Building Agent Networks for Agent Fabric collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/agent-network/1.0/af-agent-networks.md canonical_url: https://docs.mulesoft.com/agent-network/1.0/af-agent-networks source_site: docs.mulesoft.com content_type: documentation content_hash: 739ffc8061e353dff76fbd7c72a19478ee99fa33db24f04c0df59653bb4e568d description: MuleSoft Documentation Site release: "1.0" latest: false --- --- product: Building Agent Networks version: 1.0 --- # Building Agent Networks for Agent Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt An agent network is a coordinated group of agents, brokers, LLMs, and MCP servers that acts as a central hub for defining, validating, and executing agentic processes across your enterprise. An agent network provides the building blocks of your agentic deployment while MuleSoft Agent Fabric helps you maximize the potential of every AI agent with centralized discovery, orchestration across agents and tools, cross-ecosystem governance, and full transparency into agentic interactions. You define your agent network in a simple, human-readable YAML file in Anypoint Code Builder. This approach abstracts away the underlying technical complexities, allowing you to focus on the business constraints and context of your process without needing to understand the inner workings of the orchestration engine. At the start of a new agent network project, we provide a YAML template to give you a head start. You can use MuleSoft Vibes to configure your network, publish the assets to Anypoint Exchange, and deploy your agent network instance. ## Key Benefits of Agent Networks Create robust, automated agent networks with these key benefits. - Simplified Development Define your agent processes in an intentional way using a simple YAML file, which is easier and faster than writing complex code. - Safety and Governance Ensure control and compliance across every agent and tool interaction with enterprise-grade governance. - Observability Gain insight into agent actions with a visual trace of their decision-making. - Flexibility Coordinate any type of agent and tool, regardless of where it’s built and deployed so you can build a diverse network of agents. - Tool and Agent Invocation Manage the invocation of both deterministic (tool-based) and probabilistic (LLM-based) actions. ## Example Use Case: Employee Onboarding In this example, the goal is to seamlessly activate a new hire across HR, IT, Security, and Facilities with a single, policy‑governed experience. Here’s how it works: - Discover Publish existing agents and tools (HRIS, Identity, ITSM, Payroll, Facilities, LMS) in Anypoint Exchange for reuse. - Orchestrate An agent broker decomposes the task of onboarding the new hire (create HR record, provision identity, assign hardware, grant app access, enroll in benefits and training), calling MCP and A2A agents as needed, with human‑in‑the‑loop approvals where required. - Govern Omni Gateway enforces authentication, least‑privilege access, and guardrails. API Manager policies ensure consistent controls across all calls and data exchanges. - Observe Monitoring and traces (beta) give end‑to‑end visibility into progress, failures, and latency. Visualization shows which agents interacted and where bottlenecks occurred. - Reuse The onboarding definition (YAML) is versioned and shareable, enabling rapid adaptation for roles, regions, or subsidiaries without rebuilding flows. - Trust and Compliance Centralized credentials, audit trails, and policy inheritance support security, privacy, and regulatory requirements (PII handling, approvals, and separation of duties). With this experience, you get faster time‑to‑productivity, fewer handoffs, lower error rates, and a consistent new‑hire experience across the enterprise. ## Agent Network Components An agent network is a collection of agents, brokers, LLMs, and MCP servers that are connected to each other. Agent networks use LLMs for reasoning and planning capabilities and integrate with Anypoint Connector for MCP (Model Context Protocol) and Anypoint Connector for Agent2Agent (A2A) communication. Broker An intelligent routing service that coordinates task delegation across specialized A2A-compliant agents in your enterprise. A broker is defined by the agents and MCP servers it can leverage to accomplish tasks. Brokers originate from MuleSoft and are referenced in the agent network YAML. After you publish your agent network, brokers appear as specialized agents in Anypoint Exchange and can be reused by other brokers. Agent An autonomous software component that uses goals, context, and available tools, often via a large language model (LLM), to decide and execute actions on behalf of a user or system. Agents can be defined either locally in the agent network or externally in a different agent network or elsewhere in your company. Your agent network can use both locally defined and externally defined agents to complete tasks. Agent assets must be A2A-compliant. MCP server A service that implements the Model Context Protocol (MCP) to expose tools and data to AI clients, enabling LLMs to invoke external capabilities through a standard interface. MCP servers can be defined either locally in the agent network or externally in a different agent network or elsewhere in your company. Your agent network can use both locally defined and externally defined MCP servers to complete tasks. ### Agent Networks in Anypoint Code Builder When you create agent networks, the Anypoint Code Builder canvas shows the brokers, agents, and MCP servers you’ve configured. ![Anypoint Code Builder canvas showing brokers, agents, and MCP servers](/mulesoft/current/en-us/agent-network/1.0/_images/af-agent-network-canvas.png)
1The Brokers component groups brokers defined locally in your agent network YAML. It can include assets defined locally within the project and assets previously published to Anypoint Exchange, either by your organization or third parties.

Brokers can reference other brokers defined within the project.

Agent network projects don’t require brokers. They can contain only agents and MCP servers defined within the agent network project.

2The Agents component groups agents defined locally in your agent network YAML.

These agents will be published to Exchange.

3The MCP Servers component groups MCP servers defined locally in your agent network YAML.

These servers will be published to Exchange.

4An asset that has been defined within this agent network project.

The asset might also be published to Exchange.

5An asset that has been added to this agent network project from Exchange.
## Agent Network Architecture This diagram shows an agent network with agents and MCP servers, traffic through Omni Gateway, governed by API Manager, and observed in Anypoint Monitoring and Agent Visualizer. ![Agent Fabric showing agents and MCP servers defined in YAML and published to Exchange](/mulesoft/current/en-us/agent-network/1.0/_images/agent-fabric-architecture.png)
1Publish the agentic assets to Anypoint Exchange for discovery and reuse after you define the agent network (brokers, agents, MCP servers) in the agent network YAML in Anypoint Code Builder.
2Deploy the agentic assets to CloudHub 2.0 (managed in Runtime Manager).
3Enforce policies on incoming traffic to the network with an ingress Omni Gateway, which sits in front of brokers and API endpoints.
4Enforce policies, manage connections, and emit telemetry data with an egress Omni Gateway, which sits on outbound paths from brokers and agents to external agents and services.
In a shared space, or in a private space using a single-gateway configuration, callouts policies, traffic, and data are handled by one Omni Gateway.
5Collect logs, metrics, and traces from Omni Gateway and runtimes in Anypoint Monitoring.
## Large Language Models Agent network brokers support the latest Gemini and OpenAI models and LLM Proxies. - Azure OpenAI and OpenAI API: - GPT-5.2 - GPT-5.2 Pro - GPT-5-mini - GPT-5 nano - GPT-5 For more information about these models, see the [OpenAI](https://developers.openai.com/api/docs/models) documentation. - Gemini API: - Gemini 2.5 Pro - Gemini 2.5 Flash-Lite - Gemini 2.5 Flash - Gemini 3 Flash - Gemini 3 Pro For more information about these models, see the [Gemini](https://ai.google.dev/gemini-api/docs/models) documentation. - LLM Proxy: LLM Proxy provides a unified endpoint for multiple LLM providers including Gemini, OpenAI, Bedrock (Anthropic Claude models), and NVIDIA Nemotron. To find the supported models, see [LLM Proxy Supported LLM Providers](https://docs.mulesoft.com/general/model-proxy#supported-llm-providers). This table details the requirements and recommended models.
Model ProviderRequired EndpointRequired CapabilitiesSuggested Models

OpenAI

/responses

  • Reasoning

  • Native structured output

  • Function and custom tool calling

  • For lower latency: GPT-5-mini

  • For complex reasoning: Evaluate models

Gemini

/generateContent (Native API)

  • Native Thinking (via thinkingBudget and thinkingLevel)

  • Native structured output (responseSchema)

  • Function and custom tool calling

  • For lower latency: Gemini 2.5 Flash, Gemini 2.5 Flash-Lite

  • For complex reasoning: Gemini 3 Pro (Deep Think capabilities)

Agent networks support text-based messages and responses. Image and binary message types aren’t supported. ## A2A Protocol The Agent2Agent (A2A) Protocol governs agent-to-agent communication. This protocol powers orchestration, observability, and governance features in agent networks. MuleSoft supports v0.3.0 of the A2A Protocol Specification. ### Context and Task ID Scoping in Agent Networks In MuleSoft agent networks, the brokers receiving a request always generate a `contextId` and `taskId`. These IDs define the state and scope of a specific conversation between two agents. A `taskId` is always matched to a `contextId`, but a `contextId` can exist without a `taskId`. In a multi-agent network, a client sends a request to Broker\_1 and Broker\_1 generates the necessary IDs for that request. When Broker\_1 sends a new request to the next broker or non-broker agent in line, that broker or non-broker agent establishes a unique `contextId` and `taskId` for the new request. > [!NOTE] It is not mandatory for non-broker agents to generate a `contextId` and `taskId` when > receiving requests from a client. Consider a network with a client and two brokers (1 and 2). - The IDs used between the client and Broker\_1 are independent of the IDs used between Broker\_1 and Broker\_2. - When Broker\_1 delegates a task to Broker\_2, Broker\_2 (acting as a server) generates its own `contextId` and `taskId`. - Broker\_1 is responsible for maintaining a mapping between its own upstream `taskId` (used to respond to its client) and the downstream `taskId` it’s tracking with Broker\_2. - If Broker\_2 requires more information (if it returns `status: input-required`), it provides a `contextId` and `taskId` to Broker\_1. Broker\_1 uses these IDs to provide the requested input to Broker\_2. The client never sees Broker\_2’s internal IDs.
RelationshipRoleLogic

Client → Broker_1

Broker_1 is server

Generates contextId_1 and taskId_1 for the client.

Agent A → Broker_2

Broker_2 is server

Generates contextId_2 and taskId_2 for Broker_1.

Network broker

Broker_1

Broker_1 maps contextId_1 and taskId_1 to contextId_2 and taskId_2.

For more information, see [Life of a Task - Group Related Interactions](https://a2a-protocol.org/v0.3.0/topics/life-of-a-task/#group-related-interactions). > [!NOTE] Agent networks don’t support streaming with Server-Sent Events (SSE). ## See Also - [Get Started with Agent Networks](https://docs.mulesoft.com/agent-network/1.0/af-get-started)