Agent Brokers

An agent broker orchestrates a group of agents and MCP servers to do a job. Import one and Agent Explorer shows you the workflow it actually executes, step by step.

Importing a broker

1. Connect to Anypoint and pick the organization the broker lives in.
2. Open Anypoint in the navigation and scroll to Agent brokers.
3. Press Import next to the broker you want, then choose which deployed instance to import.

A broker can be deployed more than once — a Sandbox and a Production instance, say — and each deployment has its own address. The dialog lists them with their environment and URL, so you pick the one you actually want to talk to. Instances you have already imported are marked, and deprecated ones are flagged.

Each instance becomes its own workspace, named after the environment — Submission Triage Broker (Sandbox). Importing a second instance never disturbs the first, so you can hold Sandbox and Production side by side and compare them.

Agents and MCP servers shared between brokers — or between two instances of one broker — are imported once and appear in every workspace that uses them. There is one Assessor Agent, not one per broker.

Nothing in your Anypoint organization is changed — this reads only.

If you change the selected organization, press Reload to list that organization's brokers.

Updating an imported broker

Once a broker has been imported, its button reads Update. Press it when the broker has changed in Anypoint — a reworked flow, a new agent, a new version — and Agent Explorer refreshes the workflow graph, the agent card and the connections while keeping the workspace, its chat history and its address.

The same dialog opens, so Update is also how you add a second instance: pick an environment you have not imported yet and the button changes to Import.

The workflow graph

The graph is the broker's Agent Script — the definition it runs, drawn left to right. Each box is a step, named as the script names it:

Arrows show what happens next. Where a step calls out to an agent or MCP server, the box says so.

A step is labelled with whatever the Agent Script calls it — Classify Intent rather than classifyIntent — falling back to its identifier where the script names none.

Everything is dotted until it runs. A freshly imported broker shows every step and arrow as a dotted outline, because nothing has executed yet. When you run the broker, the path it actually took turns solid, and the steps it never reached stay dotted and dimmed — so you can see at a glance which branch was taken.

The router's fallback — the path taken when nothing else matched — is the row labelled otherwise.

A box with a dashed red border means the script points at a step it never defines. That is shown rather than hidden, because a missing step is usually a bug in the broker.

Where an imported network appears

Everything the import creates lands in the Explorer, in the workspace the import created. Imported items carry an Anypoint badge, and the broker itself carries a second Broker badge. Instead of an internal address, each row names the Exchange asset it came from — for example assessor-agent · v1.0.3 · Anypoint Exchange.

To see only imported assets, choose Anypoint in the type filter at the top of the Explorer.

The badge means the item came from Anypoint, not merely that it sits in an imported workspace. Add one of your own agents to that workspace and it stays yours — unbadged, fully editable, and chattable as always.

Talking to a broker

A broker has no Chat tab. It has a Debug tab, and that is where you talk to it: the workflow on the left, the conversation beside it. A broker is a workflow you are trying to understand, so sending a message and watching what it does belong on one screen.

Drag the divider to give either side more room, or hide the conversation entirely when the graph is what you are studying. Details shows which Exchange asset the broker came from, its agent network, and the Agent Script it was read from.

New conversation sits on the bar above the transcript. The menu beside it holds History for earlier conversations, and Debug for the raw request and response behind each message.

Watching a run

If the broker stops to ask you something, the step it stopped at is ringed in amber and marked awaiting reply, and the header says Waiting for your reply rather than Run complete. Such a run does finish executing, so without that it looks exactly like one that simply ended.

Send a message and the graph fills in the path the broker actually took. Every step and line starts dotted; each one turns solid only once the broker's own logs confirm it ran. Nothing is ever animated ahead of the evidence — a route the logs have not confirmed stays dotted.

While there is nothing to show yet, a panel covers the workflow and explains why. It lifts on its own the moment the first step is confirmed — which is the part worth watching — and you can hide it sooner with Hide and show the workflow. It covers only the workflow, not the conversation, so the reply is still readable underneath.

