Concepts

The vocabulary of Agent Networks: brokers, A2A, MCP, LLMs, Exchange assets, AgentScript, and the v1/v2 split.

Agent Networks come with their own vocabulary. Most of it maps cleanly onto ideas you already use in MuleSoft integration — this page draws those lines so the rest of the docs read easily.

The one-sentence mental model

A broker is a deployed, LLM-driven agent that receives a message over A2A, runs a graph you authored in AgentScript, calls LLMs, MCP tools, and other agents along the way, and answers back. Everything else is detail on those nouns.

Agent Network

The published unit of work — a single Exchange asset (a GAV: group / asset / version) that bundles three files: a network definition (agent-network.yaml), an Exchange descriptor (exchange.json), and one broker's graph (brokers/<name>.agent). In integration terms, it's the deployable application; in Agent Network terms it's "the network".

A network contains exactly one broker today. The plural ("networks") exists because a broker can call other networks' brokers as agents — that's how a network of agents forms.

Broker

The deployed runtime. It's the thing that's actually live in Runtime Manager, listening for A2A requests. When Tracer lists "deployed brokers", each one is an API Manager instance in an environment. When Builder talks about "the broker", it means the graph you're authoring that will become that runtime.

The broker is the network's only public front door. The network itself has no A2A card — the broker's card is the contract.

AgentScript

The language a broker's graph is written in — MuleSoft's AgentFabric dialect, stored in a .agent file. It declares an LLM-driven node graph: a trigger that starts on an inbound message, reasoning and routing nodes in the middle, and echo nodes that answer.

You almost never hand-write it. In Builder you draw the graph on a canvas and AgentScript is the projection; a read-only (and optionally editable) AgentScript view is one toggle away. It's the equivalent of Studio's XML behind the visual flow.

A2A (Agent-to-Agent)

The JSON-RPC 2.0 protocol brokers speak — how a client talks to a broker, and how brokers talk to each other. Two versions are in play:

0.3 — the default. Method message/send; the A2A-Versionheader is omitted.
1.0 — method SendMessage; a different message shape and a requiredA2A-Version header.

Version mismatch is a classic confusing failure: 0.3 and 1.0 differ in method name, message shape, and header, so a broker built for one will reject the other with an opaque error. Tracer's Invoke rail lets you pick the version explicitly.

Agent card

The A2A discovery document that describes a broker and the skills it advertises — think of it as the agent's OpenAPI/RAML spec. Clients fetch it (typically from /.well-known/agent-card.json) to learn where to send messages and what the agent can do. In Builder you edit it on the A2A card tab; its security is derived from your inbound policies, not hand-typed.

MCP

Model Context Protocol — the standard way agents call external tools. An MCP server exposes named tools (e.g. get_customer_profile); a broker calls them as actions. On Tracer's graph, MCP servers are their own node type. In Builder, adding an MCP server as an Exchange asset auto-creates one action per tool it advertises.

LLMs

The models that do the reasoning. An LLM is an Exchange asset you compose in; in AgentScript it becomes a binding (@llm.<name>) that reasoning nodes use. A network has a default LLM and can bind several (e.g. a cheap model for classification, a bigger one for generation).

On Tracer's network graph, LLM nodes are design-time only — they're synthesized from Exchange metadata, because the platform's topology feed doesn't report them directly.

Exchange assets & GAV

Same Exchange you already use. Every reusable thing — an LLM, an MCP server, an agent, a policy, and the agent network itself — is an Exchange asset identified by a GAV: groupId : assetId : version. Builder's golden rule is compose, never create: you wire existing published assets; Builder doesn't publish new ones (that's Build & Publish's job).

A composed asset fans out into three things automatically: an exchange.json dependency, a connection in the YAML, and deploy variables. You don't hand-maintain those — they're derived.

Task, context & iteration

A task is one A2A request/turn — the unit Tracer traces. A contextIdgroups tasks into a conversation. Within a task, work happens in iterations:

v1 brokers — an iteration is one LLM tool-selection loop (the ReAct pattern).
v2 brokers — an iteration is a graph runtime node/phase.

A task can produce artifacts (named outputs) and carries a terminal status (Completed / Failed / Canceled / Rejected). Tracer reconstructs the whole ordered timeline — the "call stack" — from logs, traces, and Object Store data.

v1 vs v2 brokers

This is the single most important split to internalize, because the same Tracer UI shows different tabs and views depending on which generation a broker is:

v1 — a ReAct-style reasoning loop. Tracer shows a Tree and List of iterations and steps.
v2 — a node-graph (AgentScript) runtime. Tracer shows a node timeline, a Task story, and a graph overlay of the actual execution path.

Builder authors v2 networks (Agent Network 2.0). If you compare a v1 and a v2 broker side by side in Tracer you'll think features are missing — they're just format-specific.

Object Store & retention

Brokers persist their reasoning and task state in Anypoint Object Store. That's what powers Tracer's richest views — the Task story and LLM reasoning. The catch: it expires. The documented default TTL is 24 hours (30 days maximum), so if you open a task after its keys have aged out, those panels will be empty even though the task ran fine.

Chasing an intermittent "why is Task story blank?" — it's almost always retention, not a bug. See Tracer shows nothing.

Ready to use the tools? Jump to Tracer, Builder, or Build & Publish. Full MuleSoft references: Agent Network YAML and AgentScript.