Every managed-services provider brought its own tooling and, increasingly, its own AI agents. Each was competent inside its own scope and blind outside it, so when an incident crossed provider boundaries, which real incidents usually do, root-cause analysis became a relay race between vendors with the customer holding the baton and the outage.
Each provider ran its own agents and tools, and none of them could see, or task, the others.
Analysis spanning providers meant serial handoffs, each with its own queue, lost context and finger-pointing.
No single layer owned the question of what actually caused this, and who fixes it.
Tickets, updates and closures were driven by hand across every provider boundary.
Building new automation meant a change request to a vendor rather than something the customer's own team could do.
Reconstructing what happened relied on memory and fragmented logs from several parties.
x101 was deployed as the neutral orchestration layer above the entire estate. It did not replace any provider's agents, it coordinated them: receiving the incident or the typed question, deciding which provider agents to engage, correlating what came back into a root cause, driving resolution, and writing the postmortem from the evidence gathered along the way.
x101 sits above every provider's agent system, holding the cross-estate picture that no single provider has.
An incoming incident, or an engineer's question typed into chat, starts an orchestrated investigation.
The orchestrator tasks and queries each provider's agents over the open agent-to-agent protocol, in parallel, and correlates their answers.
Findings converge into a single root cause, and resolution is driven through the responsible provider's agents under governance.
The customer's own team designed its agents in Agent Studio, connected to their services through native connectors.
The full investigation and action trail becomes the postmortem, generated rather than reconstructed.
The proof of concept validated the pattern that matters most in multi-vendor operations: an orchestrator that makes other vendors' agents work together, while the customer's own team extends the system without waiting on anyone.
Provider agents tasked in parallel over an open standard.
A single governed record across a multi-vendor estate.
Extended by the customer's own team, not by change request.
Generated from the investigation rather than reconstructed.
| Dimension | Before | After · with x101 |
|---|---|---|
| Cross-provider analysis | Serial vendor handoffs, context lost at each hop | One orchestrated investigation, provider agents engaged in parallel |
| Accountability | No single owner of cause and fix | One governed layer holding the full evidence and action trail |
| Service management | Manual choreography across boundaries | Actions executed via native connector under governed records |
| Extending automation | Change requests to vendors | Agents built by the customer's own team, self-service |
| Access | Console-hopping and status calls | A typed question as the front door to an orchestrated investigation |
| Postmortems | Reconstructed from fragments, days later | Generated automatically from the investigation itself |
The estate already had plenty of agents. What it lacked was anyone above them. Proving that one orchestrator can task every provider's agents, determine the root cause and hand back a finished postmortem changed the conversation from which vendor's AI to who conducts them all.
Solution summary · x101 multi-provider orchestration proof of concept
Nothing here was built for one customer. Each capability below is standard platform behaviour, applied to this problem.
About this case study. This was a proof-of-concept engagement: the scope was capability validation, not production operation. Customer and partner identities are withheld at their request, and the customer is referred to as a global consumer-goods enterprise.