The graph trails the run by about twenty seconds, and usually finishes after the reply arrives. That is Anypoint's log ingestion delay, not a stall: logs become readable some seconds after the step that wrote them. The status line above the graph says which of these is happening:

• Waiting for the broker's logs… — the message is away, nothing has been ingested yet.
• Replaying the run… — steps are arriving and the graph is filling in.
• Run complete — solid steps and lines are the path it took.
• The broker's logs did not arrive — nothing came through in time. Retry looks again for the same run; it does not re-send your message.

Each step that ran carries its own summary: how long it took, what it called, and a warning or error count if anything went wrong. Most questions are answered without clicking anything.

Click a step to see its members. The agents, MCP servers and LLMs it can reach appear beside it, stacked in the direction the workflow reads, connected by dotted lines — dotted because the workflow's own arrows mean then, while these mean calls. The rest of the canvas darkens so the step and what it reached are clearly the subject. After a run each member shows how many times that step invoked it and how long those calls took in total.

A member this run never reached is struck through and greyed out, so "not used" is stated rather than left to a missing number. It is not marked in red — red means a call that failed, which is a different thing.

The LLM is marked out in amber, because it is usually where a run's time goes. No action in the script names it — a step that reasons reaches it implicitly — so every generator, orchestrator and subagent is shown with the network's LLM whether or not the script mentions it. Steps that only execute or echo are not.

Click a member to see every call to it. Each invocation gets its own row: when it happened, which step made it, how long it took, and whether it failed. A member the step called fifteen times is fifteen rows, so one slow call among fast ones is visible — a total alone would hide it. Bars are sized against that member's own slowest call. The step stays revealed while you look, so a call is always read against the step that made it.

Click the canvas to deselect. Nothing in the workflow moves while a step is open — the members are drawn over it, not laid out in it.

The workflow, the timeline and the detail below it are all resizable — drag the bars between them to give whichever you are reading the room it needs. Either of the lower two can also be opened full-window with its expand button, which is the easier way to read a long log or a run with many steps.

Past runs

Refreshing the page does not lose your work. The Runs column on the far left lists every request already sent to this broker — what was asked, when, and how long it took — and picking one replays it: the same path, logs and member calls you saw live. The run currently on the canvas is marked, so a list of similar prompts still says which one you are looking at.

The three columns read left to right in the order the work happens: pick a run, read the conversation, study what the broker did. Either of the two narrow ones can be folded away with the History and Chat buttons above the workflow when the diagram is all you want.

Nothing extra is stored to make that work. A run is rebuilt from Anypoint out of the request's own identifiers, which means Anypoint's retention is the limit: traces are kept 7 days and logs 30. A run older than a week replays its path but not its member calls, and one older than a month cannot be replayed at all. Each entry says which of those applies rather than replaying to an unexplained blank.

When the gateway refuses

The broker rejected these credentials says nothing about what would satisfy it. When a send is refused, the message now also names what the gateway in front of that broker enforces — its applied policies, by name.

Deliberately what is applied now, rather than an attempt to name the single policy that refused one request: the policy ids Anypoint records against a rejection are historical, so a policy since removed resolves to nothing, and a confident wrong name is worse than a list of what is switched on.

Which broker needs attention

The broker list on the Anypoint page carries each broker's last seven days beneath its name: how many calls it took, its p95 latency, and how many of those calls failed. p95 rather than an average, because an average hides the tail that people actually feel, and failures named separately because a broker answering quickly while refusing a third of its traffic reads as healthy until they are counted.

It comes from Anypoint's metrics store in one query for the whole list, so it costs a single call however many brokers you have. A broker with no traffic in the window simply says nothing.

Finding your way around

The Debug tab is a workbench: Runs on the left, the workflow on the canvas, a drawer of views beneath it, and the conversation on the right. Either side column folds away with the panel buttons at the right of the run header.

