Proof of Concept · Consumer Goods · Europe
One orchestrator above every provider's agents
A global consumer-goods enterprise, working with a Big Four consulting partner, ran its operations across multiple managed-services providers, each arriving with agent systems of their own. This proof of concept placed Opstral above all of them as the central orchestrator: coordinating agent-to-agent to determine root cause, drive resolution and produce the postmortem, whether the trigger was an incident or a question typed into Copilot chat.
- Multiplemanaged-services providers, each with their own agent systems, coordinated under one orchestratorProviders inside the POC scope
- A2Aagent-to-agent protocol used to task, query and coordinate agents the platform did not shipProtocol used, not a result
- Self-builtagents designed by the customer's own team in Agent Studio, no vendor dependencyBuilt by the customer team, not by us
- ServiceNowITSM actions executed through the platform's native connectorNative connector, actions executed
- Copilotchat as a first-class trigger, ask a question, get an orchestrated investigationTrigger path demonstrated
- Automatedpostmortems produced from the full investigation and action trailGenerated from the action trail
The Challenges
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. 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.
- Provider agent islands
Each managed-services provider ran its own agents and tools; none of them could see, or task, the others.
- Cross-boundary incidents ping-ponged
RCA that spanned providers meant serial handoffs, each with its own queue, context loss and finger-pointing.
- No central accountability
No single layer owned the question 'what actually caused this, and who fixes it?'
- Manual ITSM choreography
Tickets, updates and closures in ServiceNow were driven by hand across every provider boundary.
- Customer locked out of automation
Building new automation meant a change request to a vendor, not something the customer's own team could do.
- Postmortems assembled after the fact
Reconstructing what happened relied on memory and fragmented logs from several parties.
The architecture, and what sits above what
A multi-provider managed-services estate has a structural problem that no single provider can fix: each one automates competently inside its own boundary, and the incidents that hurt are the ones that cross boundaries. Adding a seventh agent alongside six others makes it worse. The only position that helps is above them.
This proof of concept, delivered with a Big Four consulting partner, put an orchestration layer over the providers existing agent systems and coordinated them over agent-to-agent protocol rather than replacing any of them. The customer team built its own agents in Agent Studio, which matters more than it sounds: the automation was theirs, not a vendor black box they would have to ask permission to change.
Governance held across every boundary: each engagement of a provider agent, each ITSM action and each resolution step ran through audited, reversible Action Tickets, so a multi-vendor estate gained a single accountable record for the first time.
What the proof of concept established, and what it did not
A POC is a different kind of evidence from a production deployment and we would rather draw that line ourselves than let a reader assume the stronger claim. Here is the honest split.
What it established
- An orchestrator can sit above independently owned provider agent systems and coordinate them over A2A
- Providers do not have to give up their own automation for the arrangement to work
- A customer team can build and run its own agents in Agent Studio without vendor engineering
- A chat question and an incoming incident can start the same orchestrated investigation
- ITSM actions execute through the native ServiceNow connector rather than through glue code
- A postmortem can be generated from the action trail rather than reconstructed from memory
What it did not establish
- Any measured operational outcome. There is no MTTR figure here and we are not implying one
- Behaviour at production volume, over a sustained period, with real on-call pressure
- How the arrangement holds when a provider changes its own agents without telling anyone
- Commercial or contractual mechanics of accountability across providers, which is a harder problem than the technical one
What happens when an incident crosses a boundary
This is the sequence the POC demonstrated. The step that does not exist in a multi-provider estate today is the third one.
The Sentinel loop, as it runs here
Every Opstral deployment runs the same four-stage loop: Observe, Investigate, Act, Optimize. It is the methodology rather than a feature list, and the point of setting it out per deployment is that you can see which stages carried the weight in this one and which did not.
- ObserveTake in every signal the estate produces, normalised and correlated as it arrives rather than after somebody goes looking.HereAn incident or a question starts the loop, arriving from any of the provider estates rather than from one monitoring tool.
- InvestigateWork the signal into a probable cause with the evidence attached, before anyone is notified.HereThe orchestrator tasks each provider agent system over A2A and their findings converge into one root cause, which is the thing a multi-provider estate cannot normally produce at all.
- ActRun the approved procedure where the blast radius allows it, or hand a named human the plan, the evidence and the rollback.HereResolution is driven through whichever provider is responsible, and ITSM actions execute natively rather than as a notification asking somebody to do it.
- OptimizeFeed the outcome back so the next run of the loop is better informed than the last.HereThe postmortem writes itself from the record of what each agent found and did, so the account of the incident exists without anyone reconstructing it a week later.
- Something starts it: an incident, or a question
An incoming incident from any provider estate, or an engineer asking a question in Copilot chat. Treating a chat question as a first-class trigger matters because most cross-boundary problems are noticed by a person before they are raised as a ticket.
PlatformObserve - The orchestrator tasks each provider agent system over A2A
It queries the agents that already exist inside each provider boundary rather than reimplementing what they do. Each provider keeps its automation, its access and its boundary.
PlatformInvestigate - Findings converge into one root cause
The layer that holds the cross-estate picture is the only place a cause spanning two providers can be determined. This is the step that does not exist when every provider is competent inside its own boundary and nobody owns the space between them.
PlatformInvestigate - Resolution is driven through whoever is responsible
The orchestrator does not reach into a provider estate and fix things itself. It drives resolution through the provider that owns the component, which is both the technically correct answer and the only one their contracts permit.
PlatformAct - ITSM actions execute natively
Through the ServiceNow connector rather than through bespoke integration code that somebody would then own forever.
PlatformAct - The postmortem writes itself
The investigation and action trail already contains what a postmortem is assembled from. Generating it removes the delay and the selective memory that makes most postmortems less useful than they should be.
PlatformOptimize
The Outcome
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.
| Dimension | Before | After · agent-governed |
|---|---|---|
| Cross-provider RCA | Serial vendor handoffs, context lost at each hop | One orchestrated investigation, provider agents engaged in parallel over A2A |
| Accountability | No single owner of cause and fix | One governed layer holding the full evidence and action trail |
| ITSM operations | Manual ServiceNow choreography across boundaries | ITSM actions executed via native connector, under Action Ticket governance |
| Extending automation | Change requests to vendors | Customer-built agents in Agent Studio, self-service |
| Access | Console-hopping and status calls | Copilot chat 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.'
At a glance
- Industry
- Global Consumer Goods Enterprise
- Geography
- Global
- Engagement
- Proof of concept, delivered with a Big Four consulting partner
- Scope
- Multi-Provider Managed-Services Estate
- Platform components
- Sentinel AI orchestrator, agent-to-agent (A2A) protocol, provider agent systems, native ITSM actions
- Evidence basis
- Proof of concept: scope was capability validation, not production operation. No figure on the page is a measured production result. Customer and partner identities withheld by request.
Conduct every agent in your estate
A2A orchestration above your providers' agents, self-service Agent Studio for your own team, and governed ITSM actions, validated in enterprise conditions.
Proof-of-concept engagement: scope was capability validation, not production operation. Customer and partner identities withheld by request; the customer is referred to as a "global consumer-goods enterprise."