When five agents are looking at the same IT incident, which one makes the decisions?

It’s 2:14 am, and checkout latency at your largest retail store has tripled.

Your observability platform’s agent has already posted to Slack that there is a connection pool exhaustion on the orders database, with a link to the trace. Your cloud provider’s agent reports a degraded network path in one availability zone. The AI SRE tool one of your product teams adopted last spring points to a deploy that went out at 1:50. Your ITSM platform’s agent has grouped 46 tickets and routed them to the database team, because that’s the assignment group on the CI your CMDB recorded. Your on-call platform’s agent has classified the incident as a P2, based on the last time a similar incident occurred.

You now have five agents looking at the same incident, each with a confident, defensible answer from their perspective. However, none of these agents has determined which answer is right, what the outage is costing the business, or who should act. So you open a bridge call, and 12 people spend 40 minutes arbitrating between tools that were supposed to eliminate the need for bridge calls in the first place.

Put simply, you’ve automated incident investigation, but you’ve kept the argument and expensive escalations. 

Enterprise ITOps will require more AI agents than you expect

Salesforce’s MuleSoft 2026 Connectivity Benchmark surveyed 1,050 IT leaders at organizations with 1,000 or more employees. The average organization runs 12 AI agents today, and expects that number to grow 67% within two years. Half of those agents operate in isolated silos rather than as part of a multi-agent system. The same survey reports 957 applications in the average enterprise, with only 27% integrated.

Those figures cover AI agents deployed across the whole enterprise, from HR to sales, finance, and IT. IT operations is where the number is climbing fastest, because nearly every vendor in your environment has shipped an agent in the last 12 months. Datadog made Bits AI SRE generally available in December 2025. PagerDuty’s SRE Agent went GA in October 2025. AWS made its DevOps Agent generally available in April 2026, and Microsoft has the Azure SRE Agent. 

Your ITSM platform has its own agents and its own orchestrator. In addition, there is a wave of AI SRE startups selling directly to engineering teams, often adopted by a single team without a procurement cycle.

The numbers add up quickly. We recently surveyed 112 global IT leaders and found that enterprises use an average of 19 monitoring and observability tools, with 23% using 25 or more. Most of those vendors have already shipped an agent or announced one. I estimate that large enterprises will use 40 or more agents to support their operational environment by 2028, and I suspect that estimate is conservative.

Every agent is right (within its own walls)

To be clear, none of these agents is a bad tool, and most do exactly what they were built to do. The problem is the scope of what each one can see.

An agent can only reason over the data its platform holds. Your observability agent sees telemetry from the services you instrumented with that platform, and nothing from the other 18 tools. Your cloud provider’s agent sees its cloud. Your ITSM agent sees tickets, CIs as the CMDB recorded them (or didn’t), and changes as they were submitted. AI SRE tools were built for an engineer on a service team, and they read that team’s code, telemetry, and deployments. Within their scope, they’re fast.

The problem is that an IT incident at a major enterprise doesn’t stay within neat boundaries. The outage I referenced in the introduction of this article involves a deploy, a database, a network path, a business service, and an owner, and the data for each of those sit in a different tool. Understanding the impact radius means reasoning across the entire radius, and no single agent in that scenario can do so, because the context it needs lies outside its platform.

This is why each agent produces a local answer. The database agent is right that the pool is exhausted. The deploy agent is correct that something shipped at 1:50. The cloud provider’s agent is right that the network link is saturated. However, the only question the business needs answered is if the deploy exhausted the pool or the degraded network path slowed queries forcing connections to pile up and none of the five agents are positioned to answer that effectively.

Before I joined BigPanda, I ran a global ServiceNow platform team, and I’ve been on many bridge calls when the competing answers came from people. Agents don’t remove that argument from the bridge; they just make it happen at machine speed.

What interoperability fixes, and what it doesn’t

The industry’s answer is agent-to-agent protocols. The Model Context Protocol (MCP) and Google’s Agent2Agent (A2A) protocol let one vendor’s agent call another’s. In April 2026, Microsoft showed Azure SRE Agent working against AWS through the official AWS MCP server. That will work for several use cases, but it’s far from a complete solution.

