Recent vendor announcements pull hard in opposite directions on agent governance. The right answer isn’t a neutral control plane or deep domain platform — it’s federation, where different systems handle what they do best.
We all have stories of AI “misconduct”. In February 2024, a Canadian court ruled against Air Canada after its customer service chatbot told a passenger he could book a bereavement fare and claim the discount retroactively — a policy that did not exist. The chatbot had no access to the real policy held elsewhere on the airline’s website. Air Canada argued the chatbot was “a separate legal entity responsible for its own actions“. The court rejected that defense. The AI had not malfunctioned. It operated exactly as designed but lacked the necessary domain knowledge.
This well-known case involved just one system and one customer. Widen it to cover cross-system agent chains now entering production with agents that touch CRM, ERP, service management, and financial systems in a single workflow, and the governance problem scales big time. Cyera’s May 2026 analysis of 7,200 publicly reported AI incidents identified 344 verified cases of enterprise agent-inflicted damage, including financial harm, data destruction, and unauthorized system actions. The majority was caused by agents operating autonomously.
Gartner projects that 40% of enterprise applications will feature task-specific AI agents by the end of 2026, up from fewer than 5% in 2025. The deployment race is on. The governance race for deployed agents is starting.
Every major enterprise software vendor now offers a solution that promises to govern agents across systems — or at least within theirs. The proposed solutions, however, reveal a structural disagreement that buyers need to understand before committing dollars.
Should cross-system agent orchestration sit in a domain-agnostic control plane routing work from a neutral position above all systems, or should it be governed closer to where work actually happens? This is a big question, and the dominant vendor announcements of Q1 and Q2 2026 have been pulling hard in both directions. Buyers are sitting between two chairs with no clear map.
Spoiler: Neither extreme is correct. Effective orchestration governance requires a federated model that allocates control based on the domain knowledge required to exercise it safely.
Why? Glad you asked, so let’s dig into it.
A Buyer’s Architecture Strategy
The right orchestration architecture depends on where your enterprise currently sits.
Start where your highest-consequence agentic work actually executes. If it runs inside a single dominant platform — a deeply integrated ERP, a workflow system that owns your approval chains, or a service platform that closes every customer loop — the domain governance argument applies directly. That system holds the business rules. Governance should sit close to it, not above it.
Then consider how much of your agent activity crosses system boundaries. A single-vendor shop faces a different problem than a heterogeneous enterprise where a customer commitment made in CRM triggers a fulfillment check in ERP and a service record in a third system. The more boundaries agents cross, the more a cross-system coordinator matters, and the more important it becomes that each domain system can define exactly where its governance responsibility ends.
The answer to both questions is already partially visible in your existing IT landscape. Enterprise architecture is your friend here. The decisions made about system boundaries, data ownership, and integration patterns over the past decade are the foundation your agentic governance model should build on, not work around.
If they were conscious decisions, that is.
The Domain-Agnostic Control Plane: The Promise and the Flaw
At Google Cloud Next 2026, Google repositioned Google Cloud from “AI development environment” to enterprise agent control plane. The Gemini Enterprise Agent Platform covers the full stack from identity, agent registry, via API gateway, observability, and simulation, to evaluation. Alongside it sits a Knowledge Catalog aggregating context from Salesforce, SAP, ServiceNow, Workday, and Palantir into a single layer for Gemini and other agents. Five of the seven Enterprise Titans announced expanded partnerships on this architecture, positioning Gemini Enterprise as the coordinating layer. I wrote about this before.
A neutral control plane can apply consistent governance policies, route work without vendor bias, and maintain a single audit trail across systems. Open protocols — A2A, A2UI, and MCP — carry the connections.
The flaw is in the governance layer, not the routing layer. A neutral control plane can see that an agent called an SAP OData endpoint. It can even determine whether the agent is legit. However, it cannot reliably determine whether that call was within sanctioned business logic, whether the result came from a consistent master data definition, or whether the downstream workflow complied with business rules embedded in the source system over decades of process design. Governance at that level requires domain knowledge that the control plane doesn’t have.
That’s one of the core reasons for SAP’s updated API Policy. It draws a line between “detached AI” — assistants that help humans understand SAP without touching live transactions — and “attached AI” — agents that plan, select, and execute sequences of API calls against productive systems. SAP’s position is that the latter can only be safely routed through architectures carrying SAP business context. The policy is, of course, commercially self-serving. The conceptual distinction it rests on is solid. You cannot govern what you do not understand. For the CX leader, that gap becomes apparent when an agent completes a workflow that violates a business rule the orchestration layer couldn’t have known existed.
Orchestration With Deep Domain Knowledge: Strong Arguments, Real Limits
SAP and Zendesk hold the domain-first position.
SAP’s case is built on Business Data Cloud, including the Reltio master data acquisition, the Dremio data lakehouse, and the Prior Labs structured data foundation model. AI is only as trustworthy as the enterprise data underneath it, and most of the world’s transactional data lives in SAP. Zendesk made the same argument at Relate 2026, scoped more narrowly: orchestrate every service interaction, close the learning loop, and stop there. Both vendors make the same underlying claim. You cannot govern what you do not understand.
The limitation follows directly from its own logic. When work crosses system boundaries, the system with deep domain knowledge in one part of the landscape has no reliable view of what the next domain’s agents are doing. SAP knows when a business process is executed correctly within SAP. It does not hold authoritative knowledge of the CX workflow on the Salesforce side of the same transaction. Enterprises fully committed to a single vendor stack can make the domain-first model work. Most large enterprises cannot. Still, the business consequence is a governance boundary that stops at the system edge; anything that crosses it enters unmonitored territory.
The Hybrid Claim: Domain Depth as Credential for Cross-System Authority
ServiceNow and Microsoft occupy a third position that fits neither camp.
ServiceNow’s Knowledge 2026 pitch is not “stay inside our domain.” It is “our domain knowledge earns us the right to govern agents across yours.” The AI Control Tower and Action Fabric are explicitly designed to govern agents built on Claude or any other stack. McDermott’s Q1 2026 earnings statement is direct: “our two decades of engineering combined with deep business context enable us to orchestrate and secure the agentic enterprise“. Independent analyst Rebecca Wettemann, CEO of Valoir, noted after Knowledge 2026 that she had not seen proactive alerting capabilities comparable to the Control Tower demo from any competing vendor. The question buyers need to ask is whether ITSM and workflow context is sufficient to govern agents executing financial transactions or customer-facing CX processes.
Microsoft’s position is different. Agent 365 gives Microsoft something no application vendor has: device-level visibility into agents running on Windows endpoints, including unmanaged ones. What undercuts the cross-system governance claim is that Microsoft, at Knowledge 2026, deepened its integration with ServiceNow AI Control Tower, effectively delegating agent governance above the device layer to a competitor. It owns a necessary piece of the orchestration layer. Not yet the whole thing. For buyers, the practical question is whether the piece either vendor owns covers the processes where the highest-consequence agent failures are likely to occur.
The Case for a Federated Governance Model
The right model is not a single “ring that governs them all,” nor is it a collection of domain specialists each governing their corner independently. It is a federated architecture that allocates governance authority based on the domain knowledge required to exercise it safely, while providing a framework. Role-based access control already works this way; HR systems own employee identity attributes, financial systems own payment authorization, CRM systems own customer relationship data. The same logic needs to extend into agentic AI governance.
The vendor competition of early 2026 makes the architecture more visible. Salesforce’s Headless 360 established that Salesforce business logic should be accessible from any surface, while permissions and governance travel with the platform, not the surface. SAP’s claim is that its business logic governs SAP-side execution regardless of what coordinates it. ServiceNow’s claim is that governance of decision flows should live where those decisions are modeled. These are three separate domain governance claims, all self-serving, yet structurally legitimate within their respective domains. Google’s Gemini Enterprise Agent Platform does not invalidate them; the Knowledge Catalog depends on them. The question is not which vendor wins the orchestration argument. The question is which layer does what work.
In a federated governance model, the cross-system coordinator handles routing, agent identity registration, cross-system audit trail, and policy enforcement at handoff points. Domain orchestrators handle execution governance; they decide whether a specific agent action is within sanctioned business logic, whether data outputs meet consistency requirements, and whether they close the learning loop within that domain. The federated model is not “one ring rules.” It is the right governance applied at the right layer by the entity with the knowledge to apply it.
Forrester’s AEGIS framework for agentic AI governance identifies cascading failures across chained agent workflows as the primary risk pattern: a governance gap at one point in a multi-system chain propagates before anyone detects it. You cannot govern a chain from one end. Governance is needed at every link. A break at any link is a business event, not an IT event, whether it’s a misfired approval, a customer promise that the back-end system never received, or a compliance record that stops at the system boundary.
Three Recommendations for Buyers
Map your agentic AI inventory by domain before selecting an orchestration platform. Every agent touching a productive system belongs to a domain. Identifying which system holds authoritative governance knowledge for each agent action is a prerequisite for any governance model that must hold up under audit pressure. Vendors will happily map everything to their own control plane. That mapping serves their interests, not yours.
Treat the selection of a cross-system coordinator and domain governance as separate decisions. The coordinator question is about routing, identity, audit trail, and policy enforcement at handoff boundaries. The domain governance question is about business logic, data consistency, and execution safety within a system. A vendor claiming both from a single platform should demonstrate governance depth in your highest-risk agentic domain.
Require explicit handoff documentation from every domain system before connecting it to a cross-system coordinator. Zendesk’s CPO pointed this out. Zendesk wants to orchestrate service interactions, then hand off to the meta-orchestrator at named integration points. Every domain system in your architecture should produce an equivalent statement. A vendor that cannot define what governance it applies within its domain and where responsibility transfers is offering an orchestration claim without the knowledge to back it. That’s where Forrester’s predicted cascade failures originate.
The vendor framing of 2026 pits neutral control planes against deep domain platforms. This binary is vendor-convenient. The federated governance question is yours to answer.