The drawer's tab row is the whole inventory — Timeline, Compare, Logs, Connections, Gateway, Script, Errors. Those six are always there, in that order. A view with nothing to show is dimmed and says why when you hover it, rather than disappearing; being told nothing failed in this run is an answer, and a missing tab is not.

Selecting a step narrows the drawer rather than opening anything else. Click a step on the canvas or in the timeline and Logs, Connections and Errors all scope to it, with an only <step> chip in the tab row saying so, and each tab's count narrows with it — so the number beside Connections is what this step called, not what the run did. Timeline and Gateway keep run-wide counts, because neither of them narrows.

A view leaves the tab row while a step is selected when it cannot narrow to that step. Gateway always qualifies — its subject is the broker's traffic over days, including requests that produced no run. Compare qualifies only until you have picked something to compare against: until then it is a list of runs to choose from, which says nothing about the step on screen. Once a baseline is chosen it narrows like everything else and stays. Timeline never leaves, because it is how another step gets selected.

Clearing the step brings them straight back. Click the chip to widen again — or click anywhere on the canvas that is not a step, including inside the workflow frame, or press Escape.

Clicking a connection brings the Connections view with it, so the click always has a visible result. Selecting a step deliberately does not switch views — a step narrows whichever view you are already reading.

The run header above the canvas carries everything that acts on the run — keep it, compare it, open it in Monitoring — and Broker holds what the broker is: versions, script path, deployed spec, organization. The broker and its agent network are links — they open the asset in Exchange — and the Agent Script path opens the whole file in the Script view, clearing any selected step so that it shows the file rather than one step's few lines.

Each step on the canvas carries a </> icon that opens its own declaration. Each connection revealed beneath a step carries a link to its asset in Exchange — a different one for each, which is why the link lives there rather than on the steps.

A connection card leads with its name, since that is what identifies it, and the number in its corner is how many times that step called it during the run — hover it for the count and the total time. Fifteen fast calls and one slow one reach the same total, and only the count tells them apart. Controls that cannot act right now stay put and dim, with the reason on hover.

The timeline

Below the workflow, every step appears as a bar on a shared time axis, in execution order, with its duration on the right. This answers the one question the workflow diagram cannot: which step took the time. A step that dominated a run is immediately obvious — in a typical triage run, Triage Pipeline is 24 of 30 seconds — where the diagram gives it exactly the same box as a router that finished in a millisecond.

The timeline is also the easiest way to pick a step. Rows are one column, fixed size, in the order things happened, so choosing one is a short move rather than a hunt across the canvas. It stays put while a step is open, so moving between steps is a single click.

When a run failed

Runs that went wrong are marked in the Runs column with the status the broker answered — 401, 503 — or simply failed when it answered 200 and then broke mid-graph. Both signals matter: neither alone tells you a run went wrong.

The gateway

Gateway shows how Anypoint's gateway answered for this broker, over 1, 7 or 30 days. It is the one view here that is not about a single run, and it exists because everything else in this tab can only show requests that reached the broker.

A request refused by a policy never does. It produces no log, no turn and no task id, so it has no run to replay and appears nowhere else — it looks from here exactly like a request nobody ever sent. On a real broker that was 50 requests in a month. Those rows are marked blocked.

It also shows the broker's whole traffic rather than only what you sent from here, so calls from other agents and other tools are included.

Keeping a run

Everything in this tab is rebuilt from Anypoint on demand, which is why nothing is stored — and why it all expires: traces last 7 days, logs 30. A run worth returning to is exactly the run that will outlive them.

Keep, in the run's header above the workflow, stores one. The button reads Kept once it has, and clicking it again stops keeping the run.

What is stored is the rebuilt run itself, not a request to rebuild it later — so a kept run stays readable and comparable indefinitely. Kept runs carry a pin in the Runs column and never show a retention warning, however old they get.

This is what a long-lived baseline needs. Comparing rebuilds the earlier run like any other, so the run you measure against expires on the same schedule as the rest — keep the one you intend to come back to.

Reading the logs

The Logs view groups a run's lines under the step that wrote them, with the step name on a sticky header rather than repeated down every row, and shows how many lines and how long that step's logging spanned.