If you connect five agents, each holding a different model of your environment, you will get a group chat. They can pass findings back and forth. They’ll still disagree about what depends on what, because each one learned your topology from a different source, or never learned it at all. A protocol can carry a finding from one agent to another. It can’t reconcile the four names your CMDB has for the same server, and it can’t decide whose answer wins.

The four conditions that must be in place before an agent acts

In my view, four conditions must be met before you let any agent take action on an enterprise incident. This is my own framework, drawn from building platforms and from what our customers run today.

Four questions for every vendor this season

Every vendor on every expo floor this season will tell you their agent is autonomous. These questions separate the ones that will work in your environment from the ones that will add another voice to the bridge.

1. What can your agent see outside your platform? If the answer is a list of integrations you’d have to build and maintain, you’ve found the gap.
2. When your agent and another vendor’s agent disagree, whose answer wins, and why? If nobody has an answer, the arbiter is still a human at 2 am.
3. What’s the impact radius of the actions your agent can take, and who in my organization approved it?
4. Where does what your agent learned go when the incident closes? If it stays within that vendor’s product, it compounds the problem for them. It should compound for you.

Where BigPanda fits

BigPanda is built to serve as the connective tissue among all these AI ITOps agents.

The BigPanda IT Knowledge Graph spans monitoring signals, topology, change records, and ticket history across your entire environment, rather than a single platform’s slice. Our agents reason over that graph, from L1 first response through Investigation Swarm, where agents choose which specialists to invoke and in what order. Custom Agents, with agent-to-agent interoperability, let your teams build agents that work from a shared context rather than their own. Adaptive Memory retains what each incident teaches, so the next determination starts from more than the last one did.

We don’t ask you to turn off your observability agent or your ITSM agent. Keep them. Put one shared context and one determination step in front of them, and their answers become inputs to a single decision instead of five competing ones.

Across 130 enterprises on our platform, 18% of incidents are actionable. The other 82% is what five agents without shared context will spend the night arguing about.

Three things to do this quarter

None of the following requires a purchase order, and you should do these things before deploying your next AI agent.

Inventory your operations agents. Every agent from every vendor, including the ones a team switched on without telling anyone. For each, document what data it sees, what actions it can take, and who owns it. You can’t govern what you can’t enumerate.

Replay your last three major incidents. For each one, list the agents that would have weighed in and what each would have concluded from its own data. Count how many would have agreed. That count is your coordination gap, measured in your own environment, with your own names attached.

Decide where determination lives. Name the one place where signals become incidents and incidents get owners. If you can’t name it, your agents can’t either.

Take the next steps

This article is the problem statement. In the future, I’ll discuss the answers to these and other questions, such as how an agent earns the right to act, what your SREs do once they supervise agents instead of working a queue, how to prove the value of an outage your agents prevented, and why a change advisory board that meets weekly can’t keep pace with AI-assisted delivery. 

Each of these questions stems from the same place. Before you give forty agents the right to act, give them one picture of your environment and one place where decisions get made.

If you’re ready to see agentic ITOps in action, come meet our team at Gartner IT Infrastructure, Operations & Cloud Strategies Conference (IOCS) North America 2026, from December 8–10 in Las Vegas, NV. Stop by to learn how enterprises are using agentic ITOps to improve MTTR, reduce L1 and MSP spend, prevent escalations, and build resilient IT operations.

Rob Pickering is the Field CTO at BigPanda. He previously ran the global ServiceNow platform team at Stellantis and spent nearly a decade at ServiceNow.

Top 5 takeaways from this article:

1. Agent sprawl is already here. The average enterprise runs 12 AI agents and expects 67% growth in two years, and IT operations is adding them fastest because nearly every monitoring, cloud, ITSM, and on-call vendor has shipped one.
2. Every agent is right within its own platform, and that’s the problem. Each one reasons only over the data it holds, so an enterprise incident that spans a deploy, a database, a network path, and a business service produces five local answers and no determination.
3. Interoperability protocols connect agents but don’t reconcile them. MCP and A2A let agents exchange findings; they can’t agree on your topology, fix your CMDB, or decide whose answer wins.
4. Four conditions must hold before an agent acts: a shared model of the environment, determination before action, one owner per action, and a scored record of each agent’s conclusions.
5. You can start this quarter without a purchase order. Inventory your operations agents, replay your last three major incidents to measure your coordination gap, and name the one place where determination lives.