Contact Us 1-800-596-4880
  1. Homepage
  2. Anypoint Code Builder

  3. Building Agent Networks for Agent Fabric

Building Agent Networks for Agent Fabric

Agent Fabric manages and coordinates the execution of agents across your enterprise, regardless of where they’re deployed. Agent Fabric solves the problem of integrating and automating complex processes that involve multiple agents and tools.

Complex tasks often require a series of steps, with each step handled by a different agent or tool. Managing this process manually is difficult and error-prone. Agent networks (networks of agents in a domain) act as central hubs for defining, validating, and executing these multi-step processes.

Define your agent network in a simple, human-readable YAML file in Anypoint Code Builder. This approach abstracts away the underlying technical complexities so you focus on the business constraints and context of your process without needing to understand the inner workings of the orchestration engine.

Don’t worry, we give you a head start by providing you with a YAML template in your agent network project. MuleSoft Dev Agent can help you configure it for your business environment, publish agent network assets to Anypoint Exchange, and deploy your agent network instance.

For more information about Agent Fabric, see Agent Fabric Overview.

Agent Network Components

Agent networks support brokers, A2A-compliant agents, and Model Context Protocol (MCP) servers.

Agent network

A collection of agents, brokers, LLMs, and MCP servers that are connected to each other.

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.

Anypoint Code Builder canvas showing brokers, agents, and MCP servers
1 The 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.
2 The Agents component groups agents defined locally in your agent network YAML.

These agents will be published to Exchange.
3 The MCP Servers component groups MCP servers defined locally in your agent network YAML.

These servers will be published to Exchange.
4 An asset that has been defined within this agent network project.

The asset might also be published to Exchange.
5 An asset that has been added to this agent network project from Exchange.

Large Language Models

Agent network brokers support these LLMs.

  • Azure OpenAI

  • OpenAI API

  • Gemini API

The following table details the requirements and recommended models.

Model Provider Required Endpoint Required Capabilities Suggested 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 network supports text-based prompts 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.

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.

Relationship Role Logic

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.

Agent network doesn’t support streaming with Server-Sent Events (SSE).

See Also