An agent's own logging is repetitive by nature, so the view is built to make the differences visible rather than the sameness:

• Levels are a coloured edge, not a column. Nearly every line is INFO, and a column reading INFO two dozen times is noise. WARN and ERROR keep their word and earn a colour.
• Idle gaps are drawn. Where a run sat still for eighteen seconds, the list says so — in a plain column of timestamps that looks identical to no pause at all.
• Searching marks the match in place, so a hit does not need reading twice to find.

The other views follow the same rules — say the structure the data already has, drop anything that repeats, and draw what would otherwise be invisible:

• Timeline carries a scale, so a bar reads as a duration rather than only as longer than the one above it, and the run's longest step is marked.
• Connections lists what the broker called itself. Open one and it shows every individual call, and then what that connection went on to call — the LLM an agent used to answer is the agent's work, not the broker's, and listing it at the top level made the broker look responsible for it. All of this was already in the trace; it was only being flattened away.
• Connections are grouped by what they are, which retires the column that said MCP Server on every row, and each group says what share of the run's connection time it took. A member whose slowest call beat its own 30-day p95 is flagged slower than usual — 200ms is alarming for one member and unremarkable for another, so the run's own scale cannot answer it.
• Gateway splits what reached the broker from what never did. Those are not two values of a column; one produced a run and the other exists nowhere else in this screen.
• Script is highlighted as YAML and narrows to the selected step's own declaration, like every other view. Agent Script is not valid YAML — it is read on import with a line scanner for that reason — but highlighting only lexes, so the shape the two share is coloured and the parts YAML does not know about stay plain rather than being coloured wrongly. The line numbers are the file's real ones, so a slice still says where in the script it sits, and clearing the step shows the whole thing again.

Comparing two runs

A single run tells you a step took four seconds. It cannot tell you whether four seconds is normal. Open the Compare view in the drawer — it lists the earlier runs, and picking one reads the run on screen against it.

Both runs are named at the top and every figure below sits in a fixed column under the run it belongs to, so no number has to be traced back to which run produced it. Total time, step count, member calls and the deployed version come first, then every step, then every member — ordered by how much each one moved, because the question is what changed rather than what exists.

With a step selected, Compare narrows to it like every other view: how long that one step took in each run, how many connection calls it made, and how those connections compare — rather than totals for steps you are not looking at. If one run never took the step, it says so.

Deltas are amber for slower, emerald for faster. Red is not used; a run that took longer has not failed. The timeline carries the same deltas beside its bars, for reading them against the run's own wall clock.

Steps the earlier run took and this one did not are listed underneath as not taken this run, with how long they took last time. That is the path difference — a router that sent this request down a different branch shows up as steps on one side and not the other.

The header carries the difference over the whole turn, so the first thing you read is whether the run was slower at all. Nothing is stored to make this work: the earlier run is rebuilt from Anypoint on demand, exactly as replaying it is, so the same retention limits apply — a run too old to rebuild says so instead of quietly comparing against nothing.

Is this normal?

A duration on its own cannot be judged: 4.1s from a member is unremarkable against a p95 of 5.3s and alarming against 200ms. Open a member and the panel says what it usually costs — average, p95, and how many calls that is drawn from.

This comes from Anypoint's metrics store rather than from replaying past runs, which means one lookup covers every member, and it reaches back further than the runs do: the store keeps 30+ days where traces keep 7.

Inspecting a step

Click any step — on the workflow or the timeline — to see what it did:

The step opens as a single chronology — its CloudHub log lines and its tracing data, merged into one stream in the order things happened, timed from the moment the step began rather than by wall clock.

The two are drawn differently on purpose. A log line is something the broker said: quiet, monospaced, on the rail. A call is something it did: a card naming the member, its kind and what it cost. A failed call is marked as failed.

