A customer care agent on MuleSoft Agent Fabric, where the model only talks

I built a customer care agent on MuleSoft Agent Fabric for a made-up furniture shop. The model reads each message and writes each reply, and that's all it does. Whose order it is, which delivery slots are free and whether a care case gets opened are decided by an Agent Script graph, a Mule MCP server and a System API.

It's called Where's my sofa?, and the project page has the demo video. My day job is MuleSoft integration, and there's no agent in it yet. MuleSoft now ships Agent Fabric, Agent Script and an MCP connector, so I wanted one real use case built end to end, the API-led way. The shop, its products and its customers are invented.

One question, three systems

"Where is my sofa?" sounds simple. For a piece made to order, the answer joins the order, the workshop's production stage and the delivery booking. Moving a delivery has rules too: only your own order, only a free slot, and never inside 48 hours.

Each layer does one job:

• Omni Gateway sits in front of the broker: client ID enforcement, 60 requests an hour per client to cap the LLM bill, and user context, which gives each caller their own conversation memory.
• The Care Desk broker is an Agent Script graph that Agent Fabric deploys. It speaks A2A, and gpt-5-mini through OpenRouter does the language, with low reasoning effort.
• sofa-care-mcp is a Mule app on the MCP Connector with five tools. It checks an API key when an MCP session opens.
• sofa-orders-sapi is a Mule System API over a mock ERP, with the rules in DataWeave.

The model classifies, the graph decides

Agent Script mixes LLM nodes and plain nodes in one graph. I gave the model as little as I could:

1. understandRequest makes one LLM call with no tools. It fills in the intent, order number, email and preferred slot.
2. intentRouter has no LLM. It picks the path and checks that the email and order number are there. When one is missing, a fixed reply asks for both.
3. orderStatus is the only LLM node with tools: find_orders and get_order. The graph binds the email into them, so the model can't aim a tool at another order.
4. Moving a delivery has no tool-calling model at all. An executor reads the free slots, pickSlot makes one LLM call to pick the slot that matches the request, a router decides, and another executor makes the move. The model picks a slot but never calls the tool that moves it.
5. Two executors open care cases with fixed arguments, for a complaint or a delivery too close to move. No model decides whether a case gets opened.

Then the System API holds the line. A wrong email gets the same 404 as a missing order, so asking about SO-24903 with someone else's email doesn't even confirm that the order exists.

The agent replied with its own reasoning

My first eval run passed 5 of 7. Two of the failures weren't wrong answers. They were the model thinking out loud, sent to the customer as the reply:

User asked to move their delivery but did not provide an order number or email address. Reschedule requests require both order number and email to proceed, so additional information is needed from the customer.

Turns out Agent Fabric runs generator and orchestrator nodes with human-in-the-loop. When the model decides it needs more input, the task ends in TASK_STATE_INPUT_REQUIRED to wait for the customer, and the model's reasoning becomes the reply. "I want to move my delivery" did it every time.

Telling the model never to ask the customer made it worse. Over the next five runs it passed between 2 and 5 of 7. What worked was taking the decision away from it:

• The router checks what's missing, not the model.
• The message reaches the model quoted, as data, under its instructions. Given the bare message, the model took the customer's request as its own goal.
• Each node is told its goal is complete once its outputs are set, whatever the message asks for.
• No model writes a question to the customer. The model fills in fields, a router decides, and every question comes from a fixed reply.

That last one took me two tries. After 8 of 8, the next run passed 7 of 8: when two free mornings matched, the node choosing the slot stopped to wait for the customer again. I moved the list into a separate generator, sure that a node which only formats data would never stop. It stopped too, because what it wrote was a question. Now pickSlot only fills in the slot, or the slots to offer, and "Which one suits you?" is a fixed reply from the graph.

MCP tool discovery timed out

The other thing that took a while was below the agent. MCP Connector 1.6 held an SSE stream open for every response. Behind Omni Gateway, the broker's tool discovery timed out on it.

That matters more than it sounds: the broker discovers its tools when it starts, and a tool missed then stays missing until the broker restarts. Connector 1.7 answers with one JSON body, and discovery went through. The catch: it needs Mule 4.12. Version 1.7.2 fails to start on 4.9.6.

The eval reads the system, not the reply

A reply can sound right and do the wrong thing. So scripts/eval.py doesn't grade the wording. It sends eight customer messages, and before and after each one it reads every delivery slot and care case from the System API. Then it checks what changed:

• A move passes only if that one order moved to that one slot and nothing else changed.
• A delivery under 48 hours away passes only if nothing moved and one care case was opened.
• A damage report passes only if one damage case was opened and the reply gives its number.
• A prompt injection on someone else's order passes only if nothing changed at all.

The reply itself is checked only for what has to be in it, like the 14-day delay or the free mornings. On 18 October 2026 the deployed broker passed all eight, with replies in 3.5 to 15 seconds.

Try it

The repo has both Mule apps, the agent network, the deploy scripts and the eval. With an Anypoint org that has Agent Fabric, a connected app and an OpenRouter key:

scripts/deploy-apps.sh                                                     # both Mule apps to CloudHub 2.0
SETUP_GATEWAY=1 SOFA_CARE_MCP_URL=https://... scripts/deploy-network.sh    # gateway, publish, broker
scripts/ask.py                                                             # talk to it over A2A

demo/server.py serves the page from the video: the chat next to the System API's own data, so you can watch a message change it.

It isn't production. The customer's email comes from their message, which is fine for a demo; for real it would come from a token validated at the gateway, and the System API's email check would be real authorization. It ran in an Anypoint trial org. If you're trying Agent Fabric too, tell me what broke for you.

MuleSoft, Anypoint Platform and Agent Fabric are Salesforce trademarks. Where's my sofa? is an independent project.

Plain text: mulesoft-agent-fabric-care-desk.md · Atom feed · All notes