What it takes to scale multi agent workflows with Agent Fabric

In October, AbsoluteLabs joined the MuleSoft Value Delivery team to host a webinar on Agent Fabric. Ankit Jain, Pradeep BS and Vivek Sharma from our technology team took the audience from the Agent Fabric concept to a live multi agent incident triage workflow, shown in a live demo environment, that cut triage time from approximately one hour to 2.5 minutes. This is what we built, what we showed, and what we learned.

Thank you to Daniele Ghetti and Varsha Upadhyaya from the MuleSoft Value Delivery team for presenting alongside us. Whether you were there on the day or missed it, here are the key points from the session.

Agents are repeating an old integration problem

The session opened with a pattern customers have seen before.

In the early 2000s, applications were connected directly to each other, point to point. As enterprises scaled, that became unmanageable: too many connections, no visibility, no governance. APIs solved this in the 2010s by introducing a shared, governed layer in the middle, which MuleSoft called API led connectivity.

AI agents are now heading down the same path. They get wired directly to each other and to the systems behind them, with no central place to see what they are doing or govern what they can reach.

Agent Fabric solves this the same way APIs did. Rather than agents connecting directly to each other and to backend systems, it puts a shared, governed layer between them. Through that layer you can find every agent in one registry, route work between agents through a broker, apply policies to every call, and see the entire agent network on a live map. Think of it as an API Manager, but for agents.

"You might not have a single registry where you see all your agents, created by different people in the organisation, and that's where Fabric helps. When you put everything in one place, it helps you visualise."

Ankit Jain, Senior Director, Engineering and Technology, AbsoluteLabs

What AbsoluteLabs built

For the demo, AbsoluteLabs chose a problem most operations teams know well: a P1 integration failure, the highest-priority category of incident, where a business-critical service is down and needs fixing immediately.

When orders stop flowing downstream, a single P1 can generate dozens of tickets with nothing linking them to a root cause. The incident sits in a queue, the service desk hands it on, and an engineer works through logs, runbooks, documentation and old tickets. In a typical scenario, triage alone takes approximately one hour before a fix even begins.

AbsoluteLabs turned each part of that engineer's job into one agent's job, with Agent Broker coordinating the flow between them:

• Analysis agent takes the incident context, searches the runbook and docs, and recommends the fix, with priority set by rules and escalation logic
• Ticket agent raises or updates the ticket with the full analysis
• Notification agent notifies the team on Slack and by email, adding SMS for P1s

While the agents do the work, Agent Fabric keeps it under control. Agent Broker routes execution from one agent to the next, the gateway checks every call against policy, and each step is traced end to end. The result, measured in our build: approximately 2.5 minutes from a logged error to a triaged ticket and a notified team.

What the live demo showed

The team ran the demo live, in a demo environment, with Datadog logs, Zoho Desk for ticketing and Slack for notifications.

To simulate a real incident, the team sent 30 error logs to Datadog. Only 5 of them were genuine errors, and the other 25 were noise. Before any AI was involved, the poller, which watches Datadog for new alerts, grouped the logs into one incident and passed it to Agent Fabric. From there the agents took over, and the audience watched a ticket appear with the full analysis, root cause and recommended fix. In the case of a P1, the team is notified on all three channels: Slack, email and SMS.

The demo then turned to governance. This is what makes it safe to let agents handle triage autonomously while engineers still own the fix. The team walked through four governance controls:

• Full tracing. Every step across every agent can be seen and audited.
• Controlled access. Omni Gateway enforces client ID and rate limits on the entry point, so only known callers can reach the system.
• Policies that work. Unauthenticated calls are rejected at the gateway before they reach any agent.
• Contained failure. If one agent fails, the problem stays with that agent and is reported.

The key architectural point: these policies sit in one shared layer, not inside each individual agent. Govern the layer once and every agent that calls it is covered. Add a new agent and it inherits the same policies from day one.

Lessons from the build

Building this for production use gave the team a clear view of what it takes to make multi agent workflows reliable.

• Keep agents focused. A single monolithic agent lost context, while smaller agents with one job each performed better.
• Force the calls that matter. The LLM writes the analysis from the knowledge base context, but creating the ticket and sending notifications are built in steps rather than left to the AI to decide, so they always happen.
• Group before AI. Noisy logs are grouped before any LLM runs. In the demo, 30 logs were grouped before being analysed and used to update the incident.
• Invest in retrieval. Initially, the right runbook entry surfaced as the top result only 23% of the time. After tuning, Recall@5 reached 89.7%.
• Take facts from systems, not the model. Ticket numbers come from the ticketing tool, never the AI, and anything AI generated is clearly labelled.

Taken together, these lessons point to one pattern: let agents coordinate the work at the top, and govern everything they can access below, in one shared layer. Get that split right and new agents can join the network without rewiring anything or losing control.

"Getting to 89.7% recall was not a prompt engineering problem. It was a data problem. We had to go back to the runbooks, restructure how information was stored, and tune the retrieval layer. That work is invisible in the demo, but it is what makes the analysis trustworthy."

Pradeep BS, Associate Director, Technology, AbsoluteLabs

Why Agent Fabric matters for your business

Integration failures are a business problem, not just a technical one. When they happen, orders, payments and inventory stop flowing, and every minute of manual triage adds to the impact.

AI agents can take on that work far faster, but speed alone is not enough. You need to trust what the agents are doing, know what they can reach, and be able to explain it to a regulator or an auditor.

That is what Agent Fabric provides. Every call is governed and every step is traced, so agents can handle triage autonomously while your engineers stay in control of the fix. Integrations and tools are built once and shared across agents, whether they run on Agentforce, another vendor's platform, or a custom framework. Each new agent joins the same governed network instead of starting from scratch.

Where to start

At AbsoluteLabs, our advice is to start with one bounded, measurable use case and extend from there. Incident triage is a good place to begin, and the build shown in the webinar is a working example of what that first step looks like.

If you are ready to start your AI journey with Agent Fabric, AbsoluteLabs can help you identify the right first use case and get it running. Get in touch with the team at contact@absolutelabs.co.