• Calls appear where they happened. Each shows what was called and how long it took, with a bar sized against that step's slowest call. Read apart from the log, a step can look idle for twenty seconds; read together, that gap is the LLM call that filled it.
• Long pauses are shown as pauses. Anything over about a second appears as its own marked gap, so time that went nowhere is visible instead of implied by two distant timestamps.
• Warnings and errors are marked, not just coloured.
• Routine runtime chatter is folded — protocol handshakes and internal timing notices, which restate what the call rows already say. The count is always shown and one click reveals them; nothing is discarded.

The members a step used are also summarised in the panel header, so they are visible without scrolling. Repeated calls to one member are totalled — watchlistServer ×15.

Click the canvas, or the panel's close button, to go back.

A run's first few lines — protocol negotiation and tool discovery — happen before any step begins. They are reachable too, via the link below the timeline, rather than being hidden.

A conversation with a broker can run to several turns; the graph always shows the most recent turn, not everything the conversation has ever done.

If a broker has never run, there are no logs to read and the graph simply stays dotted.

Credentials

Whether a broker needs credentials is up to whoever deployed it. Send a message and Agent Explorer will tell you:

• The broker answers, and nothing more is needed.
• The broker refuses, and the credential form opens. Where the broker names the scheme it wants, the form opens on it and says so; where it names something we do not recognise, you are shown the raw challenge and can choose.

Three schemes are supported: Client ID & Secret, a Bearer token, and custom headers for anything else. You can also set credentials before sending anything, from the same menu.

Once saved, credentials are sent with every request to that broker until you change or clear them. They are encrypted at rest and never displayed again — the credential line shows only which identity is acting, and the client ID, which travels in plain text on every request anyway and is the first thing worth checking when a broker rejects you.

If a broker refuses credentials you have already stored, it says so plainly rather than reopening an empty form.

Imported agents are read only

An imported broker and its agents get their name and address from Exchange, so both are shown but cannot be edited here — Update rewrites them from Anypoint. Everything that is yours, such as custom headers, stays editable.

The agents in a network have addresses of their own, but whether you can reach them depends on how the gateway was configured; in a network they are called by the broker rather than directly. What they cannot do is be edited from here.

Broker v1 is not supported

MuleSoft's earlier brokers ran on a different runtime and described themselves differently. Agent Explorer supports broker v2 only. Attempting to import a v1 broker tells you so instead of importing something incomplete.

Troubleshooting

"This is a v1 broker." See above — only v2 brokers can be imported.

"Could not find this broker's agent network in Exchange." The broker refers to a network asset that is missing or that you cannot access. Its connections may still import, but its workflow cannot be shown.

"This broker has no readable workflow." The import succeeded but the archive contained no Agent Script. You will see the broker's connections without the step-by-step graph.

Nothing is listed. Check that an organization is selected above, then press Reload. Brokers belong to a specific organization, and a business group may legitimately contain none.

"This broker requires credentials." Its gateway refused the request because nothing was sent. The form opens with it; see Credentials above.

"The broker rejected these credentials." Something was sent and refused. The credential line still shows which identity was used, so you can check the client ID before replacing it.

"Endpoint not resolved yet." The broker was imported without an instance, or the instance publishes no address, so there is nowhere to send. Press Update and choose an instance.

"Invoked via the broker." Shown on an agent inside a network. It is reached through the broker rather than addressed directly here, so talk to the broker instead.

"That instance no longer exists in Exchange." The broker's instances changed between opening the dialog and confirming. Reload and try again.

The graph stays dotted after a message. Give it up to a minute — logs are ingested on a delay. If it still says The broker's logs did not arrive, press Retry. A broker whose deployment has never produced logs has nothing to show, and No run data for this broker yet says so.

If a run refuses to open while the Runs list still shows it, that list is read from Agent Explorer's own database and the run itself is rebuilt from Anypoint — so the likely cause is the Anypoint connection rather than the broker. The status line says Your Anypoint connection needs re-authorising and offers Reconnect when that is what happened, and a dialog explains it the first time a run refuses to open — dismissing that leaves the message and the Reconnect button in the header.