But the architectures are fundamentally different. Automation Anywhere’s approach is built on the Process Reasoning Engine (PRE)—trained on 400 million+ enterprise flow executions and developed in collaboration with OpenAI—combined with a new Context Intelligence Graph that retrieves task-specific context rather than flooding agents with data. UiPath’s approach layers Intelligent Xtraction and Processing (IXP) for document intelligence on top of Maestro orchestration, with multi-agent coordination across Claude, Gemini, and custom-coded agents in the same workflow.

If you’re an RPA professional navigating this shift, our RPA-to-agentic-AI transition guide covers the foundational skills you’ll need. For Agentic AI Architects evaluating which platform to deploy, the decision hinges on orchestration philosophy, AI backbone, document processing, governance depth, and where each vendor’s P2P solution is genuinely strong versus where it’s still catching up. This guide breaks it all down with a decision table, a feature-by-feature walkthrough, and a clear verdict at the end.

Decision Table: Automation Anywhere vs UiPath P2P at a Glance

Why Procure-to-Pay Is the New Agentic Battleground

The procure-to-pay automation market is valued at approximately USD 10.3 billion in 2026, growing at a CAGR of 9.3%, with large enterprises accounting for 65% of spending (Market.us, 2026). The growth driver isn’t new: procurement workflows span too many disconnected systems—ERPs, CRMs, supplier portals, approval chains, email inboxes—and every handoff between systems creates friction, exceptions, and manual work.

What is new is that both UiPath and Automation Anywhere are using P2P as the proving ground for their agentic AI platforms. This isn’t RPA with a chatbot bolted on. Both solutions deploy autonomous agents that reason about exceptions, route approvals across channels (Slack, Teams, email), ingest and classify invoices from multiple formats, match them to purchase orders, and escalate only what genuinely requires a human decision. The P2P use case is a natural fit because it’s high-volume, rules-heavy, exception-dense, and spans enough systems to truly test whether agentic orchestration works at enterprise scale.

For automation architects, the choice between these two platforms will likely determine your agentic infrastructure for the next three to five years. Here’s what each brings to the table.

Architecture Deep Dive: How Each Solution Actually Works

Automation Anywhere: Process Reasoning Engine + Mozart Orchestrator

Automation Anywhere’s P2P solution is part of the Autonomous Finance suite, built on two foundational components announced throughout 2026:

The Process Reasoning Engine (PRE) is the AI brain of the operation. Developed in collaboration with OpenAI and trained on 400 million+ enterprise automation executions, PRE determines what enterprise action should happen next and orchestrates execution across systems. The new Context Intelligence Graph, announced at Imagine 2026 in May, connects to an organization’s systems of record, documents, policies, knowledge bases, and execution history. It automatically creates associations and metadata to retrieve the right context for each specific task—rather than exposing everything to every agent step, which increases cost, slows execution, and risks leaking sensitive data to irrelevant process steps.

In Automation Anywhere’s internal evaluations, agents using PRE with Context Intelligence Graph demonstrated over 30% higher accuracy compared to those operating without it (Automation Anywhere, May 2026).

Mozart Orchestrator handles the execution layer—connecting AI agents, automations, documents, and APIs in a single unified composer. It manages decisions, dependencies, context, and exceptions, enabling AI agents to plan, reason, and collaborate across bots, systems, data, and human touchpoints. The Split and Merge feature (GA in v3.9 for Enterprise license customers) supports full parallel execution, nested branches, conditional logic, and automatic merge point handling with live monitoring.

In the P2P context specifically, the solution acts as an intelligent layer that connects the entire procurement lifecycle end-to-end, including procurement systems and ERP. Finance leaders get governed spend visibility and earlier exception addressing, while the OpenAI reasoning-to-action loop handles the complex decision-making that traditional RPA couldn’t touch.

UiPath: IXP + Maestro + Multi-Agent Ecosystem

UiPath’s Solution for Purchase-to-Pay takes a different architectural approach, centering on the Maestro orchestration platform and IXP document intelligence:

Intelligent Xtraction and Processing (IXP) handles the document-heavy portions of P2P. On the invoice side, agents ingest invoices from email, PDF, supplier portals, and EDI, then match them to purchase orders, classify mismatches, and guide exception resolution. IXP combines machine learning-based extraction with governed exception handling, so only items that genuinely need a human decision get escalated.

UiPath Maestro coordinates the orchestration layer. Unlike Automation Anywhere’s single-model approach with OpenAI, Maestro supports multi-agent orchestration across UiPath agents alongside Claude, OpenAI, Gemini, Microsoft Copilot, LangChain, CrewAI, and custom-coded agents in the same workflow (UiPath Maestro product page). Policy, audit, and human-in-the-loop controls live at the orchestration layer, expressed once and applied across every agent, bot, and step.

On the buying side, AI agents route approvals to appropriate stakeholders and proactively reach out via Teams or Slack without leaving their workflow. The solution introduces what UiPath calls an “agentic execution layer above existing systems of record”—combining AI agents, automation workflows, and end-to-end orchestration to reduce manual effort and processing costs while keeping the ERP authoritative and controls intact.

Hitesh Ramani, UiPath’s Chief Accounting Officer and Deputy CFO, described the rationale: the solution helps “organizations close gaps in procurement and accounts payable workflows… finance teams will be able to process transactions faster and focus more of their time on strategic, value-driven work” (UiPath press release, March 2026).

Head-to-Head: Six Dimensions That Matter

1. AI Reasoning and Decision-Making

Automation Anywhere has the stronger story here, at least on paper. The OpenAI collaboration gives PRE access to advanced reasoning models in a co-developed loop: OpenAI handles reasoning and interpretation, PRE handles governed execution. The 400M+ execution training dataset is a legitimate differentiator—it means the reasoning engine has seen a vast range of enterprise edge cases before encountering yours. The Context Intelligence Graph adds selective context retrieval, which is architecturally sound: giving an agent all available context is a known anti-pattern that increases hallucination risk and cost.

UiPath takes a model-agnostic approach. Maestro can orchestrate agents powered by any major LLM provider, which gives architects more flexibility to swap models as pricing and capabilities shift. The trade-off is that UiPath doesn’t have a single, deeply integrated reasoning engine equivalent to PRE—the intelligence is distributed across the models you choose to plug in.

Verdict: Automation Anywhere wins on depth of AI integration for P2P specifically. UiPath wins on model flexibility and future-proofing.

2. Document Processing and Invoice Intelligence

UiPath’s IXP is the more mature document intelligence platform. It’s purpose-built for the extraction-heavy portions of P2P—ingesting invoices across formats (email, PDF, portals, EDI), performing PO matching, classifying mismatches, and routing exceptions. IXP has years of production deployment behind it and benefits from UiPath’s broader document understanding investments.

Automation Anywhere’s Document Automation (evolved from IQ Bot) handles similar extraction tasks but hasn’t received the same level of dedicated investment as IXP. The PRE compensates somewhat by bringing reasoning capability to exception handling, but for pure extraction accuracy and format coverage, UiPath has the edge.

Verdict: UiPath wins on document processing maturity. Automation Anywhere’s reasoning layer partially compensates for extraction gaps.

3. Orchestration and Workflow Management

Automation Anywhere’s Mozart Orchestrator emphasizes universal orchestration—a single composer for AI agents, bots, documents, APIs, and human tasks. The Split and Merge feature enables true parallel execution with conditional logic and automatic merge handling. The approach is more centralized: everything runs through Mozart.

UiPath Maestro is BPMN-based, which gives it more structured process modeling capability. Maestro Case handles exception-driven work, Maestro Flow supports developer-first orchestration with coding agents, and the core Maestro engine coordinates the full stack. The multi-product architecture (Maestro, Maestro Case, Maestro Flow) is more modular but also more complex to configure.

Verdict: UiPath wins on orchestration breadth and standards compliance (BPMN). Automation Anywhere wins on simplicity of a unified orchestration model.

4. Governance, Testing, and Compliance

Automation Anywhere introduced two governance features at Imagine 2026: AI Evaluations (GA now), which assess agent performance at design time and runtime—measuring whether agents achieve correct outcomes, use the right tools, and follow appropriate execution paths—and Process Simulation, Optimization & Testing (preview), which lets teams simulate real-world scenarios including failures and edge cases before deployment.

UiPath embeds governance at the Maestro orchestration layer through the AI Trust framework. Policy, audit, and human-in-the-loop controls are expressed once and applied across every agent and bot. UiPath also has Test Cloud for broader test automation, and UiPath was named a Leader in the 2026 Gartner Magic Quadrant for AI Testing Tools—a distinct advantage for organizations that need testing governance alongside process governance.

Verdict: Both are strong. Automation Anywhere’s AI Evaluations are more purpose-built for agent performance measurement. UiPath’s Test Cloud gives it broader QA integration.

5. Ecosystem and Integration Breadth

UiPath’s Integration Service connects to hundreds of enterprise applications natively, and the marketplace offers thousands of pre-built activities. Combined with IXP’s multi-format ingestion (email, PDF, EDI, portals) and Maestro’s multi-agent support (LangChain, CrewAI, custom agents), UiPath offers a wider integration surface for complex, multi-system P2P environments.

Automation Anywhere connects to major enterprise platforms (Salesforce, ServiceNow, SAP, custom apps) through its universal orchestration layer. The Aisera acquisition (now integrated as IT Service Management and IT Operations products) adds service desk connectivity. However, the integration marketplace is narrower than UiPath’s, and the multi-agent story is more tightly coupled to the OpenAI partnership. (For more on agent interoperability protocols, see our A2A and MCP guide for Agentic AI Architects.)

Verdict: UiPath wins on integration breadth and multi-agent flexibility. Automation Anywhere’s OpenAI depth partially compensates.

6. Deployment Model and Time-to-Value

Automation Anywhere positions the P2P solution as “configurable and ready-to-deploy,” with the OpenAI collaboration designed to provide “a fast on-ramp to agentic operations—pre-built, deeply contextual, and deployable in weeks rather than months.” The introduction of AAI Code (low-code tool announced at Imagine 2026) lets teams describe workflows in natural language or bring existing process materials like SOPs and screenshots.

UiPath describes its P2P solution as “purpose-built” with pre-configured workflows for buying-side approvals and invoice-side processing. The approach assumes an existing UiPath installation (Orchestrator, Studio, robots), which means faster deployment for existing UiPath customers but a heavier initial lift for greenfield environments.

Verdict: Automation Anywhere has a slight edge for greenfield P2P deployments. UiPath has a clear advantage for organizations with existing UiPath infrastructure.

The Broader Platform Context: What’s Behind Each P2P Solution

Neither P2P solution exists in isolation. Understanding the broader platform investments helps predict where each vendor is heading.

Automation Anywhere’s 2026 Platform Story

Automation Anywhere has made several significant moves in 2026:

• OpenAI collaboration (January 2026): Co-developed AI-native agentic solutions combining PRE with OpenAI reasoning models
• Imagine 2026 (May): Unveiled universal orchestration, AAI Code, Context Intelligence Graph, AI Evaluations, and Process Simulation
• Autonomous Finance suite: P2P is the second module (after Autonomous Service Desk, which has fulfilled 1B+ IT service requests)
• Outcome-based transactions: In July, AA reported the largest outcome-based transaction in company history, signaling enterprise commitment to paying for results rather than licenses
• Gartner recognition: Named a Leader in the 2026 Gartner Magic Quadrant for RPA for the eighth consecutive year

UiPath’s 2026 Platform Story

UiPath has also been aggressive in 2026:

• WorkFusion acquisition (February 2026): Acquired for $189.5 million, adding pre-built AI agents for financial crimes compliance (AML, KYC) in financial services (UiPath newsroom)
• Maestro expansion: Maestro Case for exception-driven work, Maestro Flow for developer-first orchestration with coding agents
• Autopilot coding agent (GA August 2026): UiPath Autopilot is now a full coding agent, generating workflows from natural language (see our detailed Autopilot GA guide)
• Agentic AI Summit (March 2026): P2P solution launch alongside industry-focused solutions for healthcare, financial services, and retail
• AI Testing leadership: Named a Leader in the Gartner Magic Quadrant for AI Testing Tools

Real-World Deployment Considerations

When to Choose Automation Anywhere’s P2P Solution

• You’re a finance-first organization and your CFO is sponsoring the initiative. AA’s Autonomous Finance suite is designed for the Office of the CFO, with P2P and Service Desk as the first two modules.
• You want OpenAI-powered reasoning out of the box. If your organization has committed to OpenAI’s enterprise offering, the deep PRE integration gives you purpose-built reasoning without glue code.
• You value greenfield simplicity. For organizations without an existing RPA footprint, AA’s unified platform (Mozart + PRE + AAI Code) may be faster to deploy.
• Context-sensitive operations matter. If your P2P process involves complex policy lookups, execution history, and cross-system context, the Context Intelligence Graph’s selective retrieval could reduce agent errors.
• Outcome-based pricing appeals to you. AA’s move toward outcome-based transactions means you may be able to tie cost to results rather than robot licenses.

When to Choose UiPath’s P2P Solution

• You have an existing UiPath estate. If your organization already runs UiPath Orchestrator, Studio, and attended/unattended robots, adding the P2P solution is an incremental deployment, not a platform migration.
• Document-heavy invoicing is your biggest pain point. IXP is the more mature document intelligence platform, and if your P2P bottleneck is invoice extraction across formats (PDF, email, EDI, portals), UiPath handles this more cleanly.
• You need multi-model flexibility. If you’re running agents across Claude, Gemini, OpenAI, and custom models, Maestro’s model-agnostic orchestration avoids vendor lock-in to a single AI provider.
• Compliance and financial crime are concerns. The WorkFusion acquisition gives UiPath pre-built AML/KYC agents for financial services—a natural extension of P2P in banking environments.
• Testing governance is non-negotiable. UiPath’s Test Cloud and Gartner-recognized AI testing capabilities give you end-to-end quality assurance alongside process governance.

What Neither Vendor Tells You: Three Honest Caveats

1. “Ready-to-Deploy” Still Means Months of Configuration

Both vendors describe their P2P solutions as configurable and pre-built. In practice, any enterprise P2P deployment involves mapping to your specific ERP (SAP, Oracle, Microsoft Dynamics), configuring approval hierarchies, training extraction models on your invoice formats, and testing exception handling against your real edge cases. Budget 3–6 months for a controlled rollout, not the “weeks” that press releases suggest.

2. The AI Accuracy Claims Need Your Own Validation

Automation Anywhere’s “30%+ accuracy improvement” with Context Intelligence Graph comes from internal evaluations. UiPath doesn’t publish comparable aggregate numbers. Before committing, run a proof-of-concept on your own data. Enterprise P2P data is messy—partial POs, multi-line invoices, currency mismatches, retroactive pricing adjustments—and vendor benchmarks may not reflect your complexity.

3. Neither Solution Replaces Your ERP

Both vendors are careful to position their P2P solutions as an “agentic execution layer above existing systems of record.” The ERP remains authoritative. This is the right design, but it means you’re adding an orchestration layer on top of SAP/Oracle/Dynamics, not simplifying your stack. Total cost of ownership should include the orchestration platform licensing, AI model consumption costs (especially with OpenAI-based reasoning), and ongoing model retraining.

The Market Context: Why This Race Matters

The UiPath vs Automation Anywhere rivalry has defined the RPA market for nearly a decade. Both companies have been recognized as Leaders in the Gartner Magic Quadrant for RPA in 2026—UiPath for the seventh-plus consecutive year with the highest Ability to Execute rating, Automation Anywhere for the eighth consecutive year.

But the P2P showdown represents something bigger than another feature comparison. It’s the first head-to-head test of whether these former RPA vendors can compete as agentic AI platforms. P2P is the canary in the coal mine: if agents can reliably handle the complexity of multi-system procurement workflows—with real money, real compliance requirements, and real supplier relationships on the line—then the broader promise of enterprise agentic automation becomes credible. (We’ve written extensively about why agentic automation programs fail—P2P deployments face every one of those risks.)

The procure-to-pay solution market is projected to reach USD 15.15 billion by 2033 (SNS Insider, 2026). The vendor that wins the agentic P2P category won’t just capture procurement budgets—they’ll establish the pattern for agentic automation across order-to-cash, record-to-report, and every other finance workflow that follows.

FAQs

Can I run Automation Anywhere’s P2P solution alongside an existing UiPath RPA deployment?

Technically yes—both solutions operate above your ERP as an orchestration layer, and they don’t conflict at the system-of-record level. However, running two automation platforms introduces governance complexity, duplicate licensing costs, and context fragmentation. Most organizations will want to standardize on one platform for their agentic P2P layer.

Does UiPath’s P2P solution require Maestro, or can I use it with Orchestrator alone?

The agentic capabilities (multi-agent coordination, intelligent exception handling, cross-system orchestration) require Maestro. You can run basic RPA-driven P2P automation with Orchestrator and Studio, but the purpose-built P2P solution leverages Maestro’s orchestration, IXP’s document intelligence, and the AI Trust governance framework together.

What ERP systems do both solutions support?

Both solutions are designed to work with major ERP platforms including SAP, Oracle, Microsoft Dynamics, and others. They function as an orchestration layer above the ERP rather than replacing it. Specific connector availability varies by vendor and plan—verify during proof-of-concept that your ERP version and deployment model (on-premise, cloud, hybrid) are supported.

How do the AI consumption costs compare between the two platforms?

Automation Anywhere’s deep OpenAI integration means reasoning model API costs are embedded in platform pricing (details vary by contract). UiPath’s model-agnostic approach means you bring your own API keys for whichever models you use with Maestro, giving you more control over AI costs but requiring you to manage model billing separately. Request detailed cost modeling from both vendors during evaluation.

Which solution is better for organizations in regulated industries like banking or healthcare?

UiPath has a slight edge in regulated financial services due to the WorkFusion acquisition, which adds pre-built AML/KYC compliance agents. Automation Anywhere’s Gujarat government partnership and healthcare-focused Aisera integration serve public sector and healthcare use cases. Evaluate both against your specific compliance requirements, audit trail needs, and data residency constraints.

Key Takeaways

• Both solutions are genuinely agentic—not rebranded RPA with a chatbot. They deploy autonomous agents that reason about exceptions, route decisions, and handle multi-format documents.
• Automation Anywhere’s differentiator is the OpenAI-powered Process Reasoning Engine and Context Intelligence Graph, offering deep reasoning out of the box with selective context retrieval.
• UiPath’s differentiator is IXP document maturity and multi-agent flexibility—Maestro orchestrates across any LLM provider, and IXP has deeper extraction capabilities for invoice-heavy environments.
• Choose Automation Anywhere for greenfield deployments, OpenAI-committed organizations, and finance-led initiatives sponsored by the CFO.
• Choose UiPath for existing UiPath estates, document-heavy P2P workflows, multi-model AI strategies, and regulated financial services environments.
• Budget 3–6 months for real deployment regardless of vendor—”ready-to-deploy” means configurable, not instant.
• Run a proof-of-concept on your own data. Vendor benchmarks don’t reflect your specific invoice formats, ERP configuration, and exception patterns.
• This is the first real agentic AI platform war. The vendor that wins P2P will set the pattern for every finance workflow that follows.

References

1. Automation Anywhere. “Automation Anywhere’s New Agentic Procure-to-Pay Solution Extends Autonomous Finance Across the Procurement Lifecycle.” PR Newswire, September 9, 2026. Link
2. UiPath. “UiPath Announces New Agentic Solution to Accelerate Procurement Cycles.” UiPath Newsroom, March 25, 2026. Link
3. Automation Anywhere. “Automation Anywhere Unveils 2026 Platform Enhancements to Run AI-Driven Processes Across the Enterprise.” Automation Anywhere Press Room, May 19, 2026. Link
4. Automation Anywhere. “Automation Anywhere Advances AI-Native Agentic Solutions for the Enterprise with OpenAI.” PR Newswire, January 2026. Link
5. UiPath. “UiPath Acquires WorkFusion Strengthening Agentic Solutions for Financial Services.” UiPath Newsroom, February 2026. Link
6. Market.us. “Procure-to-Pay Software Market Size | CAGR of 9.2%.” 2026. Link
7. SNS Insider. “Procure-to-Pay Solution Market Set to Hit USD 15.15 Billion by 2033.” GlobeNewswire, February 2026. Link
8. Everest Group. “UiPath’s Acquisition of WorkFusion Marks the Shift Toward Verticalized Agentic Solutions.” 2026. Link
9. Automation Anywhere. “Process Reasoning Engine.” Product page. Link
10. UiPath. “UiPath Maestro: Business Orchestration with BPMN and AI Agents.” Product page. Link

If you build automations for a living — whether in UiPath Studio, Power Automate, or Python-based agent frameworks — the implications of Orca’s architecture deserve your attention. The same orchestration principles that make RPA Orchestrator indispensable for managing bot fleets now apply to managing fleets of AI coding agents. This guide breaks down what Orca ADE actually does, how its architecture works under the hood, how to set it up, and why agentic AI architects should be watching this space closely.

What Is Orca ADE?

Orca is a free, MIT-licensed desktop application built by Stably AI, a Y Combinator Winter 2022 company founded by Jinjing Liang (who previously built the testing and release infrastructure that ships Google Chrome to billions of users) and Neil Parker (one of Uber’s youngest Tech Leads, who led multiple large-scale ML projects on Uber’s Safety team). The founding team includes PhD graduates specializing in AI’s application in software reliability plus ex-founders who have previously built and sold an AI startup.

At its core, Orca is an Agent Development Environment — a new category of tooling that sits above individual AI coding agents and below your project management workflow. Think of it as the control plane for your agent fleet. Instead of the sequential prompt → wait → review → prompt loop that defines working with a single coding agent, Orca lets you fan one prompt across five agents simultaneously, each operating in its own isolated Git worktree, then compare the results and merge the winner.

The “ADE” framing is deliberate. Just as IDEs (Integrated Development Environments) unified editing, compiling, and debugging into one interface in the 1990s, Orca argues that the 2026 developer workflow needs a unified environment for orchestrating, reviewing, and managing the output of multiple AI coding agents. The project describes itself as built “for 100x builders” — engineers who run 10 to 100 coding agents at once.

Why Orca Matters: The Shift from Sequential to Parallel Agent Work

To understand why Orca crossed 43,000 stars in five months, you need to understand the problem it solves.

By mid-2026, the AI coding agent market has exploded. Claude Code, OpenAI Codex, Google’s Antigravity, Cursor CLI, GitHub Copilot CLI, Devin, Cline, and dozens more all compete for developer attention. A McKinsey research report found that nearly one-third of surveyed organizations had decided against purchasing at least one software product because they could build the functionality internally using AI-powered coding agents. Gartner predicts that 40% of enterprise applications will feature task-specific AI agents by end of 2026, up from less than 5% in 2025.

But here is the bottleneck: most developers use these agents one at a time, in a sequential loop. You prompt Claude Code, wait for it to finish, review the output, then prompt again. If you want to try a different agent on the same task — say, comparing Codex’s approach to Claude Code’s — you need to switch tools, contexts, and often branches manually. Scale this across a team of five developers, each running agents on different features, and the coordination overhead becomes the new bottleneck.

Orca eliminates this bottleneck through three architectural decisions:

1. Git worktree isolation — every agent session gets its own genuine git checkout in a separate worktree. Agents cannot overwrite each other’s work mid-task. There is zero shared mutable state between concurrent sessions.
2. Agent-agnostic orchestration — Orca does not wrap, proxy, or modify agent traffic. If a tool runs in a terminal, it runs in Orca. Your existing Claude Code or Codex subscriptions work unchanged; Orca just runs them in parallel.
3. Unified review surface — annotated diffs, inline comments, and branch comparison happen in one window, so the human reviewer (still essential) can evaluate multiple agent outputs without context-switching between tools.

This is not incremental improvement. It is a categorical change in how software gets built — from one-human-one-agent to one-human-many-agents. The RPA-to-agentic-AI transition that many teams are navigating involves exactly this kind of paradigm shift.

Architecture Deep-Dive: How Orca Actually Works

Orca employs a three-process Electron architecture — Main, Preload, and Renderer — to separate system-level operations from the UI and maintain responsiveness while handling heavy background tasks.

Process Architecture

The Main process handles all system-level operations: Git operations (clone, checkout, worktree creation), PTY (pseudo-terminal) session management for running agent CLIs, SSH tunnel establishment and maintenance, file system watchers, and IPC (inter-process communication) with the renderer. It runs on Node.js and has full access to native APIs.

The Preload process acts as a security bridge between Main and Renderer. It exposes a carefully scoped API surface to the renderer via Electron’s contextBridge, preventing the UI from directly accessing system resources — a security design pattern that matters when you are running untrusted agent output.

The Renderer process runs the UI, built with React and TypeScript. It handles the workspace layout (terminal splits, editor panes, diff viewers, browser previews), state management for active worktree sessions, and the visual diff annotation system.

Git Worktree Isolation — The Core Innovation

The heart of Orca’s architecture is its use of Git worktrees. A Git worktree is a linked working tree attached to a repository that lets you check out a different branch without cloning the entire repo. Orca creates one worktree per agent session, each on its own branch, checked out from the same base ref.

This means:

• Agent A (Claude Code) works on feature-auth-claude in /worktrees/auth-claude/
• Agent B (Codex) works on feature-auth-codex in /worktrees/auth-codex/
• Agent C (Gemini) works on feature-auth-gemini in /worktrees/auth-gemini/

All three share the same Git object store (so history and refs are shared), but each has its own working directory and index. There is no file-level contention. No merge conflicts mid-task. No race conditions on .git/index. This is filesystem-level concurrency, not application-level locking.

For RPA practitioners familiar with UiPath Orchestrator’s queue-based job isolation — where each robot gets its own transaction and its own process execution context — the parallel is striking. Orca achieves for coding agents what Orchestrator achieves for RPA robots: deterministic isolation with centralized review.

Terminal Layer: Ghostty-Class WebGL Rendering

Each agent runs inside a PTY session rendered through a WebGL-accelerated terminal emulator. Orca’s terminal layer supports infinite splits (arrange agents, terminals, browsers, diffs, and files into split panes that match the shape of the task), persistent scrollback that survives application restarts, and session restoration on crash or reconnect. The rendering performance matters because coding agents produce substantial terminal output — watching five agents work simultaneously requires a terminal layer that does not bottleneck on rendering.

Supported Agents: 30+ CLI Agents and Counting

Orca’s agent-agnostic design means it works with any CLI agent. As of September 2026, the officially tested list includes over 30 agents:

The key architectural point: Orca does not proxy agent traffic through its own servers. Your API keys, subscriptions, and agent sessions remain between you and the agent provider. Orca is a local orchestration and review layer, not a middleman. This is a deliberate privacy and security decision — and one that enterprise teams evaluating the tool will appreciate.

Key Features That Set Orca Apart

1. Parallel Worktrees with Competitive Evaluation

Fan one prompt across multiple agents, each in its own isolated Git worktree. When all agents complete, compare their diffs side by side. Merge the winner. This is not theoretical — it is the primary workflow Orca was built around. For complex implementation tasks where the “right” approach is uncertain, running three agents in parallel and picking the best result is faster than running one agent, reviewing, deciding it is suboptimal, and starting over.

2. Mobile Companion App

Monitor and steer agents from your phone. Get notified when an agent finishes and send follow-ups from anywhere. Available on iOS (App Store and TestFlight) and Android (APK). For team leads managing agent workloads across a distributed team, this is a force multiplier — you can review and redirect agent work during commute or between meetings.

3. Design Mode

Click any UI element in a real Chromium window embedded in Orca to send its HTML, CSS, and a cropped screenshot straight into your agent’s prompt. This bridges the gap between visual design intent and code generation — instead of describing a UI element in text, you point at it.

4. Annotated AI Diffs

Drop inline comments on any diff line generated by an agent and ship those comments back to the agent as follow-up instructions. This creates a tight human-in-the-loop review cycle without leaving the tool. Review, edit, and commit without context-switching.

5. SSH Remote Worktrees

Run agents on a remote server with full file editing, Git, and terminal access. Auto-reconnect and port forwarding included. For teams with beefy cloud build machines, this means you can run compute-intensive agent workloads on powerful hardware while controlling them from a lightweight laptop.

6. GitHub and Linear Integration

Browse PRs, issues, and project boards in-app. Open a worktree directly from a task and review without context-switching. This connects agent work to your existing project management workflow.

7. Orca CLI

Agents can drive Orca too. Script every workflow with orca worktree create, snapshot, click, and fill. This enables automation of the agent orchestration itself — a meta-automation layer that will feel familiar to anyone who has written UiPath coded workflows or Power Automate desktop flows to orchestrate other automations.

8. Computer Use

Let agents operate desktop apps and visible UI when a workflow needs real interaction. This is the bridge between terminal-based coding agents and GUI automation — precisely the intersection where RPA meets agentic AI.

Getting Started: Installation and First Run

Step 1: Download and Install

Orca is available for macOS (Apple Silicon and Intel), Windows, and Linux.

# macOS (Homebrew)
brew install --cask stablyai/orca/orca

# Arch Linux (AUR)
yay -S stably-orca-bin

# Or download directly from https://onorca.dev/download
# Windows: .exe installer
# Linux: AppImage
# macOS: .dmg

Step 2: Open a Repository

Launch Orca and open your project repository. Orca will detect the Git configuration and prepare its worktree infrastructure.

Step 3: Create Your First Parallel Session

Create a new worktree from the workspace panel. Select which agent(s) to run — Claude Code, Codex, or any other CLI agent you have installed. Each agent gets its own branch and working directory.

Step 4: Fan a Prompt

Write your prompt once, then fan it across multiple agents. Orca creates isolated worktrees for each, starts the agent sessions, and shows you real-time output in split terminal panes.

Step 5: Review, Annotate, Merge

When agents complete, use the built-in diff viewer to compare outputs. Annotate lines with feedback. Merge the best result back to your main branch.

Production Considerations

• Cost: Orca itself is free. Your real bill is the agent subscriptions and model credits you already pay for. Running five agents in parallel means five times the token consumption. Budget accordingly.
• Disk space: Git worktrees share the object store but each gets its own working tree checkout. Large monorepos will consume proportionally more disk space per concurrent worktree.
• Network: Parallel agent sessions mean parallel API calls. Ensure your network and API rate limits can handle the concurrency.

Orca vs. the Alternatives: Where It Fits in the 2026 Landscape

Orca occupies a distinct niche in the 2026 AI coding tool ecosystem. To understand where it fits, consider the three dominant philosophies:

The key distinction: Orca does not compete with Claude Code, Codex, or Cursor. It orchestrates them. The most popular developer stack in 2026 — Claude Code + Cursor — works inside Orca. You are not choosing between them; you are adding an orchestration layer on top.

This is analogous to the relationship between an RPA robot and an RPA Orchestrator. The robot (agent) does the work. The orchestrator (Orca) manages the fleet, assigns tasks, isolates execution contexts, and provides the review and merge surface.

The RPA Connection: Why Automation Teams Should Care

If you are reading this on rpabotsworld.com, you likely build automations for a living. Here is why Orca matters to you specifically:

The Orchestration Pattern Is Identical

UiPath Orchestrator manages a fleet of robots. Each robot gets an isolated execution context (its own machine or container). Jobs are assigned, monitored, and their outputs reviewed centrally. Orca does the same thing for coding agents — isolated worktrees instead of isolated VMs, diff review instead of job logs, branch merging instead of queue completion.

If you understand why agentic automation programs fail, you understand why unmanaged agent fleets are equally dangerous. Without orchestration, parallel agents create merge conflicts, duplicate work, inconsistent code styles, and review bottlenecks. Orca’s worktree isolation solves the same class of problems that Orchestrator’s queue-based transaction isolation solves.

RPA Teams Are Already Writing More Code

The transition from low-code RPA (drag-and-drop XAML workflows) to coded automations (C# coded workflows in UiPath, Python-based agents, LangGraph pipelines) means RPA teams are spending more time in code. As the 2026 agentic platform comparison shows, every major RPA vendor is adding agent capabilities, and those capabilities increasingly involve writing and reviewing code. A tool that makes code review of AI-generated output faster and more reliable is directly relevant.

The Agent Sprawl Problem

Enterprise teams that have adopted AI coding agents often face the same “bot sprawl” problem that plagued early RPA programs — too many agents, too little governance, no centralized visibility. Orca provides a single pane of glass for agent activity, which is the first step toward the kind of agent governance frameworks that enterprise IT departments are starting to demand.

Computer Use Bridges RPA and Coding Agents

Orca’s Computer Use feature — letting agents operate desktop apps and visible UI — sits precisely at the intersection of RPA (automate GUI interactions) and coding agents (automate code generation). For hybrid automation workflows that involve both code generation and GUI interaction, this is a natural convergence point.

Limitations and What to Watch

No tool review is complete without an honest assessment of limitations:

• Electron-based: Orca is an Electron app, which means higher memory consumption than native alternatives. Running five concurrent agent terminals with WebGL rendering in an Electron wrapper will consume significant RAM. Teams on memory-constrained machines should monitor resource usage.
• Cost multiplication: Running agents in parallel multiplies your API costs proportionally. Five agents working for 30 minutes each costs the same as one agent working for 150 minutes. The value proposition depends on whether parallel speed is worth the cost.
• Source-available, not fully open governance (yet): While MIT-licensed, the project is still primarily driven by Stably AI. Community governance structures are evolving. Compare this to projects like n8n (which has a mature community contribution model) or LangChain (which has a formal RFC process).
• No built-in agent evaluation: Orca shows you diffs but does not automatically evaluate code quality, run tests on agent output, or score agent performance. The human reviewer remains the quality gate. Future integration with automated testing pipelines would strengthen the platform significantly.
• Early Windows and Linux support: While officially cross-platform, the project’s roots are on macOS. Windows and Linux users should expect a slightly less polished experience in the current version, with rapid improvement expected given the project’s daily ship cadence.

Frequently Asked Questions

Is Orca ADE free?

Yes. Orca itself is completely free and MIT-licensed. There is no subscription, no per-seat pricing, and no premium tier. Your only costs are the AI coding agent subscriptions (Claude Code, Codex, etc.) and model API credits you already pay for. Orca is an orchestration layer, not a model provider.

Does Orca ADE proxy my agent traffic through its servers?

No. Orca runs entirely locally. Your API keys, agent sessions, and code stay on your machine. The only network component is the optional mobile companion relay (for phone notifications), which is also open source and available in the repository’s cloud/ directory if you want to self-host it.

Can I use Orca with UiPath coded workflows or Power Automate scripts?

Yes, if you use CLI-based coding agents to write those workflows. For example, you could run Claude Code in Orca to generate UiPath C# coded workflows, while simultaneously running Codex to generate unit tests for those workflows, each in its own worktree. Orca orchestrates the coding agents; it does not care what language or framework the agents are writing in.

How does Orca compare to multi-agent frameworks like CrewAI or LangGraph?

Different category entirely. CrewAI and LangGraph orchestrate AI agents at the application layer — defining roles, tools, and communication patterns for agents that perform tasks within a running application. Orca orchestrates coding agents at the development layer — managing the environments where agents write code. You might use LangGraph to build a multi-agent system, and use Orca to run the coding agents that write that LangGraph code.

What is an Agent Development Environment (ADE)?

An ADE is a new category of developer tooling that provides a unified environment for running, monitoring, reviewing, and managing the output of multiple AI coding agents. Just as an IDE unified editing, compiling, and debugging in one tool, an ADE unifies agent orchestration, output review, and code merging. Orca coined the term in 2026 and is the leading implementation of the concept.

Key Takeaways

• Orca ADE introduces a new category — the Agent Development Environment — that orchestrates parallel coding agents the way an RPA Orchestrator manages a bot fleet.
• Git worktree isolation is the core architectural innovation: each agent gets its own branch and working directory with zero shared mutable state, enabling true parallel execution without merge conflicts.
• Agent-agnostic by design: Orca works with 30+ CLI agents (Claude Code, Codex, Gemini, Cursor, and more) without proxying traffic or requiring vendor lock-in.
• 43,000+ stars in 5 months signals genuine developer demand for multi-agent orchestration tooling — this is not a niche project.
• Free and MIT-licensed with no per-seat cost. Your bill is your existing agent subscriptions.
• For RPA teams moving into agentic AI: Orca’s orchestration patterns directly mirror the bot-fleet management principles you already know. The paradigm shift is from sequential single-agent work to parallel multi-agent orchestration.
• Watch for: automated agent output evaluation, deeper CI/CD integration, and enterprise governance features as the project matures.

References

1. Stably AI. “Orca — The Agent Development Environment.” onorca.dev. Accessed September 2026.
2. stablyai/orca GitHub Repository. github.com/stablyai/orca. MIT License. Accessed September 2026.
3. Y Combinator. “Stably AI (Orca): We make Orca, MIT open source terminal-based agent orchestrator.” ycombinator.com. Accessed September 2026.
4. AgentConn. “Orca Built an IDE for Agent Fleets. Is the ADE Real?” agentconn.com. 2026.
5. CoddyKit Blog. “Orca: The Open-Source ADE With 43,000+ GitHub Stars That Orchestrates Your AI Coding Agents in Parallel.” coddykit.com. 2026.
6. Yeyupiaoling. “Orca: An ADE Running Five Coding Agents Simultaneously, A New Parallel Orchestration Paradigm.” blog.yeyupiaoling.cn. 2026.
7. McKinsey & Company. Research on AI coding agents’ impact on enterprise software purchasing decisions. Referenced via multiple industry sources, 2026.
8. Gartner. Prediction: 40% of enterprise applications will feature task-specific AI agents by end of 2026. Referenced via Firecrawl.
9. DeepWiki. “stablyai/orca — Architecture and Technical Documentation.” deepwiki.com. 2026.
10. Vibecodinghub. “Orca Review: MIT-licensed agent development environment.” vibecodinghub.org. 2026.

If you build multi-agent systems — or you will in the next 12 months — this is not a branding event. It is a structural shift in how your agents will discover, communicate with, and delegate work to agents built by other teams, other vendors, and other frameworks. This guide breaks down exactly what changed, why it matters for enterprise architectures, and what you should do about it now.

Table of Contents

• What Is the Agentic AI Foundation (AAIF)?
• What A2A Actually Does — And How It Differs from MCP
• The Full AAIF Protocol Stack: Five Layers, One Governance Model
• A2A v1.0 Technical Architecture: Agent Cards, Tasks, and Streaming
• Where A2A Is Already Running in Production
• What This Means for Enterprise Agentic Architectures
• Implications for RPA Teams Moving to Agentic Workflows
• Getting Started: How to Adopt A2A + MCP in Your Stack Today
• FAQs
• Key Takeaways
• References

What Is the Agentic AI Foundation (AAIF)?

The Agentic AI Foundation launched in December 2025 as a Linux Foundation initiative to provide neutral, vendor-independent governance for the infrastructure that powers AI agents in production. Its founding members — Anthropic, OpenAI, and Block — contributed three anchor projects: MCP (the protocol for connecting agents to tools and data), goose (an open-source agent runtime from Block), and AGENTS.md (a specification for communicating instructions and conventions to AI agents).

Within eight months, AAIF grew from fewer than 40 members to over 250. Platinum-tier signatories now include AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI (Linux Foundation Press Release). That breadth is deliberate. When foundational infrastructure protocols are owned by a single vendor, every downstream team absorbs that vendor’s roadmap constraints. When they are governed openly, the community shapes what gets built.

For context, MCP alone had crossed 97 million monthly SDK downloads (Python + TypeScript combined) by February 2026. The protocol that standardizes how your agents connect to databases, APIs, and enterprise services is no longer any single company’s project — it belongs to the ecosystem. And now A2A, the protocol that standardizes how your agents talk to each other, sits in the same governance structure.

What A2A Actually Does — And How It Differs from MCP

The simplest mental model: MCP is vertical, A2A is horizontal.

MCP standardizes the connection between an agent and its tools. When a Claude-based agent needs to query a PostgreSQL database, read a Google Drive file, or call a Salesforce API, MCP defines the protocol for that interaction — discovery, authentication, invocation, and response. It solves the “agent-to-tool” problem. If you’ve built MCP servers for your internal tools, you’ve already used this layer. (For a deeper dive, see our guide to what MCP servers are and how they work.)

A2A solves a different problem: the “agent-to-agent” problem. When a procurement agent built on LangGraph needs to delegate a compliance check to a legal-review agent built on Google ADK, or when a customer-service agent on Salesforce Agentforce needs to route an IT escalation to a ServiceNow agent, A2A defines how those agents discover each other, negotiate capabilities, delegate tasks, and exchange results — regardless of their underlying framework.

AAIF CTO Manik Surtani put it directly: “Where A2A fits is at the collaborative edge; where MCP fits is at the tool integration edge.” Together they form the plumbing for what analysts increasingly call the agentic AI economy (AAIF Blog).

Dimension	MCP (Model Context Protocol)	A2A (Agent2Agent)
Primary function	Agent Tool connectivity	Agent Agent interoperability
Originated by	Anthropic (2024)	Google (April 2025)
Joined AAIF	December 2025 (founding project)	August 2026
Stable spec	2026-07-28 stateless spec	v1.0 (March 2026)
Core abstraction	Tools, resources, prompts	Agent Cards, Tasks, Messages
Discovery mechanism	Server manifests	Agent Cards (signed JSON metadata)
Communication pattern	Request/response (tool invocation)	Task lifecycle (submitted → working → completed) + streaming
Monthly SDK downloads	97M+ (Feb 2026)	Growing rapidly post-v1.0
Typical use case	“My agent needs to read Jira tickets”	“My agent needs to delegate work to your agent”

The critical point: these protocols are complementary, not competing. A well-architected multi-agent system uses MCP for each agent’s tool access and A2A for inter-agent coordination. The AAIF governance model does not merge them — each retains its own technical steering committee — but ensures their roadmaps stay aligned.

The Full AAIF Protocol Stack: Five Layers, One Governance Model

With A2A’s addition, the AAIF now governs a complete five-layer stack for agentic AI infrastructure. Understanding each layer is essential for architects designing production systems.

Layer 1: Instructions and Context — AGENTS.md

AGENTS.md standardizes how projects communicate expectations, conventions, and operating instructions to AI agents. Think of it as the “README for agents” — a structured document that tells an agent what it can and cannot do within a given project, what coding standards to follow, what tools are available, and what guardrails apply. Contributed by OpenAI.

Layer 2: Agent Runtime — goose

Block’s goose provides the environment in which an agent reasons, plans, invokes capabilities, and executes work. It is an open-source agent framework that handles the execution loop — the “engine” that an agent runs on top of.

Layer 3: Agent-to-Tool Connectivity — MCP

Anthropic’s Model Context Protocol standardizes how agents connect to tools, data sources, applications, and services. MCP servers expose capabilities through a uniform interface, and MCP clients (agents) discover and invoke them. The 2026-07-28 stateless spec update made MCP servers truly stateless, removing the requirement for persistent connections and making the protocol viable for serverless and edge deployments.

Layer 4: Traffic Mediation — agentgateway

agentgateway sits at the boundary between agent systems and infrastructure, handling routing, policy enforcement, and observability. It is the operations layer — where you apply rate limiting, access control, audit logging, and traffic shaping to agent communications.

Layer 5: Agent-to-Agent Interoperability — A2A

A2A standardizes how independent agents discover one another, communicate, delegate tasks, and exchange results across systems and organizational boundaries. This is the newest addition and the layer that makes true multi-vendor, multi-framework agent ecosystems possible.

Every major cloud provider and AI lab is a governance participant. This is not a Google stack or an Anthropic stack — it is the industry stack. For architects, this means you can design multi-agent systems against these protocols with reasonable confidence that they won’t be deprecated, forked, or locked behind a single vendor’s paywall.

A2A v1.0 Technical Architecture: Agent Cards, Tasks, and Streaming

A2A v1.0 shipped in March 2026 with several critical capabilities that make it production-ready. Here’s what you need to understand as an implementer.

Agent Cards: Discovery and Identity

Every A2A-capable agent publishes an Agent Card — a JSON metadata document describing its identity, capabilities, skills, service endpoint, and authentication requirements. Agent Cards are the discovery mechanism: other agents read your card to understand what you can do and how to reach you (A2A v1.0 Specification).

The v1.0 spec added signed Agent Cards with cryptographic identity verification. Clients verify the signatures field against the issuer’s public key (typically held in a curated registry or x5c chain) before trusting the card. This is not optional for enterprise deployments — unsigned agent cards in a multi-vendor system are the equivalent of unsigned API endpoints.

// Simplified Agent Card structure
{
  "@context": "https://a2a-protocol.org/v1.0",
  "name": "compliance-review-agent",
  "description": "Reviews procurement requests against regulatory requirements",
  "url": "https://agents.example.com/compliance",
  "version": "1.0.0",
  "skills": [
    {
      "id": "regulatory-check",
      "name": "Regulatory Compliance Check",
      "description": "Evaluates a procurement request against applicable regulations",
      "inputModes": ["text", "application/json"],
      "outputModes": ["application/json"]
    }
  ],
  "authentication": {
    "schemes": ["oauth2"],
    "credentials": "https://auth.example.com/.well-known/oauth-authorization-server"
  },
  "signatures": { }
}

Task Lifecycle: The State Machine

Every interaction in A2A revolves around a strict task state machine. When an agent receives a SendMessage call, it either returns a Message directly (for trivial responses) or instantiates a Task and transitions it through defined states:

submitted → working → input-required → completed | canceled | failed

This is fundamentally different from simple request/response patterns. The input-required state is particularly important — it allows agents to negotiate, ask clarifying questions, or request additional context mid-task. A compliance agent reviewing a procurement request can pause in input-required, ask the requesting agent for additional documentation, receive it, and then continue to completed. This models how humans actually collaborate — with back-and-forth — rather than the fire-and-forget pattern of most API integrations.

Streaming Architecture

For long-running tasks, A2A supports streaming via Server-Sent Events (SSE). Clients call SendStreamingMessage (to submit and stream in one step) or SubscribeToTask (to attach to an existing task). The server responds with Content-Type: text/event-stream and pushes TaskStatusUpdateEvent and TaskArtifactUpdateEvent objects until the task reaches a terminal state.

This means your orchestrating agent doesn’t need to poll. It opens a stream, processes status updates and partial results as they arrive, and can display progress to end users in real time.

Multi-Tenancy and Version Negotiation

The v1.0 spec added two enterprise-critical capabilities. Multi-tenancy allows a single A2A server to serve multiple tenants with isolated task namespaces. Version negotiation allows agents running different spec versions to discover the highest mutually supported version and communicate at that level — essential for organizations rolling out upgrades across a fleet of agents at different cadences.

Where A2A Is Already Running in Production

A2A is not a whitepaper protocol. As of mid-2026, it is running in production across mobile platforms, cloud infrastructure, financial services, and supply chain logistics. Here are the most significant deployments (Linux Foundation Press Release, April 2026).

Huawei HarmonyOS: Mobile-Scale Agent Orchestration

Huawei standardized A2A as the protocol between Celia (its OS-level AI assistant) and in-app agents across the HarmonyOS developer platform. Supported scenarios include Celia delegating long-running tasks to app agents, Celia controlling app UI through an agent, and Celia requesting contextual recommendations from application agents. This is agent-to-agent communication operating at mobile operating system scale — billions of potential interactions daily.

Tencent’s WeChat is among the first major apps integrating with Huawei and other Android OEM assistants over A2A, enabling messages, voice calls, and video calls initiated through an AI assistant. The flow runs with dual authorization through the A2A protocol.

PayPal: Agentic Commerce

PayPal deployed A2A in production for merchant-facing workflows. A sales agent receives a natural-language request, uses A2A to locate and authenticate a PayPal-provided payment agent via its Agent Card, and initiates a transaction. Google Cloud and PayPal are extending this into the Agent Payments Protocol (AP2), where shopping and merchant agents communicate over A2A throughout product discovery, pricing, and order fulfillment, with AP2 handling the payment authorization layer. Over 60 organizations across payments and financial services already support this initiative.

Cloud Platform Native Integration

Every major cloud platform now supports A2A natively:

• Google Cloud: Supports developing and deploying A2A agents through Agent Development Kit (ADK), Agent Engine, Cloud Run, and GKE. If you’ve been building multi-agent systems with Google ADK, A2A support is already built into the framework.
• Microsoft Azure: Azure AI Foundry lets agents expose A2A endpoints and discover external agents through standard discovery. This integrates directly with Copilot Studio’s multi-agent orchestration capabilities.
• AWS: Amazon Bedrock AgentCore can host and operate A2A servers, enabling cross-framework and cross-cloud agent communication.

Enterprise IT: Cross-Vendor Agent Collaboration

A Salesforce CRM agent can route a support escalation to a ServiceNow ITSM agent. A Google Workspace agent can delegate document summarization to a specialized LLM agent on Azure. These aren’t theoretical scenarios — they are the explicit design targets of the protocol and the reason companies like Salesforce, SAP, ServiceNow, and Workday are all supporters.

What This Means for Enterprise Agentic Architectures

The consolidation of A2A and MCP under one governance body has several concrete implications for architects designing production agent systems.

1. The End of Custom Integration Code Between Agents

Before A2A, connecting agents built on different frameworks required custom integration code for every pairing. A LangGraph agent talking to a Google ADK agent needed bespoke glue. A UiPath process invoking a Bedrock agent needed a custom connector. With A2A, any agent that publishes an Agent Card and implements the task lifecycle can communicate with any other A2A-compatible agent. The cost isn’t in the agents — it’s in eliminating the O(n²) integration matrix.

2. Protocol Vendor Lock-in Risk Drops Dramatically

When MCP was Anthropic’s project and A2A was Google’s project, architects legitimately worried about betting on one vendor’s protocol. With both under AAIF governance — and with every major cloud provider and AI lab signed on — the risk profile changes fundamentally. These are now industry standards with the same governance model that governs Linux, Kubernetes, and other foundational infrastructure. As our guide to enterprise agent governance explores, governance is the hardest problem in agent deployments — and having protocol governance settled at the industry level removes one category of that risk entirely.

3. The Agent Card Becomes Your Agent’s Resume

Agent Cards are not just a technical artifact. They are the mechanism by which your agents advertise their capabilities in a marketplace of agents. Organizations that invest in clear, well-structured Agent Cards — with precise skill descriptions, proper authentication, and cryptographic signatures — will find their agents get discovered and delegated to. Those that don’t will build agents that sit in isolation.

4. Multi-Cloud Agent Architectures Become First-Class

With AWS, Azure, and Google Cloud all supporting A2A natively, you can now design architectures where agents on different clouds collaborate seamlessly. A fraud-detection agent on AWS Bedrock can delegate to a customer-history agent on Azure AI Foundry, which can invoke a risk-scoring agent on Google Cloud’s Agent Engine — all through standardized A2A communication. This is a concrete answer to the multi-cloud agent challenge that enterprises have been asking about.

5. IBM’s ACP Merger Validates the Convergence

In August 2025, IBM’s Agent Communication Protocol (ACP) merged into A2A. This was an early signal that the industry was consolidating around A2A rather than sustaining competing protocols. IBM — the company behind watsonx Orchestrate’s agentic control plane — decided to contribute its protocol work into A2A rather than maintain a separate standard. When a company with IBM’s enterprise footprint makes that call, it tells you where the industry consensus landed.

Implications for RPA Teams Moving to Agentic Workflows

If your team currently runs UiPath, Automation Anywhere, Blue Prism, or Power Automate automations, the A2A + MCP stack has direct implications for your transition path to agentic workflows.

RPA Processes as A2A-Accessible Agents

The A2A protocol makes it possible to wrap existing RPA processes as agent-accessible services. An RPA bot that processes invoices in SAP can be exposed via an Agent Card, making it discoverable and callable by any A2A-compatible agent. The bot doesn’t need to be rebuilt — it needs a wrapper that publishes its capabilities and implements the task lifecycle.

This is significant because it provides a migration path that doesn’t require rip-and-replace. Your existing RPA investments become nodes in a broader agentic network. The latest comparison of UiPath, Automation Anywhere, and Blue Prism’s agentic capabilities shows that all three vendors are moving toward agent-oriented architectures — A2A gives them a standard protocol to target.

MCP for Tool Access, A2A for Process Orchestration

Here’s a practical architecture pattern for RPA-to-agentic migration:

• MCP servers wrap your existing integrations: SAP connections, database queries, file system operations, email interactions. Each becomes a standard MCP tool that any agent can discover and invoke.
• A2A handles the orchestration layer: a customer-onboarding agent delegates KYC checks to a compliance agent, which delegates document extraction to an IDP agent, which delegates data entry to an RPA-wrapped SAP agent.

This pattern preserves your existing automation logic (the RPA bots doing the actual work) while adding an intelligent orchestration layer on top. It is a practical answer to the question every RPA team is asking: “How do we get to agentic without throwing away what we’ve built?”

The Governance Question

Enterprise RPA programs already have governance frameworks — change management, access control, audit trails, error handling. The A2A protocol maps cleanly to these requirements. Agent Cards include authentication requirements. The task lifecycle provides auditable state transitions. The enterprise agent deployment considerations we’ve covered previously apply directly — A2A doesn’t replace your governance; it gives it a standard protocol to enforce against.

Getting Started: How to Adopt A2A + MCP in Your Stack Today

Here’s a practical roadmap for teams that want to start building with both protocols.

Step 1: Start with MCP (If You Haven’t Already)

MCP has a larger ecosystem and more immediate utility for most teams. Wrap your most-used internal tools as MCP servers. The Python and TypeScript SDKs are mature, and most agent frameworks (LangGraph, Google ADK, Claude, Bedrock Agents) support MCP natively. Start with your database, your CRM, and your document store.

Step 2: Design Your Agent Card

Before you implement A2A, design the Agent Card for your most valuable agent. What skills does it expose? What input/output modes does it support? What authentication is required? This exercise forces you to think about your agent’s external interface — which is often underdefined in internal agent projects.

Step 3: Choose Your A2A SDK

Google provides official SDKs for Python, TypeScript/JavaScript, Java, and Go. The SDKs handle the task lifecycle, streaming, and Agent Card serving. If you’re on Google ADK, A2A support is built in. If you’re on LangGraph or another framework, use the standalone SDK.

# Python: Minimal A2A server using the official SDK
from a2a.server import A2AServer, AgentCard, Skill

card = AgentCard(
    name="invoice-processor",
    description="Processes and validates supplier invoices",
    url="https://agents.internal.example.com/invoice",
    skills=[
        Skill(
            id="validate-invoice",
            name="Invoice Validation",
            description="Validates invoice against PO and contract terms",
            input_modes=["application/json"],
            output_modes=["application/json"]
        )
    ]
)

server = A2AServer(card=card)

@server.on_message
async def handle(message, context):
    # Your agent logic here
    invoice_data = message.content
    result = await validate_against_po(invoice_data)
    return context.complete(result)

server.run(port=8080)

Step 4: Test Cross-Framework Communication

The value of A2A appears when agents on different frameworks need to collaborate. Build a simple two-agent system where Agent A (on one framework) delegates a task to Agent B (on another) via A2A. Verify the full lifecycle: discovery via Agent Card, task submission, status updates, and result retrieval. This is your proof of concept for multi-vendor agent architectures.

Step 5: Layer in agentgateway for Operations

Once you have agents communicating via A2A, add AAIF’s agentgateway for routing, policy enforcement, and observability. This is where you apply rate limiting, access control, and audit logging — the operations layer that makes agent communication production-ready.

Frequently Asked Questions

Does A2A replace MCP?

No. They solve different problems and are designed to work together. MCP handles agent-to-tool connectivity (your agent querying a database or calling an API). A2A handles agent-to-agent communication (your agent delegating work to another agent). A production system typically uses both — MCP for each agent’s tool access and A2A for inter-agent orchestration.

Do I need to switch agent frameworks to use A2A?

No. A2A is framework-agnostic by design. An agent built on LangGraph can communicate with an agent built on Google ADK, Claude, or a custom framework. You add A2A support to your existing agent — you don’t rebuild the agent. The official SDKs (Python, TypeScript, Java, Go) handle the protocol layer.

Is A2A ready for production use?

Yes. A2A v1.0 shipped in March 2026 with signed Agent Cards, multi-tenancy, and version negotiation. It is running in production at Huawei (mobile OS scale), PayPal (agentic commerce), and across AWS, Azure, and Google Cloud. Over 150 organizations are active supporters.

How does A2A handle security and authentication?

Agent Cards include authentication requirements (OAuth 2.0, API keys, or custom schemes). The v1.0 spec added cryptographic signatures for Agent Cards, so clients can verify an agent’s identity before trusting its card. The task lifecycle is fully auditable, with each state transition logged.

Can existing RPA processes be exposed via A2A?

Yes. An RPA process can be wrapped with an A2A server that publishes an Agent Card describing the process’s capabilities and implements the task lifecycle. The RPA bot continues to execute the actual work — A2A provides the discovery and communication layer that makes it accessible to other agents.

Key Takeaways

• A2A + MCP under one roof is a structural shift. The two most critical agent protocol layers — tool connectivity (MCP) and inter-agent communication (A2A) — are now governed by the same Linux Foundation body with 250+ members including every major cloud provider and AI lab.
• MCP is vertical, A2A is horizontal. Use MCP to connect agents to tools and data. Use A2A to connect agents to other agents. Both are complementary and both are needed for production multi-agent systems.
• A2A is already in production. Huawei (mobile OS), PayPal (commerce), and all three major cloud platforms run A2A today. This is not vaporware.
• RPA teams have a migration path. Existing RPA processes can be wrapped as A2A-accessible agents without rebuilding them, preserving automation investments while adding intelligent orchestration.
• Agent Cards are your agent’s external interface. Invest in clear, well-structured Agent Cards with proper authentication and signatures. They determine whether your agents get discovered and trusted in multi-vendor ecosystems.
• Start with MCP, add A2A when you need multi-agent. For most teams, wrapping internal tools as MCP servers delivers immediate value. Layer A2A when you need agents to delegate work across framework or vendor boundaries.

References

1. Agentic AI Foundation. “A2A joins AAIF’s open agentic stack.” August 17, 2026. https://aaif.io/blog/a2a-joins-aaif
2. Forbes. “Agent2Agent Joins The Agentic AI Foundation Alongside MCP.” August 19, 2026. https://www.forbes.com/sites/janakirammsv/2026/08/19/
3. Axios. “AI agents inch toward interoperability.” August 17, 2026. https://www.axios.com/2026/08/17/
4. Linux Foundation. “A2A Protocol Surpasses 150 Organizations.” April 2026. https://www.linuxfoundation.org/press/
5. Linux Foundation. “Announces the Formation of the Agentic AI Foundation (AAIF).” December 2025. https://www.linuxfoundation.org/press/
6. A2A Protocol. “v1.0 Specification.” March 2026. https://a2a-protocol.org/latest/specification/
7. AI Magazine. “Why Did Google’s A2A Join the Agentic AI Foundation?” August 2026. https://aimagazine.com/news/
8. Tyk. “A2A protocol: Architecture and technical specification.” 2026. https://tyk.io/learning-center/
9. Pebblous. “A2A Joins MCP at the Agentic AI Foundation.” 2026. https://blog.pebblous.ai/blog/
10. Zylos Research. “Agent Interoperability Protocols 2026: MCP, A2A, ACP and the Path to Convergence.” March 2026. https://zylos.ai/research/

Microsoft’s answer is a vertically integrated agentic AI stack that shipped across the first half of 2026: Microsoft Agent Framework 1.0 (the open-source SDK that merged AutoGen and Semantic Kernel into one production-grade runtime), Foundry Agent Service (the managed cloud runtime with session-isolated sandboxes and zero-idle-cost autoscaling), Foundry IQ (a knowledge layer that replaces hand-built RAG pipelines with 54% better recall), and Toolboxes in Foundry (a single MCP-compliant endpoint for every tool an agent needs). Together with Copilot Studio’s multi-agent orchestration reaching general availability in August 2026, Microsoft now offers the most complete build-deploy-operate platform for agentic AI in the enterprise market.

This guide walks through the entire stack — architecture, orchestration patterns, production deployment, observability, and certification — so you can evaluate whether it fits your automation roadmap and start building if it does.

Why Microsoft Merged AutoGen and Semantic Kernel

Until early 2026, Microsoft maintained two separate agent frameworks with overlapping ambitions. Semantic Kernel, born inside the Microsoft 365 Copilot team, provided enterprise-grade plumbing: type-safe connectors, telemetry, filters, and a deep plugin ecosystem. AutoGen, a Microsoft Research project, pioneered multi-agent orchestration patterns — group chat, handoff, and the Magentic-One system for open-ended collaborative problem-solving. Developers building production agents frequently needed both, stitching them together with glue code that neither team officially supported.

On April 3, 2026, Microsoft shipped Microsoft Agent Framework 1.0 for both .NET and Python. The release unified Semantic Kernel’s enterprise foundations — session-based state, type safety, middleware pipeline, full connector ecosystem — with AutoGen’s multi-agent orchestration, under a single Microsoft.Agents.AI namespace. This wasn’t a rename. The internal architecture was refactored so that Semantic Kernel serves as the foundation layer, with AutoGen’s graph-based multi-agent orchestration built on top.

The practical consequence for teams already invested in either framework: existing Semantic Kernel plugins and connectors carry forward directly. AutoGen orchestration patterns (sequential, concurrent, handoff, group chat, Magentic-One) are now stable and supported under the same API. You no longer need to choose between enterprise plumbing and multi-agent flexibility — they ship as one package.

Architecture: What Ships in Agent Framework 1.0

Agent Framework 1.0 is organized around five core abstractions that mirror how production agents actually operate:

Multi-Model, Multi-Protocol by Default

Agent Framework 1.0 ships with first-party connectors for six model providers — Azure OpenAI, OpenAI, Anthropic Claude, Amazon Bedrock, Google Gemini, and Ollama — swappable with a single configuration line. This isn’t just about model flexibility; it’s about cost optimization. A production agent might use GPT-4.1 for complex reasoning steps, Claude Haiku for classification, and a local Ollama model for PII detection — all within the same workflow, all managed by the same harness.

Two interoperability protocols are native at 1.0, not bolt-on additions:

• Model Context Protocol (MCP) — agents dynamically discover and invoke external tools exposed over MCP-compliant servers. If you’ve already built MCP servers for your organization’s tools, Agent Framework connects to them without wrapper code.
• Agent-to-Agent (A2A) — agents register as each other’s tools, enabling cross-framework and cross-organization collaboration. A LangGraph agent running on AWS can invoke a Microsoft Agent Framework agent running on Azure via A2A, and vice versa, through natural language delegation.

Procedural Memory: Agents That Learn How to Work

The most architecturally significant addition in 1.0 is procedural memory (public preview). User memory remembers facts (“this user prefers metric units”). Session memory maintains conversation context. Procedural memory is different: it captures how the agent performed a task and applies that learned procedure to future runs. Microsoft’s Tau-bench evaluations show +7–14% absolute success-rate gains at near-baseline cost when procedural memory is enabled.

The practical scenario: a PR-review agent is coached once — “check test coverage first, then flag new dependencies, then look for breaking API changes.” Weeks later, on an entirely different pull request, the agent runs the same sequence autonomously. This is closer to how human experts actually develop work patterns, and it’s a meaningful step beyond the stateless agent architectures that dominate most frameworks today. For teams building agents that handle memory and retrieval-augmented generation, procedural memory adds a third dimension beyond what RAG alone provides.

Multi-Agent Orchestration: Five Patterns, One API

Agent Framework 1.0 ships five stable orchestration patterns. Each supports streaming, checkpointing, human-in-the-loop approvals, and pause/resume for long-running workflows. Choosing the right pattern is the most consequential architectural decision you’ll make — it determines latency, cost, and failure modes.

Magentic-One deserves special attention. Developed by Microsoft Research as part of the AutoGen project, it reached stable release in Agent Framework 1.0. Unlike the other four patterns, Magentic-One doesn’t follow a fixed flow. The manager agent maintains a ledger of what each specialist can do, what’s been tried, and what failed, then dynamically reassigns work. This makes it the right choice for tasks where you genuinely don’t know the optimal sequence upfront — complex document processing, multi-system investigations, or research tasks that require pivoting strategies mid-execution.

Foundry Agent Service: The Production Runtime

Agent Framework gives you the SDK. Foundry Agent Service gives you the runtime. It’s the managed cloud environment where your agents actually execute in production, reaching general availability in mid-2026.

Session-Isolated Sandboxes

Every agent session runs in its own sandbox with dedicated compute, memory, and filesystem. This isn’t container-level isolation — it’s session-level, meaning two concurrent users of the same agent get completely separate execution environments. The runtime handles autoscaling with zero idle cost: when no sessions are active, you’re not paying for dormant infrastructure.

Framework-Agnostic Deployment

Foundry Agent Service doesn’t lock you into Microsoft Agent Framework. Agents built with LangGraph, GitHub Copilot SDK, Claude Agent SDK, or any other framework can be deployed without rewrites. Two protocols are supported: the Responses API for OpenAI-compatible stateful interactions, and the Invocations protocol for schema-free pass-through scenarios where you control the request/response format entirely.

This matters for organizations running heterogeneous agent stacks. Your legacy LangChain agents, your new Microsoft Agent Framework agents, and your experimental Claude Agent SDK prototypes can all run on the same managed runtime — unified observability, unified billing, unified governance.

Long-Running Agents and Routines

Most agent runtimes assume a request-response lifecycle. Foundry Agent Service also supports long-running autonomous agents with durable state and filesystem access, plus routines (public preview) — agents that run on a timer or a schedule. The canonical example: an agent monitors a GitHub repository overnight, triages new issues by morning, and posts a summary to Microsoft Teams before standup. This is the kind of always-on automation that bridges traditional RPA scheduling with agentic intelligence.

Autopilot Agents: Agents With Identity

Perhaps the most forward-looking feature: autopilot agents (public preview) act independently with their own Entra ID, email address, Teams presence, and place in the organizational chart. They can initiate conversations, work on shared files, follow up on action items, and collaborate with humans over time. Every action is attributable, auditable, and governed through Agent 365 in Microsoft Admin Center.

For RPA teams, this is conceptually equivalent to an unattended robot in UiPath or Automation Anywhere — but operating at the knowledge-worker layer rather than the UI-automation layer. The agent doesn’t click buttons; it reads documents, sends emails, updates project plans, and joins meetings. If your automation roadmap includes evaluating how classic RPA platforms compare to agentic approaches, autopilot agents represent the opposite end of the spectrum from screen-scraping bots.

Foundry IQ: Replacing DIY RAG Pipelines

Foundry IQ (generally available) replaces the chunking-indexing-retrieval pipeline that every RAG implementation forces you to build from scratch. It turns Azure AI Search into an agentic retrieval engine that plans multi-step queries, reasons across knowledge bases, and enforces enterprise-grade security at the retrieval layer — not as an afterthought.

The architecture unifies five knowledge source types behind one SLA-backed retrieval endpoint:

Microsoft’s benchmarks show that combining a smaller agent model with agentic retrieval through Foundry IQ improves evidence recall by up to 54% compared to traditional RAG, while controlling costs and increasing agent responsiveness. The “agentic retrieval” distinction is important: instead of a single vector-similarity search, Foundry IQ plans multi-step retrieval strategies — decomposing complex questions, querying different knowledge bases for different sub-questions, and synthesizing results before returning them to the agent.

For teams already managing RAG architectures, Foundry IQ offers a path to significantly reduce custom plumbing. The tradeoff is platform commitment — Foundry IQ is deeply integrated with Azure infrastructure, and migrating away later means rebuilding the retrieval layer.

Toolboxes in Foundry: One Endpoint for Every Tool

The integration tax is real. Each tool an agent needs — an API, a database connector, a document processor — brings its own authentication flow, protocol, and lifecycle. Toolboxes in Foundry (public preview) consolidates this: configure your tools once, point any MCP client at one URL, and let Foundry handle auth, lifecycle, and governance.

Three capabilities stand out:

Skills as first-class resources: Skills are versioned in a project-scoped catalog and discoverable as MCP resources by any agent in the project. This means your “check-credit-score” skill or your “query-SAP-inventory” skill is registered once and available to every agent in the organization, with version control and access policies.

Tool search: Instead of surfacing every available tool to the model (which wastes tokens and invites hallucinated tool calls), tool search intelligently selects the right tools for each specific task. Early adopters report significant reductions in unnecessary tool invocations.

Microsoft IQ integrations: Toolbox connects directly to Work IQ, Fabric IQ (with Fabric data agents, ontology, and semantic models), and Foundry IQ — so agents tap enterprise data without custom plumbing between the tool layer and the knowledge layer.

Observability and Optimization: The Operate Layer

Most agent platforms stop at deployment. Microsoft’s strongest differentiator may be the operate layer — the closed-loop system that turns production failures into ranked improvements.

End-to-End Tracing

Tracing and evaluation for hosted agents (GA as of June 2026) pipes every model call, tool invocation, sub-agent hop, and handoff through a single OpenTelemetry pipeline. Evaluations link directly back to the trace that produced them in the Foundry Control Plane. When a regression surfaces, you move from the score to the exact production trace that caused it — not a separate dashboard, not a log file, the actual trace.

For teams coming from UiPath’s Orchestrator-centric monitoring or IBM watsonx’s control plane approach, Microsoft’s tracing is notable for being standards-based (OpenTelemetry) rather than proprietary.

Agent Optimizer: A Closed Improvement Loop

Agent optimizer (public preview, rolling out mid-2026) replaces the manual guess-and-check cycle of agent improvement with an evidence-backed loop:

1. Observe — consume production traces and evaluation scores from hosted agents
2. Evaluate — score every run against your defined rubric (task success, tone, safety, cost, latency)
3. Optimize — generate ranked candidate improvements across prompts and skills, validate each against your scenarios
4. Deploy — promote the winner with full lineage, diffs, audit trail, and rollback capability

Three components feed into this loop:

• ASSERT generates adversarial tests from your policies, surfacing where the agent fails before users do
• Agent Control Specification turns those risks into enforceable runtime guardrails across input, model, state, tool execution, and output
• Rubric (public preview) defines what “good” looks like with weighted evaluation criteria, scoring every run against them

This is the kind of continuous-improvement infrastructure that enterprise automation teams are used to from process mining tools (Celonis, UiPath Process Mining) — but applied to agent behavior rather than business processes.

Distribution: From Code to Microsoft 365 in One Step

Publishing agents to Microsoft Teams and Microsoft 365 Copilot is generally available. Any Foundry agent deploys directly into the apps employees already use, with identity, permissions, and policy flowing through automatically.

Three agent modes are now supported for distribution:

For organizations already using Copilot Studio’s rebuilt agent platform, Foundry Agent Service agents and Copilot Studio agents can now interoperate through A2A and MCP — Copilot Studio handles the low-code, business-user-facing orchestration, while Foundry Agent Service handles the developer-built, production-grade agents that require custom code and framework-level control.

How Microsoft’s Stack Compares to Competitors

Every major cloud provider now offers an agentic AI platform. Here’s how Microsoft’s stack compares at a glance:

Microsoft’s strongest differentiators are the M365 distribution path (no other vendor can deploy agents directly into Teams, Outlook, and Copilot), the agent optimizer closed loop (no competitor has an equivalent automated improvement cycle), and the breadth of orchestration patterns (five stable patterns vs. most competitors offering one or two). The tradeoff is ecosystem commitment — the deeper you integrate with Foundry IQ, Toolboxes, and M365 distribution, the harder it becomes to migrate to another cloud provider’s agent platform.

Getting Started: Your First Production Agent

The fastest path from zero to a production-deployed agent follows this sequence:

Step 1: Choose your runtime. .NET or Python — same concepts, same API surface, first-class support on both. Pick based on your team’s existing skills and the rest of your stack.

Step 2: Set up the development environment. Install Foundry Toolkit for VS Code (GA). This gives you agent templates, local testing with full trace visualization, step-by-step debugging, Toolbox connectivity, and one-click deployment to Foundry Agent Service — all without leaving the editor.

Step 3: Build with the Quickstart. Follow Microsoft’s hosted agent quickstart, which walks through creating, testing, and deploying a production-ready hosted agent end to end. The Azure Developer CLI handles provisioning, identity, and admin approval in a single workflow.

Step 4: Choose your orchestration pattern. Start with sequential for predictable pipelines or handoff for routing scenarios. Graduate to Magentic-One only when your task genuinely requires adaptive, dynamic collaboration — the orchestration overhead isn’t justified for simple workflows.

Step 5: Connect knowledge and tools. Wire up Foundry IQ for knowledge grounding and Toolboxes for tool access. Start with one knowledge source and one or two tools, then expand as you validate the agent’s behavior.

Step 6: Deploy and monitor. Deploy to Foundry Agent Service, enable tracing, and define your evaluation rubric. Let the agent optimizer suggest improvements based on real production traces.

The Agentic Business Solutions Certification Path

Microsoft’s partner ecosystem is restructuring around agentic AI. The Low Code Application Development and Intelligent Automation specializations have merged into a new Agentic Business Solutions specialization as of August 2026. Two new certifications anchor this path:

• AB-100: Agentic AI Business Solutions Architect — covers end-to-end solution design across Agent Framework, Foundry Agent Service, Copilot Studio, and Power Platform
• AB-620: AI Agent Builder Associate — covers hands-on agent development with Agent Framework, MCP/A2A integration, and Foundry deployment

For partners, achieving the specialization requires demonstrating real customer deployments: at least two customers, including one using Power Automate with a production flow and one using a Power Apps application with minimum five production users (Pathway One), or two Copilot Studio deployments with minimum $10,000 TTM each (Pathway Two). Customer references have been replaced with a third-party capabilities audit that requires real customer examples, valid for two years.

This certification restructuring signals where Microsoft expects enterprise agent budgets to flow. If you’re an automation professional considering the transition from classic RPA to agentic AI, the AB-100 and AB-620 certifications are the clearest investment in Microsoft-ecosystem skills.

Frequently Asked Questions

Is Microsoft Agent Framework the same as Semantic Kernel?

No, but it includes Semantic Kernel. Agent Framework 1.0 merged Semantic Kernel (enterprise plumbing: connectors, telemetry, filters) with AutoGen (multi-agent orchestration) into a single SDK. Existing Semantic Kernel plugins and connectors carry forward directly — you’re upgrading, not replacing.

Can I use Agent Framework with non-Microsoft models like Claude or Gemini?

Yes. Agent Framework 1.0 ships first-party connectors for Azure OpenAI, OpenAI, Anthropic Claude, Amazon Bedrock, Google Gemini, and Ollama. Model providers are swappable with a one-line configuration change.

How does Foundry Agent Service compare to running agents on my own Kubernetes cluster?

Foundry Agent Service provides session-level isolation (not just container-level), automatic memory management, built-in tracing via OpenTelemetry, and zero-idle-cost autoscaling out of the box. On self-managed Kubernetes, you’d build all of these yourself. The tradeoff is control vs. operational overhead — Foundry handles the infrastructure, but you’re committed to Azure as your runtime.

Does Agent Framework support human-in-the-loop approvals?

Yes. All five orchestration patterns — sequential, concurrent, handoff, group chat, and Magentic-One — support human-in-the-loop approvals, pause/resume for long-running workflows, and checkpointing for recovery.

What’s the difference between Copilot Studio agents and Foundry Agent Service agents?

Copilot Studio is the low-code, business-user-facing agent builder with a visual Workflow Designer. Foundry Agent Service is the developer-built, code-first runtime for agents that need custom orchestration, framework-level control, and production-grade infrastructure. They interoperate via A2A and MCP — Copilot Studio agents can invoke Foundry agents as tools, and vice versa.

Key Takeaways

• Agent Framework 1.0 unifies AutoGen + Semantic Kernel into one open-source SDK for .NET and Python, with stable multi-agent orchestration and MCP/A2A native at 1.0.
• Five orchestration patterns — sequential, concurrent, handoff, group chat, and Magentic-One — cover everything from simple pipelines to complex open-ended tasks.
• Foundry Agent Service provides the production runtime with session-isolated sandboxes, zero-idle-cost autoscaling, and framework-agnostic deployment.
• Foundry IQ replaces DIY RAG pipelines with agentic retrieval that improves recall by up to 54%, unifying five knowledge source types behind one endpoint.
• Autopilot agents get their own Entra identity, email, Teams presence, and org-chart position — the knowledge-worker equivalent of an unattended RPA robot.
• Agent optimizer closes the observe-evaluate-optimize-deploy loop automatically, replacing manual prompt tweaking with evidence-backed improvements.
• M365 distribution is the unique Microsoft advantage — no other cloud vendor can deploy agents directly into Teams, Outlook, and Copilot.
• New certifications (AB-100 Architect, AB-620 Builder) and the Agentic Business Solutions specialization mark where Microsoft expects the partner ecosystem to invest.

References

1. Microsoft Foundry Blog, “Build and run agents at scale with Microsoft Foundry at Build 2026” (June 2, 2026) — devblogs.microsoft.com
2. Microsoft Agent Framework Blog, “Microsoft Agent Framework Version 1.0” (April 3, 2026) — devblogs.microsoft.com
3. Microsoft Agent Framework Blog, “Agent Framework’s Orchestration Patterns Reach 1.0” (2026) — devblogs.microsoft.com
4. InfoQ, “Microsoft Foundry Adds Runtime, Tooling, and Governance for Production Agents” (June 2026) — infoq.com
5. Microsoft Azure Blog, “Introducing Microsoft Agent Framework” (2026) — azure.microsoft.com
6. Microsoft Foundry Blog, “Foundry IQ: Build smarter agents faster with unified knowledge and serverless retrieval” (2026) — devblogs.microsoft.com
7. itnext.io, “From Classic RAG to Agentic Retrieval: Inside Microsoft’s Foundry IQ Architecture” (2026) — itnext.io
8. Microsoft Tech Community, “Foundry IQ: Improve recall by up to 54% with knowledge bases” (2026) — techcommunity.microsoft.com
9. HubSite365, “Copilot Studio: Autonomous Agent Flows — August 2026 Updates” (August 2026) — hubsite365.com
10. Microsoft Learn, “Agentic AI Business Solutions Architect Certification” (August 2026) — learn.microsoft.com

If you’ve spent any time wiring up agentic systems with LangGraph, CrewAI, or AG2, you know the pain: tools configured here, system prompts threaded there, retry logic bolted on somewhere else, guardrails in yet another layer. Pydantic AI v2 collapses all of that into one concept. And because it’s built by the team behind Pydantic — the validation library that underpins FastAPI and virtually every serious Python ML pipeline — the type safety isn’t aspirational. It’s enforced.

This guide walks you through everything an Agentic AI Architect needs to know: what capabilities actually are, how the architecture works, how they compare to extension mechanisms in competing frameworks, and how to build production agents with them. We’ll use real code throughout, sourced directly from the official documentation.

Table of Contents

• What Are Capabilities and Why Do They Matter?
• The Architecture: How Capabilities Compose
• Built-in Capabilities Reference
• Provider-Adaptive Tools: One API, Every Model
• The Pydantic AI Harness: Batteries Sold Separately
• Agent Specs: Declarative Agents in YAML/JSON
• Code Mode: The Capability That Changes Everything
• On-Demand Loading: Keep Your Prompt Lean
• Building Custom Capabilities
• How Pydantic AI v2 Compares to LangGraph, CrewAI, and AG2
• Migrating from v1 to v2
• Production Patterns and Best Practices
• FAQs
• Key Takeaways
• References

What Are Capabilities and Why Do They Matter?

Before v2, building a Pydantic AI agent meant threading configuration through multiple constructor arguments: instructions here, model_settings there, a toolset somewhere else, a history_processor on yet another parameter. Each concern lived in its own argument, and composing multiple extensions — say, a memory system and a guardrail and instrumentation — meant carefully interleaving parameters that didn’t know about each other.

A capability solves this by bundling related behavior into a single, self-contained unit. According to the official documentation, a capability can provide any combination of:

• Tools — via toolsets or native tools
• Lifecycle hooks — intercept and modify model requests, tool calls, and the overall run
• Instructions — static or dynamic instruction additions
• Model settings — static or per-step model configuration
• Models — static or adaptive model selection

This makes the capability the primary extension point for the entire framework. Whether you’re building a memory system, a cost tracker, a guardrail, an approval workflow, or an MCP integration, it goes through this single abstraction.

Here’s what a minimal agent with capabilities looks like in practice:

from pydantic_ai import Agent
from pydantic_ai.capabilities import Thinking, WebSearch

agent = Agent(
    'anthropic:claude-opus-4-6',
    instructions='You are a research assistant. Be thorough and cite sources.',
    capabilities=[
        Thinking(effort='high'),
        WebSearch(local='duckduckgo'),
    ],
)

Two lines in the capabilities list give this agent extended thinking and web search — behavior that in other frameworks would require separate configuration files, middleware chains, or monkey-patched tool registries.

The Architecture: How Capabilities Compose

The design philosophy behind capabilities mirrors what made Pydantic itself successful: explicit over implicit, composable over monolithic, type-safe over stringly-typed.

Capabilities compose through a flat list on the Agent constructor. There’s no inheritance hierarchy to navigate, no middleware pipeline ordering to debug. Each capability operates independently, and the framework merges their contributions:

from pydantic_ai import Agent
from pydantic_ai.capabilities import Capability, Thinking, ToolSearch, WebSearch
from pydantic_ai.mcp import MCPToolset
from pydantic_ai_harness import CodeMode

agent = Agent(
    'anthropic:claude-opus-4-7',
    instructions='Research thoroughly and cite your sources.',
    capabilities=[
        Thinking(effort='high'),
        CodeMode(),
        WebSearch(),
        ToolSearch(),
        Capability(
            id='github',
            description='Look up GitHub issues, pull requests, and code.',
            instructions='Use the GitHub tools when a question is about a repository.',
            toolset=MCPToolset('https://mcp.example.com/github'),
            defer_loading=True,
        ),
    ],
)

That last entry — the inline Capability — shows a richer shape. It bundles an ID, a description, instructions, and a toolset (here an MCP server) into a single declaration. Marked defer_loading=True, it stays collapsed to a one-line catalog entry until the model decides to load it. The model sees only the description in a compact list, then pulls the full bundle — instructions and tools together — in a single step when needed.

The Hooks System

The real power of capabilities comes from lifecycle hooks — the mechanism that lets a capability read and rewrite what the model sees on every step. This includes the model’s tools, its instructions, and its message history. As the v2 announcement puts it: “Code mode and tool search are built on exactly the same public hooks your own capabilities would use, so the batteries we ship double as worked examples.”

This is architecturally significant. It means the framework’s own advanced features don’t use privileged internal APIs — they use the same extension surface available to every developer. If Pydantic’s CodeMode capability can rewrite tool calls into Python code blocks using hooks, your custom capability can use those same hooks to implement guardrails, token budgets, or adaptive context management.

Built-in Capabilities Reference

Pydantic AI v2 ships with over 20 built-in capabilities. Here are the ones most relevant to production agent builders:

The “Spec” column indicates whether the capability can be serialized into an Agent Spec file (YAML/JSON). Capabilities that take non-serializable arguments — callables, toolset objects — can only be used in Python code.

Provider-Adaptive Tools: One API, Every Model

One of the most elegant design decisions in Pydantic AI v2 is the provider-adaptive tool pattern. Five built-in capabilities — WebSearch, WebFetch, ImageGeneration, XSearch, and MCP — each cover a single concern with two implementations:

• Native — the model provider handles it server-side (e.g., Anthropic’s built-in web search runs on their infrastructure)
• Local — your Python process does the work (e.g., calling DuckDuckGo directly)

This means you write WebSearch() once, and your agent automatically uses the native implementation when available and falls back to a local implementation when it’s not. Switch from Claude to GPT and the search still works — just via a different path.

from pydantic_ai import Agent
from pydantic_ai.capabilities import MCP, ImageGeneration, WebFetch, WebSearch, XSearch

agent = Agent(
    'anthropic:claude-sonnet-4-6',
    capabilities=[
        WebSearch(local='duckduckgo'),        # Native when supported; DuckDuckGo fallback
        WebFetch(local=True),                 # Native when supported; markdownify fallback
        ImageGeneration(fallback_model='openai-responses:gpt-5.4'),  # Subagent fallback
        XSearch(fallback_model='xai:grok-4.3'),                     # xAI native; explicit fallback
        MCP('https://mcp.example.com/api'),    # Runs locally by default
    ],
)

Notice the asymmetry: MCP defaults to local (because MCP connections carry credentials), while the others default to native. This is a security-conscious default that most framework designers would miss.

For RPA and automation architects already working with the Model Context Protocol (MCP), this native integration is significant. You can connect any MCP server as a capability — with automatic transport detection from a URL — and the agent handles the lifecycle.

The Pydantic AI Harness: Batteries Sold Separately

Pydantic AI v2 made a deliberate architectural split: the core framework stays small and stable, while the Pydantic AI Harness ships as a separate pydantic-ai-harness package with higher-level capabilities that iterate faster.

The Harness currently includes capabilities for:

• Code Mode — wraps tools into a single run_code call (more on this below)
• Memory — persistent agent memory across conversations
• Guardrails — content filtering and safety checks
• File System — sandboxed file access for agents
• Shell — sandboxed command execution
• Repo Context — code repository understanding
• Browser Use — web browser automation
• Compaction — context window management via server-side compaction (with dedicated OpenAI and Anthropic capabilities)
• Subagents — multi-agent coordination patterns
• Planning — structured planning capabilities
• Dynamic Workflow — runtime workflow construction
• Spend — cost tracking and budget management

The split is deliberate. As the official announcement explains: “Core stays small and stable, shipping the loop, the providers, the capability and hooks API, and only the capabilities that need deep provider support or are fundamental to every agent. Everything else lives in the Harness, where it can move fast, and a capability can graduate into core once it proves broadly essential.”

Third-party capabilities are already emerging. VStorm and other community contributors ship capabilities that Pydantic endorses and links to from the Harness, with plans to upstream the most mature ones.

Agent Specs: Declarative Agents in YAML/JSON

Because capabilities are serializable, Pydantic AI v2 introduces Agent Specs — the ability to define an entire agent in YAML or JSON, without writing Python code. This is a significant shift for enterprise teams where non-developers (business analysts, solution architects) need to configure agent behavior.

An Agent Spec file can define:

• The model to use
• System instructions
• Capabilities (any that are spec-compatible)
• Model settings
• Output schema

The generated JSON Schema file enables autocompletion and validation in editors that support the YAML Language Server protocol. For teams using RPA-to-agentic-AI transition strategies, this declarative approach maps well to the configuration-driven mindset that RPA platforms like UiPath and Automation Anywhere already use.

Code Mode: The Capability That Changes Everything

Of all the Harness capabilities, Code Mode deserves special attention because it fundamentally changes the agent execution model.

In a standard agentic loop, each tool call requires a full round-trip to the model: the agent decides to call tool A, sends the request, waits for the response, processes the result, then decides to call tool B. For a workflow that requires ten tool calls, that’s ten round-trips — each adding latency and token cost.

Code Mode changes this by wrapping your existing tools into a single run_code tool. Instead of one model round-trip per tool call, the model writes Python code that orchestrates your tools — with asyncio.gather for parallel calls, loops for iteration, and conditionals for branching — inside a single sandboxed execution. The code runs via Monty, Pydantic’s safe Python subset.

This means an agent that previously needed ten sequential round-trips to process ten invoices can now write a parallel processing script in one round-trip. For RPA architects designing high-throughput agentic workflows, this is a direct answer to the “agent latency tax” problem.

On-Demand Loading: Keep Your Prompt Lean

Production agents often have access to dozens or hundreds of tools — but cramming all of them into the system prompt on every run wastes context window space and confuses the model. Pydantic AI v2 solves this with on-demand capabilities.

When you set defer_loading=True on a capability, it stays collapsed to a one-line description in a compact catalog. The model sees a list of available capabilities and loads the full bundle — instructions, tools, and configuration — only when it decides it needs them.

refunds = Capability(
    id='refunds',
    description='Use for refund eligibility and refund status.',
    instructions='Always confirm the order ID before issuing a refund.',
    defer_loading=True,
)

@refunds.tool_plain
def refund_status(order_id: str) -> str:
    """Look up the refund status for an order."""
    return f'Order {order_id}: refund issued on 2026-05-01.'

agent = Agent('openai:gpt-5.2', capabilities=[refunds])

This is conceptually similar to how Claude Code’s own tool search works — and that’s not a coincidence. ToolSearch is itself a built-in capability that uses the same on-demand pattern to let agents discover tools from large registries without loading everything upfront.

Building Custom Capabilities

There are two paths to creating custom capabilities, depending on complexity:

The Declarative Path: Capability

For capabilities that bundle instructions, tools, and toolsets without needing lifecycle hooks:

from pydantic_ai.capabilities import Capability

invoice_processing = Capability(
    id='invoice-processing',
    description='Extract and validate invoice data from documents.',
    instructions='Always validate amounts against PO before approving.',
)

@invoice_processing.tool_plain
def extract_invoice(document_url: str) -> dict:
    """Extract structured data from an invoice document."""
    # Your extraction logic here
    return {"vendor": "...", "amount": 0.0, "po_number": "..."}

@invoice_processing.tool_plain
def validate_against_po(invoice_data: dict) -> str:
    """Cross-reference invoice against purchase order."""
    return "Validated: amounts match within tolerance."

The Subclass Path: AbstractCapability

For capabilities that need lifecycle hooks, model settings, or native tools, subclass AbstractCapability. This is the path for building guardrails, cost trackers, approval workflows, or any behavior that needs to intercept the agent loop:

from pydantic_ai.capabilities import AbstractCapability

class CostGuard(AbstractCapability):
    """Tracks token usage and stops the agent if budget is exceeded."""
    
    max_tokens: int = 100_000
    current_tokens: int = 0
    
    def on_model_response(self, response):
        self.current_tokens += response.usage.total_tokens
        if self.current_tokens > self.max_tokens:
            raise BudgetExceededError(
                f"Token budget {self.max_tokens} exceeded"
            )

The key insight: both paths produce objects that go into the same capabilities=[] list. The agent doesn’t care whether a capability was built declaratively or via subclass — it composes the same way.

How Pydantic AI v2 Compares to LangGraph, CrewAI, and AG2

Understanding where Pydantic AI v2 fits requires comparing its design decisions to the other major Python agent frameworks. Here’s a decision table for architects evaluating their options:

When to choose Pydantic AI v2: You’re building production Python agents, you value type safety, you want provider-agnostic code that works across OpenAI/Anthropic/Google/local models without rewiring, and your team already uses Pydantic or FastAPI. The capability model is particularly strong when you need to compose multiple concerns (memory + guardrails + instrumentation + custom tools) without them stepping on each other.

When to choose LangGraph: Your workflow is inherently graph-shaped with complex branching and state machines, or you’re deeply invested in the LangChain ecosystem (LangSmith, LangServe). For complex multi-agent orchestration patterns, LangGraph’s explicit graph model can be more readable than imperative agent code.

When to choose CrewAI: You want the fastest path from idea to working multi-agent prototype, your team prefers high-level abstractions over low-level control, and you’re comfortable with less type safety in exchange for simpler code.

When to choose AG2: You need event-driven, streaming-first architecture with concurrent agent support, especially for real-time applications. AG2’s beta redesign with MemoryStream addresses multi-user scenarios that other frameworks handle awkwardly.

Migrating from v1 to v2

The Pydantic team designed the v1-to-v2 migration to be as smooth as possible. The recommended path:

1. Upgrade to the latest v1 first and clear every deprecation warning. This catches most breaking changes before you ever touch v2.
2. Run uv add pydantic-ai to get v2.
3. Check these behavior changes that a deprecation warning couldn’t catch:
   • openai: model names now use the Responses API; use openai-chat: to stay on Chat Completions
   • WebSearch and WebFetch are native by default
   • MCP(url=...) runs locally by default
   • Instrumentation defaults to version 5 with aggregated token-usage attributes
   • Function tools requested alongside a successful output tool now run (end_strategy='graceful')

One policy change worth noting: the no-breaking-changes window between major versions has moved from six months to three. The Pydantic team’s reasoning is straightforward — the agentic AI field moves fast enough that committing further out means committing to decisions that don’t fit the world three months from now. Deprecations still always land before removals.

Production Patterns and Best Practices

Pattern 1: Layered Capabilities for Enterprise Agents

In production, capabilities naturally layer into three tiers:

1. Infrastructure capabilities (always-on): Instrumentation, Thinking, cost tracking
2. Domain capabilities (loaded on demand): CRM tools, ERP connectors, document processing
3. Guardrail capabilities (always-on): PII detection, content filtering, budget enforcement

agent = Agent(
    'anthropic:claude-sonnet-4-6',
    capabilities=[
        # Infrastructure (always-on)
        Instrumentation(),
        Thinking(effort='medium'),
        CostGuard(max_tokens=200_000),
        
        # Domain (on-demand)
        Capability(id='crm', description='Salesforce queries', 
                   toolset=crm_tools, defer_loading=True),
        Capability(id='erp', description='SAP data lookups', 
                   toolset=erp_tools, defer_loading=True),
        
        # Guardrails (always-on)
        PIIFilter(),
        OutputValidator(),
    ],
)

Pattern 2: Durable Execution for Long-Running Workflows

For agentic workflows that run for minutes or hours (common in RPA scenarios), Pydantic AI v2 is integrating durable execution as capabilities. TemporalDurability, DBOSDurability, and PrefectDurability ship in the pydantic_ai.durable_exec subpackages, with support for Restate, Kitaru, and Apache Airflow as well.

This is particularly relevant for organizations transitioning from traditional RPA to agentic automation. Traditional RPA workflows in UiPath or Automation Anywhere run deterministically and persistently — if the machine reboots, the workflow picks up where it left off. Agentic workflows need the same guarantees, and durable execution capabilities provide exactly that.

Pattern 3: Multi-Agent Coordination via Subagents

The Harness includes a Subagents capability for structured multi-agent coordination. Combined with the Planning capability, this enables patterns like:

• A supervisor agent that decomposes tasks and delegates to specialist agents
• Each specialist agent with its own capabilities (domain tools, guardrails)
• The supervisor aggregating results and making final decisions

This maps directly to the multi-agent orchestration patterns that platforms like Salesforce Agentforce and Microsoft Copilot Studio are implementing — but with the flexibility and transparency of open-source code.

Frequently Asked Questions

Can Pydantic AI v2 replace LangChain for production AI agents?

For new projects, yes — Pydantic AI v2 covers the agent loop, tool management, provider abstraction, and observability that most production agents need, with stronger type safety than LangChain. For existing LangChain projects, the migration cost depends on how deeply you’ve invested in LangChain-specific abstractions (chains, memory classes, output parsers). Pydantic AI’s MCP capability means you can incrementally adopt it by exposing existing tools as MCP servers.

How does Pydantic AI handle multi-model agents (e.g., Claude for reasoning, GPT for code)?

The SelectModel capability lets you pick a model per step using a callable — so your agent can route reasoning tasks to Claude and code generation to GPT within the same run. The provider-adaptive tool pattern means capabilities like WebSearch automatically adapt to whichever model is active.

Is Pydantic AI v2 production-ready for enterprise use?

Yes. The framework is built by Pydantic Services Inc. (the company behind the validation library used by most Python ML/AI infrastructure), ships with commercial-grade observability via Logfire, supports durable execution for crash-safe long-running workflows, and follows a formal version policy with no breaking changes within major versions.

What’s the relationship between Pydantic AI capabilities and MCP?

MCP (Model Context Protocol) is supported as a first-class built-in capability. Any MCP server can be connected as a capability via MCP('url') or MCPToolset. The on-demand loading feature means MCP tool registries can be discovered at runtime without upfront prompt loading. This makes Pydantic AI one of the most MCP-native agent frameworks available.

How do capabilities compare to LangGraph’s “tools” or CrewAI’s “tasks”?

Capabilities are broader. A LangGraph tool is a callable; a CrewAI task is a unit of work. A Pydantic AI capability can include tools plus instructions plus hooks plus model settings. The closest analogy in other ecosystems would be a LangChain “toolkit” combined with middleware — but as a single, type-safe, composable unit.

Key Takeaways

• One primitive to rule the loop: Pydantic AI v2’s capability bundles tools, hooks, instructions, and model settings into a single composable unit — eliminating the scattered configuration that plagues other frameworks.
• Provider-adaptive by default: Write WebSearch() once and it works across Claude, GPT, Gemini, and local models — switching between native and local implementations automatically.
• On-demand loading keeps agents lean: With defer_loading=True, capabilities stay out of the prompt until the model needs them — critical for agents with dozens or hundreds of available tools.
• Code Mode collapses round-trips: Instead of ten sequential tool calls, the model writes a single Python script that orchestrates all ten in parallel — a direct answer to agent latency.
• The Harness/core split is deliberate: Core stays stable (three-month major version cadence), while the Harness iterates fast with memory, guardrails, and execution capabilities.
• Agent Specs enable no-code agent configuration: Spec-compatible capabilities can be defined entirely in YAML/JSON, bridging the gap between developers and business users.
• Durable execution built in: Temporal, DBOS, Prefect, Restate, and Airflow integrations ship as capabilities, giving agentic workflows the same crash-safe guarantees as traditional RPA.
• MCP is a first-class citizen: Any MCP server connects as a capability with automatic transport detection — making Pydantic AI one of the most MCP-native frameworks in the ecosystem.
• ~19k GitHub stars and growing: Backed by Pydantic Services Inc. with commercial support via Logfire, this is not a weekend project — it’s production infrastructure.

References

1. Douwe Maan, “Pydantic AI v2: capable agentic loops,” Pydantic Blog, June 23, 2026. https://pydantic.dev/articles/pydantic-ai-v2
2. “Capabilities Overview,” Pydantic AI Documentation, 2026. https://pydantic.dev/docs/ai/capabilities/overview/
3. “Pydantic AI Harness,” Pydantic Documentation, 2026. https://pydantic.dev/docs/ai/harness/
4. pydantic/pydantic-ai GitHub Repository. https://github.com/pydantic/pydantic-ai
5. pydantic/pydantic-ai-harness GitHub Repository. https://github.com/pydantic/pydantic-ai-harness
6. “Pydantic AI v2 Ships a Single Primitive That Rebuilds How Agents Work,” AlphaSignal, 2026. https://alphasignal.ai/news/pydantic-ai-v2-ships-a-single-primitive-that-rebuilds-how-agents-work
7. “What Is Pydantic AI 2.0? The Capability Primitive That Changes How You Build Agents,” MindStudio, 2026. https://www.mindstudio.ai/blog/what-is-pydantic-ai-2-0-capability-primitive
8. Kacper Wlodarczyk, “Pydantic AI Capabilities, Hooks & Agent Specs — What Changed and How Our Libraries Migrated,” Medium, 2026. https://medium.com/@kacperwlodarczyk/pydantic-ai-capabilities-hooks-agent-specs-migration-guide-with-real-code-d0d986eb2b91
9. “Agent Specs,” Pydantic AI Documentation, 2026. https://pydantic.dev/docs/ai/core-concepts/agent-spec/
10. “Durable Execution Overview,” Pydantic AI Documentation, 2026. https://pydantic.dev/docs/ai/capabilities/durable_execution/overview/

Published on rpabotsworld.com — practical guides for Agentic AI Architects, Generative AI Architects, and RPA professionals building the next generation of intelligent automation.

This guide breaks down what the Agentic Control Plane actually is, how it compares to Microsoft Copilot Studio and ServiceNow AI Agents, what the Agent Catalog and Agent Connect framework mean for your existing automation investments, and whether IBM’s bet on being the “control plane for every agent, any framework” holds up under scrutiny. If you’re an Agentic AI Architect evaluating enterprise agent platforms — or an RPA practitioner in an IBM-heavy shop wondering what this means for your UiPath and Automation Anywhere workflows — this is the piece you need.

Table of Contents

• What Is the Agentic Control Plane?
• Why Enterprise AI Needs a Control Plane (Not Just More Agents)
• Architecture Deep Dive: How watsonx Orchestrate Works
• The Agent Catalog: 150+ Connectors and Prebuilt Agents
• Agent Connect: Bringing External Agents Into the Fold
• Governance, Compliance, and the OWASP Agentic Top 10
• IBM + ServiceNow: Cracking the Legacy System Problem
• IBM Bob: The Agentic Coding Assistant
• watsonx Orchestrate vs. Copilot Studio vs. ServiceNow AI Agents vs. Agentforce
• Pricing and Deployment Options
• Production Deployments: Aramco, Cleveland Clinic, Elevance Health
• What This Means for RPA Practitioners
• Getting Started: From Free Trial to Production
• FAQs
• Key Takeaways

What Is the Agentic Control Plane?

The term “control plane” comes from networking — it’s the layer that decides how traffic flows, as opposed to the data plane that actually carries the packets. IBM is applying the same concept to AI agents. The Agentic Control Plane, launched in June 2026 on both AWS and IBM Cloud, is a centralized management layer inside watsonx Orchestrate that handles operations, governance, and scaling for every AI agent in an enterprise — regardless of which framework built it, which cloud runs it, or which team owns it.

In concrete terms, the Agentic Control Plane provides four capabilities that most enterprises currently lack:

• Operational visibility: A unified dashboard showing what every agent is doing across the organization, with prioritized alerts for operations, incidents, and anomalies. No more digging through individual logs to figure out which agent failed at 3 AM.
• Runtime governance: Policy enforcement that happens while agents execute, not after. Content guardrails detect and block non-compliant outputs before they reach users. Credential health monitoring catches broken connections before they cause failures.
• A shared catalog: A single place to publish, version, discover, and reuse proven agents across teams — solving the endemic problem of three different departments rebuilding the same invoice-processing agent because nobody knew the others existed.
• Native scheduling: Automated execution of recurring agent workflows (weekly reports, daily monitoring, compliance checks) without requiring a human to manually trigger each run.

The critical differentiator IBM is pushing: the control plane is framework-agnostic. It manages agents built on IBM’s own Granite models, LangChain, LangGraph, CrewAI, Microsoft Copilot Studio, or custom homegrown code through a consistent interface. Whether your agent runs on AWS, Azure, IBM Cloud, or on-premises behind an air gap, the control plane treats it as a first-class citizen.

Why Enterprise AI Needs a Control Plane (Not Just More Agents)

The agentic AI market in 2026 has a supply problem — not a supply shortage, but a supply surplus. Every platform vendor, every cloud provider, and every open-source framework is shipping agent-building tools. The bottleneck has shifted from “can we build agents?” to “can we actually run them reliably across the organization?”

Consider a typical Fortune 500 company in mid-2026. The HR team built agents using Microsoft Copilot Studio because they’re a Microsoft 365 shop. The sales team deployed Salesforce Agentforce because their CRM is Salesforce. The IT operations team built custom agents on LangGraph because they needed fine-grained control. The finance team inherited a set of UiPath-orchestrated RPA bots that someone is now “upgrading” with agentic capabilities. And the innovation lab prototyped something on CrewAI that the CISO hasn’t approved yet.

This is the pattern behind most agentic automation failures: not bad technology, but ungoverned proliferation. No single team has visibility into all of these agents. There’s no unified audit trail. Compliance can’t answer the question “which agents have access to PII?” without calling five different platform owners. When an agent starts producing hallucinated outputs in a customer-facing workflow, the mean time to detection is measured in days, not minutes.

IBM’s bet is that the enterprise AI market will converge on a control-plane architecture — the same way container orchestration converged on Kubernetes, regardless of which container runtime you used underneath. Watsonx Orchestrate is their candidate to be that Kubernetes-for-agents layer.

Architecture Deep Dive: How watsonx Orchestrate Works

The platform is organized into four interconnected layers, each addressing a different stage of the agent lifecycle.

Layer 1: Agent Builder

The builder layer is where agents are authored. Teams can create agents using a low-code visual interface (for business users and citizen developers) or a pro-code approach (for AI engineers who need full control). The builder supports:

• Decision Tables: Replace complex if/else branching with a structured, spreadsheet-like format that both business analysts and developers can read and maintain.
• Parallel Execution: Independent steps (API calls, background processes) run simultaneously rather than sequentially, reducing total workflow execution time.
• Multi-model orchestration: A single agent can route tasks across IBM Granite, Anthropic Claude, Mistral, or other LLMs depending on the task requirements and cost constraints.

Layer 2: Agent Catalog

The catalog is not a marketplace — it’s an internal enterprise registry with version control. When a team publishes an agent to the catalog, they attach metadata (descriptions, categories, icons), semantic versioning, and a change log. Dependencies — collaborator agents, Python tools, custom integrations — travel with the agent automatically. Publishing creates an immutable snapshot, so other teams build on a known-good version while the original team continues iterating.

Layer 3: Agentic Control Plane

This is the operational core. The control plane provides:

• Operational Dashboard: Surfaces prioritized alerts across operations, incidents, and insights. Includes an embedded operations agent that lets administrators investigate issues using natural language — no query language required.
• Agent Analytics: Usage, performance, and reliability trends tracked over time with drill-down capabilities.
• Policy Management: Runtime policy enforcement — rules execute while agents are working, not as an after-the-fact audit.
• Credential Health Monitoring: Continuous checks on agent-to-system connections, catching broken or expired credentials before they cause workflow failures.
• Agent Access Overview: A single view showing which agents can access which integrations and data sources — the answer to “who has access to what?” that compliance teams need.
• Content Guardrails: Real-time detection and blocking of non-compliant, harmful, or hallucinated outputs before they reach end users.
• Observability Traces: Full visibility into context changes across a workflow, making root-cause analysis faster when something breaks.

Layer 4: Enterprise Integrations

The platform ships with 150+ enterprise connectors covering the systems most large organizations already run: Salesforce, SAP, Workday, ServiceNow, Microsoft 365, Oracle, Adobe, and AWS. These aren’t thin API wrappers — they include pre-built authentication flows, error handling, and data mapping that would take weeks to build from scratch.

The Agent Catalog: 150+ Connectors and Prebuilt Agents

The Agent Catalog addresses a problem that every enterprise automation architect recognizes: the same agent logic gets rebuilt multiple times by different teams who don’t know the other version exists. IBM’s catalog is designed as an interoperability layer, not just a listing page.

What’s in the Catalog

The catalog includes prebuilt agents organized by business function:

• HR agents: Talent acquisition, employee onboarding, benefits administration, internal knowledge queries
• Finance agents: Invoice processing, reconciliation, expense reporting, financial close workflows
• Sales agents: Lead qualification, opportunity management, pipeline forecasting, customer engagement
• IT operations agents: Incident triage, service request fulfillment, infrastructure monitoring, change management
• Supply chain agents: Order tracking, inventory optimization, supplier communication, logistics coordination
• Procurement agents: Purchase order management, vendor evaluation, contract analysis

Each agent in the catalog ships with proven connectors to enterprise systems — Workday for HR, SAP for finance, Salesforce for CRM — so teams aren’t reinventing authentication, data access, and error handling for every new use case.

Framework Agnosticism in Practice

The catalog’s most significant architectural decision is its framework neutrality. Unlike Microsoft’s Copilot Studio (which privileges Microsoft 365 integrations) or Salesforce Agentforce (which is tightly coupled to the Salesforce ecosystem), watsonx Orchestrate’s catalog accepts agents built on any framework. According to IBM’s product blog:

“The catalog is not tied to a single SDK, large language model or cloud.”

This means agents built on LangChain, LangGraph, CrewAI, or entirely custom Python/Java code can be published alongside IBM-native agents and surfaced through the same discovery, versioning, and governance mechanisms. For organizations that have already invested in open-source agentic frameworks, this is a significant value proposition — you bring your existing agents forward rather than rebuilding.

Agent Connect: Bringing External Agents Into the Fold

Agent Connect is the technical and commercial program through which external agents integrate with watsonx Orchestrate. It’s both an SDK/API layer and a partner program.

How Agent Connect Works

The Agent Connect Framework is a framework-agnostic integration architecture. External agents connect to watsonx Orchestrate through standard interfaces, and once connected, they appear as first-class citizens in the Agent Catalog — discoverable, versionable, and governable through the same control plane as IBM-native agents.

Currently supported integration paths include:

• IBM native agents built on Granite models and watsonx tools
• LangFlow agents authored in the visual LangFlow builder
• LangGraph agents with stateful, graph-based orchestration
• A2A protocol agents using Google’s open Agent-to-Agent standard
• MCP-compatible agents using the Model Context Protocol for tool interoperability

IBM has signaled that broader interoperability — including direct integration with Microsoft Copilot Studio agents — is on the roadmap for late 2026.

The Partner Ecosystem

Agent Connect also functions as a go-to-market channel. ISVs and technology partners can integrate their agents with watsonx Orchestrate, list them in the Agent Catalog, and access IBM’s enterprise sales channels and partner network. For automation tool vendors considering where to make their agents available, this creates a distribution path into IBM’s Fortune 500 customer base — a market where IBM has decades of relationship depth.

Governance, Compliance, and the OWASP Agentic Top 10

Governance is where IBM is drawing the sharpest competitive line. While most agent platforms treat governance as a feature checkbox, watsonx Orchestrate positions it as the central design principle.

Runtime Policy Enforcement

The Agentic Control Plane enforces policies at runtime — while agents execute — rather than relying on post-hoc auditing. This is a meaningful architectural distinction. In a post-hoc model, you find out an agent violated a compliance rule after it already sent the email, processed the transaction, or exposed the data. In a runtime model, the policy engine intercepts non-compliant actions before they complete.

Specific governance capabilities include:

• Role-based access control (RBAC): Team-scoped workspaces with granular permissions for who can build, publish, execute, and monitor agents
• Content guardrails: Configurable filters that detect and block harmful, biased, or hallucinated outputs in real-time
• Credential lifecycle management: Automated monitoring of agent-to-system credentials with alerts before expiration
• Audit trails: Complete, immutable records of every agent action — what was done, when, by which agent, with what data access
• Agent-to-agent protocol support: Safety guardrails for multi-agent workflows to prevent cascading failures in autonomous execution chains

Addressing the OWASP Agentic Top 10

The OWASP Agentic Top 10 has emerged as the de facto security framework for enterprise AI agents. IBM’s governance layer maps directly to several of these risks:

For organizations in regulated industries — banking, healthcare, government, energy — this governance depth is often the deciding factor. As HyperFRAME Research noted, the friction of governance is real, but it’s also the price of admission for deploying agents in environments where a compliance violation can mean millions in fines.

IBM + ServiceNow: Cracking the Legacy System Problem

On June 11, 2026, at ServiceNow’s Knowledge 2026 conference in Las Vegas, IBM and ServiceNow announced an expanded AI alliance that directly targets the biggest blocker to enterprise agentic AI adoption: legacy systems.

The Problem

Most Fortune 500 companies run critical business logic on mainframes, legacy .NET applications, SAP ECC systems, and custom COBOL programs that were written before anyone imagined AI agents would need to interact with them. These systems hold the data and execute the transactions that matter most — payroll processing, claims adjudication, supply chain management — but they were never designed to expose APIs or speak modern protocols.

The result: AI agents built on shiny new frameworks hit a wall the moment they need to interact with the systems that actually run the business.

The Joint Solution

The IBM-ServiceNow partnership targets three areas:

1. Application modernization: Using IBM Bob (see next section) and Enterprise Application Runtimes to wrap legacy systems with AI-accessible interfaces — without the “rip and replace” approach that most modernization initiatives demand.
2. Enterprise data governance: Connecting watsonx.data (IBM’s data lakehouse) with ServiceNow’s Workflow Data Fabric to give agents governed access to data trapped in mainframes, SAP, Oracle, and legacy Windows systems.
3. Autonomous infrastructure operations: Deploying AI agents that can monitor, diagnose, and remediate infrastructure issues across hybrid environments — cloud, on-prem, and legacy — using ServiceNow’s ITSM workflows as the orchestration backbone.

The approach is pragmatic rather than revolutionary: instead of rebuilding legacy systems (a project most enterprises have been “planning” for a decade), the partnership wraps them with AI connectors that let agents interact with them as-is. For the RPA community, this should sound familiar — it’s essentially what RPA bots have been doing for years, but with an agentic intelligence layer on top.

IBM Bob: The Agentic Coding Assistant

IBM Bob, unveiled at Think 2026 and updated with major new capabilities on July 9, 2026, is IBM’s agentic coding assistant — their answer to Anthropic’s Claude Code and OpenAI’s Codex. But Bob is specifically designed for enterprise software development, with a focus on the legacy modernization challenge that most coding assistants ignore.

Key Capabilities

• Multi-agent architecture: Bob doesn’t just respond to prompts — it coordinates specialized agents across roles (requirements, code generation, testing, deployment) and lifecycle stages.
• Multi-model orchestration: Routes tasks across IBM Granite, Anthropic Claude, and Mistral models depending on task requirements, optimizing for both quality and cost.
• Enterprise modernization workflows: Pre-built workflows specifically designed for migrating COBOL, mainframe, and legacy .NET applications — the exact systems the ServiceNow partnership targets.
• Built-in cost and usage analytics: Tracks AI consumption and costs at the team and project level, giving IT leaders the data they need to justify continued investment.
• Security and governance controls: Enterprise-grade access controls, code scanning, and audit trails that meet the requirements of regulated industries.

One widely cited case study: a client reportedly compressed a 9-month legacy modernization project to 3 days using Bob’s automated analysis and code generation capabilities. While the specifics of that claim deserve healthy skepticism (compressed timelines in demos rarely translate directly to production), it illustrates the scale of ambition IBM is bringing to this space.

watsonx Orchestrate vs. Copilot Studio vs. ServiceNow AI Agents vs. Agentforce

The enterprise agentic AI platform market in 2026 has four primary contenders, each with a different architectural philosophy. Here’s how they compare on the dimensions that matter most to Agentic AI Architects.

When to Choose watsonx Orchestrate

Choose IBM watsonx Orchestrate when your organization:

• Operates in a regulated industry (banking, healthcare, government, energy) where governance and auditability are non-negotiable
• Runs a heterogeneous technology estate — multiple clouds, multiple agent frameworks, legacy systems that can’t be replaced
• Needs on-premises or air-gapped deployment for data sovereignty requirements
• Has invested in open-source agent frameworks (LangChain, LangGraph, CrewAI) and wants a management layer without vendor lock-in
• Already has significant IBM infrastructure (mainframes, Db2, MQ) that agents need to interact with

When to Choose a Competitor

Choose Copilot Studio if your organization is standardized on Microsoft 365 and Azure, and your agent use cases center on productivity automation. The Microsoft Agent Framework with Hosted Agents GA provides excellent developer experience within the Microsoft ecosystem.

Choose ServiceNow AI Agents if your primary use case is IT service management and your agents need deep integration with ITSM workflows, CMDB, and the ServiceNow platform.

Choose Salesforce Agentforce if your agents are primarily customer-facing (sales, service, marketing) and your CRM is Salesforce.

Pricing and Deployment Options

IBM watsonx Orchestrate offers four pricing tiers, making it accessible to mid-market organizations while scaling to enterprise requirements:

Deployment flexibility is a key differentiator. Watsonx Orchestrate runs as a fully managed service on IBM Cloud or AWS, and also supports on-premises deployment for organizations that need to keep data and agents within their own infrastructure. This dual deployment model matters for industries like defense, healthcare, and financial services where data sovereignty requirements often eliminate cloud-only platforms from consideration.

Production Deployments: Aramco, Cleveland Clinic, Elevance Health

IBM showcased three production deployments at Think 2026 that illustrate the platform’s range across industries with very different compliance and security requirements:

Aramco (Energy)

The world’s largest oil company deployed watsonx Orchestrate to automate operational workflows across its engineering and procurement functions. In an industry where a single miscommunication can cost millions (or cause safety incidents), the governance and audit trail capabilities of the Agentic Control Plane were cited as the deciding factor over competing platforms.

Cleveland Clinic (Healthcare)

Cleveland Clinic’s deployment demonstrates the platform’s viability in the most heavily regulated environment in American business — healthcare under HIPAA. The specific use cases weren’t publicly detailed, but healthcare agent deployments typically focus on clinical decision support, patient scheduling optimization, and administrative workflow automation — all areas where the content guardrails and access controls of the control plane are essential rather than optional.

Elevance Health (Health Insurance)

Elevance Health (formerly Anthem) described their AI agent deployments in the insurance claims processing and member services domains. Health insurance is a domain where agent errors can directly impact patient care and trigger regulatory action, making the runtime policy enforcement and real-time monitoring capabilities of the Agentic Control Plane particularly relevant.

What This Means for RPA Practitioners

If you’re an RPA developer or architect working with UiPath, Automation Anywhere, or Blue Prism, the rise of agentic control planes like watsonx Orchestrate represents both a threat and an opportunity.

The Threat

IBM’s vision — agents that can interact with legacy systems through AI-powered connectors rather than screen-scraping bots — directly challenges the value proposition of traditional RPA. If an AI agent can wrap a mainframe terminal session or an SAP GUI interaction with an intelligent connector (using tools like IBM Bob for modernization), the case for maintaining thousands of brittle, screenshot-dependent RPA bots weakens significantly.

The Opportunity

The transition from RPA to agentic AI doesn’t happen overnight, and watsonx Orchestrate’s interoperability story actually creates a bridge. RPA practitioners who understand enterprise process orchestration, exception handling, and the real-world complexity of legacy system integration bring exactly the skills that pure AI engineers often lack. The Agentic Control Plane’s 150+ enterprise connectors speak the same language that RPA developers have been working with for years — SAP, Workday, Oracle, ServiceNow — just through an agentic interface rather than a bot-driven one.

The practitioners who will thrive are those who learn to think in terms of agent orchestration (multi-agent workflows with governance) rather than bot execution (sequential tasks with hard-coded exception rules). The operational concepts transfer directly; the implementation paradigm shifts.

Getting Started: From Free Trial to Production

IBM offers a practical onboarding path that doesn’t require an enterprise contract to begin:

1. Free trial: Sign up at ibm.com/products/watsonx-orchestrate for hands-on access to the builder, catalog, and a limited set of connectors.
2. Explore the Agent Catalog: Browse prebuilt agents for your domain (HR, finance, IT, sales) and test them against your actual data sources.
3. Connect existing agents: If you’ve already built agents on LangChain, LangGraph, or another framework, use the Agent Connect documentation to integrate them into the catalog.
4. Enable the Agentic Control Plane: Upgrade to Standard or Enterprise to activate governance, monitoring, and policy enforcement across your agent fleet.
5. Partner evaluation: If you’re an ISV or technology partner with agents to distribute, join the Agent Connect program for catalog listing and IBM go-to-market support.

Frequently Asked Questions

Does watsonx Orchestrate require IBM Cloud, or can it run on AWS?

Both. The Agentic Control Plane launched in June 2026 on AWS and IBM Cloud simultaneously. On-premises deployment is also available for organizations with data sovereignty requirements. IBM has not announced Azure support, which is a gap for organizations running primarily on Microsoft infrastructure.

Can I connect my existing LangChain or LangGraph agents to watsonx Orchestrate?

Yes. The Agent Connect framework supports LangFlow and LangGraph agents natively, and custom agents built on any framework can be integrated through the standard Agent Connect API. Once connected, they appear as first-class citizens in the Agent Catalog with full governance and monitoring.

How does watsonx Orchestrate compare to building my own control plane on Kubernetes?

You can certainly build a custom agent management layer — and many early adopters did exactly that in 2025. The trade-off is development time (months vs. days), maintenance burden (you own every bug), and governance depth (building RBAC, content guardrails, credential monitoring, and audit trails from scratch is substantial engineering effort). Watsonx Orchestrate is the “buy” option for organizations that want to focus on building agents rather than building agent infrastructure.

What LLMs does watsonx Orchestrate support?

The platform supports IBM Granite models natively, with multi-model orchestration that can route tasks to Anthropic Claude, Mistral, and other LLMs. This multi-model approach lets teams optimize for quality, cost, and latency across different agent tasks rather than being locked into a single model provider.

Is watsonx Orchestrate suitable for small and mid-size organizations?

The Essentials plan at $500/month makes it accessible to mid-market organizations, though the platform’s core value proposition — managing a fleet of heterogeneous agents across multiple frameworks and systems — is most relevant to organizations with significant enough scale to have the “agent sprawl” problem. Smaller teams with a single agent framework and a few agents may find the overhead of a full control plane unnecessary.

Key Takeaways

• The Agentic Control Plane is IBM’s bid to be the “Kubernetes for AI agents” — a single management layer that governs agents regardless of framework, cloud, or team.
• Framework agnosticism is the headline differentiator. Unlike Copilot Studio (Microsoft-first) or Agentforce (Salesforce-first), watsonx Orchestrate treats LangChain, CrewAI, and custom agents as first-class citizens alongside IBM-native ones.
• Governance is the moat, not a feature checkbox. Runtime policy enforcement, content guardrails, credential monitoring, and full audit trails are designed for regulated industries where compliance failures have material consequences.
• The IBM-ServiceNow partnership tackles the legacy system problem by wrapping mainframes and legacy apps with AI connectors rather than demanding “rip and replace” modernization.
• The Agent Catalog solves the “three teams building the same agent” problem with enterprise-grade versioning, dependency management, and cross-team discovery.
• For RPA practitioners, this is a transition signal, not a threat. The skills in process orchestration, exception handling, and enterprise system integration transfer directly — the implementation paradigm shifts from bot execution to agent orchestration.
• Pricing starts at $500/month (Essentials) with a free trial available, though the full Agentic Control Plane requires Standard or Enterprise tier.

References

1. IBM. “Agentic Control Plane in IBM watsonx Orchestrate: One place to control every AI agent.” Published July 2, 2026. ibm.com
2. IBM. “Any agent, any framework: Inside the IBM watsonx Orchestrate Agent Catalog.” Published January 5, 2026. ibm.com
3. Enterprise DNA. “IBM Think 2026: Watsonx Orchestrate GA and Agent Catalog.” enterprisedna.co
4. CIO Dive. “ServiceNow, IBM team up to target legacy IT.” Published June 2026. ciodive.com
5. DevOps.com. “IBM Bob Takes AI Coding Assistants to the Next Level.” devops.com
6. IBM Newsroom. “IBM Advances Enterprise AI Software Development with Multi-Agent Capabilities.” Published July 9, 2026. newsroom.ibm.com
7. HyperFRAME Research. “IBM Watsonx Orchestrate and the Friction of Autonomous Agent Governance.” Published May 5, 2026. hyperframeresearch.com
8. IBM. “Unlock the future of AI agent orchestration with IBM Agent Connect.” ibm.com
9. Futurum Group. “Can IBM and ServiceNow Finally Make Legacy Systems AI-Ready?” futurumgroup.com
10. IBM. “watsonx Orchestrate Pricing.” ibm.com

The SAP LeanIX Agentic AI Survey 2026 puts the adoption numbers into sharper focus: 98% of companies have either deployed AI agents or plan to. But fewer than half have visibility into a basic inventory of what agents exist, who owns them, and what they can access. Teams deploy agents independently — a marketing automation agent here, a supply chain monitoring agent there, an HR onboarding bot somewhere else — and each works in isolation. Without a centralized governance framework, the organization accumulates a fragmented landscape of agents that cannot be audited consistently, do not interoperate, and generate technical debt faster than they generate value.

This pattern has a name: agent sprawl. And SAP, through its 2023 acquisition of LeanIX and the broader Joule agentic platform, is making a deliberate play to become the governance layer of record for the enterprise agent ecosystem.

This guide breaks down what SAP AI Agent Hub actually does, how it fits into SAP’s broader agentic architecture (Joule, Joule Studio, Joule Work, MCP, A2A), what the Gartner framework for agent governance looks like in practice, and what every agentic AI architect should consider when evaluating governance platforms in 2026.

What Is Agent Sprawl and Why Should You Care?

Agent sprawl occurs when AI agents are created, deployed, or connected across systems faster than the enterprise can inventory them, assign ownership, control permissions, monitor behavior, and retire them when they are no longer fit for purpose. It is the agentic equivalent of shadow IT — except agents do not just store data or run reports. They take actions: calling tools, accessing systems, initiating business processes, and making decisions with real financial and operational consequences.

The mechanics are familiar to anyone who has navigated a wave of SaaS adoption. Individual teams, motivated by genuine productivity goals, deploy agents independently. Each agent is designed for a specific task. Each works in isolation. The organization accumulates a fragmented landscape without centralized oversight.

What makes agent sprawl more dangerous than SaaS sprawl is the difference in blast radius. As SAP’s August 2026 analysis frames it: with chatbots and early generative AI, a security failure typically meant bad output — an inaccurate response that could be corrected after the fact. In the agentic era, the consequences of an agent failure or security breach are far more damaging because agents can execute transactions, delete records, and trigger irreversible workflows.

Publicly reported incidents already illustrate the risk: malicious prompt injections causing agents to bypass guardrails, agents leaking sensitive data through over-permissioned tool access, and rogue agents triggering unintended financial transactions. These are not theoretical scenarios — they are documented failure modes that governance frameworks are specifically designed to prevent.

The Numbers Behind the Sprawl

The message is clear: agent deployment is outrunning governance by an order of magnitude. The organizations that solve this gap first will scale AI as a durable competitive advantage. Those that defer will spend 2027 cleaning up — and with agents, the cost of speed without structure arrives faster and at greater scale than anything that has come before.

SAP AI Agent Hub: Architecture and Capabilities

SAP AI Agent Hub is a vendor-agnostic command center built on top of SAP LeanIX Application Portfolio Management. It provides a single entry point for discovering, governing, and managing AI agents, large language models (LLMs), and Model Context Protocol (MCP) servers across the entire enterprise landscape — regardless of which vendor built or hosts them.

This is not a marketplace for buying agents. It is not a development platform for building them. It is a governance layer that sits above all of those things and answers the questions that matter most to CIOs, compliance officers, and enterprise architects: What agents exist in our organization? What can they access? Who owns them? Are they compliant? Are they performing?

Auto-Discovery Across Vendors

The Agent Hub automatically discovers AI agents, LLMs, and MCP servers from SAP, Microsoft, Google, AWS, Databricks, and ServiceNow. Built-in integrations with these major AI agent repositories provide an overview of available agents, while a dedicated API using the Agent-to-Agent (A2A) protocol allows organizations to import in-house or custom-built agents into the same governed registry.

This cross-vendor discovery is the critical differentiator. Most agent platforms — Microsoft Copilot Studio, Salesforce Agentforce, Oracle AI Agent Studio — are excellent at governing their own agents within their own ecosystem. But real enterprises run agents from five or six different vendors simultaneously. The governance gap is not within any single platform; it is across all of them. SAP AI Agent Hub is designed to close exactly that gap.

Six Core Capabilities

SAP AI Agent Hub is structured around six capabilities, two of which reached general availability in early 2026, with the remaining four rolling out in Q3 2026:

1. Agent Discovery (GA). Auto-discovers agents across SAP and non-SAP environments. The discovery inbox lets teams select which agents to add to their governed inventory and relate them to existing applications, business capabilities, and IT landscape context within LeanIX.

2. Agent Inventory and Classification (GA). Organizes discovered agents into a searchable registry with classification, status, and a fact sheet for each agent. Teams can inventory available agents, track ownership, and map agents to the business processes they support.

3. Governance Assessment (Q3 2026). Structured workflows that capture risk ratings and compliance mappings for each agent. Nothing ships into production without a verified governance record. This is where the EU AI Act compliance requirements get operationalized — each agent’s risk classification, data access scope, and decision authority are documented and auditable.

4. Agent Identity and Access Control (Q3 2026). Each agent receives a unique identity through SAP Cloud Identity Services. This addresses one of the most common governance failures: agents operating with shared credentials or overly broad permissions. With individual identities, organizations can apply the same access control rigor to agents that they apply to human users.

5. AI Observability (Q3 2026). Session-level monitoring that provides visibility into what agents are actually doing in production — not just what they were designed to do. This includes detecting anomalous behavior, policy violations, and scope creep.

6. Performance Monitoring (Q3 2026). Ties agent performance to business KPIs, enabling organizations to measure ROI at the agent level and retire underperforming agents before they accumulate technical debt.

Pricing: Bundled at No Additional Charge

SAP CTO Philipp Herzig confirmed at SAP Sapphire 2026 that AI Agent Hub will be included in the SAP Business AI Platform at no additional charge. This is a significant pricing signal. By removing the cost barrier, SAP is positioning the Agent Hub not as a premium governance add-on, but as the default governance layer for any organization already running SAP — and, critically, as an attractive option for governing non-SAP agents as well.

The strategic intent is clear: if you are already an SAP customer, the marginal cost of using SAP as your cross-vendor agent governance layer is zero. That is a powerful argument in a market where competing governance tools are either nascent, siloed, or expensive.

How SAP AI Agent Hub Fits Into the Broader Joule Ecosystem

Agent Hub does not exist in isolation. It is one layer in SAP’s multi-layered agentic AI architecture. Understanding where it sits relative to Joule, Joule Studio, and Joule Work is essential for architects evaluating the platform.

Joule: The Agentic Foundation

Joule is SAP’s AI copilot and agent runtime, embedded across SAP’s cloud portfolio. As of mid-2026, Joule includes more than 40 specialized agents with over 2,400 skills spanning finance, HR, supply chain, procurement, and customer experience. These are pre-built agents that execute within SAP’s transactional systems — they are not external add-ons bolted on after the fact.

Joule Studio: The Builder

Joule Studio reached general availability in 2026. It is SAP’s no-code and low-code agent builder, enabling business users and developers to create custom agents with support for Model Context Protocol (MCP) and the Agent-to-Agent (A2A) protocol. This means custom-built Joule agents can interoperate with agents from Microsoft, Google, and other A2A-compliant platforms.

Joule Studio 2.0 added managed agent builder capabilities for citizen developers, lowering the barrier to agent creation. This is both an opportunity and a governance risk — more builders means more agents, which means more sprawl potential, which is exactly why Agent Hub exists as a complementary layer.

Joule Work: The Agentic Harness

Joule Work adds the agentic execution harness — computer and file access, MCP connectivity, and A2A orchestration for multi-agent workflows across heterogeneous environments. General availability for Joule Work and Joule A2A capabilities is planned for Q4 2026.

From Joule Work, customers can access Joule Studio to build custom agents that use MCP and A2A to draw on tools and third-party agents. The A2A protocol specifically standardizes direct, bidirectional communication between agents across vendor boundaries, enabling agents from different ecosystems to collaborate in shared business processes.

The Architecture Stack

Gartner’s Six-Step Framework for Managing Agent Sprawl

In April 2026, Gartner published a six-step framework for managing AI agent sprawl. It is vendor-neutral but maps remarkably well to what SAP AI Agent Hub delivers. Here is how each step translates to practice.

Step 1: Establish agent governance and policies. Set clear rules for when and how agents are built, who can create and share them, and what connectors are permitted. This is the “constitution” layer — without it, every subsequent step is ad hoc. SAP AI Agent Hub operationalizes this through governance assessments with risk ratings and compliance mappings.

Step 2: Build a centralized agent inventory. Use AI trust, risk, and security management (AI TRiSM) tools to discover and categorize agents across applications — including agents from sanctioned tools and shadow AI. Agent Hub’s auto-discovery across six major vendors addresses this directly.

Step 3: Define agent identity, permissions, and lifecycle. Manage agent identity, permission models, and access controls. Review and retire redundant agents. Agent Hub’s Q3 2026 identity management via SAP Cloud Identity Services gives each agent a unique, governable identity.

Step 4: Develop AI information governance. Govern what information each agent can access. Ensure processes exist to keep data current, manage permissions to prevent oversharing, and archive data when obsolete. This is where the EU AI Act’s high-risk classification requirements intersect with operational governance.

Step 5: Monitor and remediate agent behavior. Establish ongoing visibility into agent usage, ensure policy compliance, detect anomalous behavior, and correct agents that exceed their intended scope. Agent Hub’s observability layer (Q3 2026) provides session-level monitoring for exactly this purpose.

Step 6: Measure and optimize. Tie agent performance to business outcomes and continuously optimize the agent portfolio. Agent Hub’s performance monitoring capability connects agent activity to business KPIs, enabling data-driven retirement and investment decisions.

Max Goss, senior director analyst at Gartner, captured the urgency at a London conference in April: “Many organizations resort to blocking or restricting the use of AI agents, but this is not a long-term solution. If employees are unable to work in the sanctioned tools, they will likely go around the organization’s controls and start using shadow AI, which presents far greater risks.”

Practical Implications for Agentic AI Architects

If you are building or managing agentic AI systems in an enterprise, here is what the agent governance landscape means for your work in 2026.

1. Governance Is Now a Design Requirement, Not an Afterthought

The days of building an agent, deploying it, and figuring out governance later are ending. With the EU AI Act enforcement now live and Gartner flagging agent sprawl as a board-level risk, governance requirements need to be baked into agent architecture from the design phase. This means defining agent identity, data access scope, decision boundaries, audit trail requirements, and retirement criteria before the first line of agent code is written.

For RPA professionals transitioning into agentic AI, this is a familiar discipline. RPA centers of excellence have always managed bot inventories, access controls, and lifecycle governance. The difference is scale and autonomy — agents make decisions that bots never did, which means the governance surface area is larger and the consequences of failure are more severe.

2. Multi-Vendor Governance Will Become Table Stakes

No enterprise runs a single-vendor agent stack. The typical 2026 enterprise has Copilot Studio agents handling Microsoft 365 workflows, Agentforce agents in Salesforce CRM, custom LangGraph or CrewAI agents for specialized tasks, and possibly Joule agents in SAP ERP. Governing each platform in isolation creates the same fragmentation that agent sprawl describes.

Cross-vendor governance platforms — of which SAP AI Agent Hub is currently the most ambitious — will become essential infrastructure. The question is not whether you need one, but which one becomes your system of record.

3. The MCP and A2A Standards Enable Governance at Scale

The Model Context Protocol (MCP) and Agent-to-Agent (A2A) protocol are not just interoperability standards — they are governance enablers. MCP standardizes how agents connect to tools and data sources, making it possible to audit and control those connections centrally. A2A standardizes how agents communicate with each other, enabling governance layers to intercept, log, and validate inter-agent interactions.

SAP’s support for both protocols in Joule Studio, Joule Work, and Agent Hub means that agents built on MCP and A2A-compliant frameworks can be discovered, inventoried, and governed through a single pane of glass — even if they were built by different teams using different frameworks.

4. Forrester’s Caution: Concentration Risk Is Real

Not everyone is celebrating SAP’s governance play. Forrester has explicitly warned about concentration risk — the danger of giving a single vendor (SAP, in this case) governance authority over your entire multi-vendor agent estate. Their argument: if SAP becomes the governance gatekeeper, it has disproportionate influence over which agents are sanctioned, which are flagged, and how non-SAP agents are treated relative to SAP-native ones.

This is a legitimate architectural concern. Agentic AI architects should evaluate whether SAP AI Agent Hub’s vendor-agnostic claims hold up in practice — particularly around the depth of integration with non-SAP agent platforms versus SAP-native ones. A governance layer that subtly favors its own ecosystem is not truly vendor-agnostic.

5. The RPA-to-Agent Governance Continuity

For organizations with mature RPA programs, the transition to agent governance is less of a leap than it might appear. The core disciplines — bot inventory management, access control, credential vaulting, audit logging, exception handling, and lifecycle management — transfer directly. The difference is that agents are more autonomous, operate across more systems, and make higher-stakes decisions.

The practical move is to extend your existing RPA governance framework to cover AI agents rather than building agent governance from scratch. If your center of excellence already maintains a bot registry with ownership, access scope, and retirement criteria, you have the organizational muscle to do the same for agents. SAP AI Agent Hub — or whichever governance platform you select — is the tooling layer that scales that discipline across hundreds or thousands of agents.

SAP AI Agent Hub vs. Competing Approaches

The fundamental difference is scope. Microsoft and Salesforce govern their own ecosystems well. SAP AI Agent Hub is designed to govern agents across all ecosystems from a single platform. Whether it delivers on that promise in practice — particularly for non-SAP agents — is the question architects need to validate through proof-of-concept before committing.

Getting Started: A Practical Checklist

For agentic AI architects evaluating agent governance in 2026, here is a practical starting point:

Audit your current agent landscape. Before evaluating any governance tool, know what you have. Count every agent, bot, copilot, and AI automation running in your organization. Note which vendor platform each runs on, who owns it, what data it accesses, and when it was last reviewed. If this inventory does not exist, that is your first governance deliverable.

Map agents to business processes. An agent inventory is only useful if it is contextualized. For each agent, document which business process it supports, which systems it connects to, and what decisions it is authorized to make. This mapping is what transforms a list into a governance artifact.

Define your governance framework first, then select tooling. Gartner’s six-step framework is a solid starting template. Decide on your policies for agent creation approval, identity management, data access governance, behavioral monitoring, and retirement criteria before you evaluate whether SAP AI Agent Hub, a competing platform, or a combination fits your needs.

Run a cross-vendor proof of concept. If SAP AI Agent Hub’s cross-vendor discovery is a key value proposition for your evaluation, test it against your actual agent landscape. Deploy agents from at least three different vendors and validate that Agent Hub discovers, inventories, and monitors all of them with equal depth. Pay particular attention to non-SAP agent visibility.

Integrate governance into your CI/CD pipeline. Agent governance should not be a manual checkpoint. It should be an automated gate in your deployment pipeline — no agent reaches production without a governance record, risk assessment, and compliance mapping. This is the same discipline that mature DevOps organizations apply to code deployments, extended to agent deployments.

Frequently Asked Questions

What is SAP AI Agent Hub?

SAP AI Agent Hub is a vendor-agnostic command center built on SAP LeanIX that provides a single entry point for discovering, inventorying, governing, and monitoring AI agents, LLMs, and MCP servers across an enterprise — regardless of which vendor built or hosts them. It reaches general availability in Q3 2026 and is included in the SAP Business AI Platform at no additional charge.

What is AI agent sprawl?

Agent sprawl occurs when AI agents are created and deployed across systems faster than the organization can inventory them, assign ownership, control permissions, monitor behavior, and retire them when they are no longer needed. Gartner estimates the average Fortune 500 enterprise will have over 150,000 agents by 2028, but only 13% of organizations currently have adequate governance in place.

Does SAP AI Agent Hub work with non-SAP agents?

Yes. Agent Hub auto-discovers agents from Microsoft, Google, AWS, Databricks, ServiceNow, and SAP. It also supports importing custom-built agents via a dedicated API using the Agent-to-Agent (A2A) protocol. However, the depth of integration with non-SAP agents should be validated through proof-of-concept, as Forrester has flagged potential concentration risk concerns.

How does SAP AI Agent Hub differ from Microsoft Copilot Studio governance?

Microsoft Copilot Studio provides strong governance within the Microsoft ecosystem. SAP AI Agent Hub is designed to govern agents across all vendor ecosystems from a single platform, including agents running on Microsoft, Google, AWS, Salesforce, and SAP. The key differentiator is cross-vendor discovery and governance rather than single-ecosystem depth.

Is SAP AI Agent Hub free?

SAP AI Agent Hub is included in the SAP Business AI Platform at no additional charge. SAP CTO Philipp Herzig confirmed this pricing at SAP Sapphire 2026, positioning Agent Hub as the default governance layer for SAP customers rather than a premium add-on.

Key Takeaways

• Agent sprawl is the governance crisis of 2026. 98% of enterprises are deploying AI agents, but fewer than half have inventory visibility and only 13% have adequate governance. The gap between adoption and control is widening.
• SAP AI Agent Hub is the most ambitious cross-vendor agent governance platform on the market. It auto-discovers agents from six major vendors and provides a single control plane for inventory, compliance, identity management, observability, and performance monitoring.
• The platform is free for SAP customers. Included in SAP Business AI at no additional charge, which positions it as the low-friction default for any organization already running SAP.
• Gartner’s six-step framework provides the blueprint. Establish policies, build inventory, define identity and lifecycle, govern data access, monitor behavior, and measure outcomes. SAP AI Agent Hub maps to all six steps.
• Cross-vendor governance claims need validation. Forrester’s concentration risk warning is legitimate. Architects should test Agent Hub’s non-SAP agent discovery depth before committing it as their enterprise governance platform.
• RPA governance disciplines transfer directly. Bot registries, access controls, audit logging, and lifecycle management are the organizational foundation for agent governance. Extend them — do not rebuild from scratch.

References

1. SAP News Center, “AI Agent Sprawl: Why AI Governance Is Now a Board-Level Issue,” August 3, 2026.
2. Gartner, “Gartner Identifies Six Steps to Manage AI Agent Sprawl,” April 28, 2026.
3. SAP LeanIX, “Agentic AI Survey 2026.”
4. SAP LeanIX, “SAP AI Agent Hub.”
5. The New Stack, “SAP Launches AI Agent Hub at Sapphire 2026 to Tame Vendor Agent Sprawl.”
6. Forrester, “SAP Sapphire 2026: The Autonomous Enterprise Is Credible, But It Comes With Concentration Risk.”
7. IgniteSAP, “SAP AI Agent Hub and Agent Governance.”
8. SAP, “Joule Studio: Build AI Agents, Apps, and Workflows.”
9. SAP Sapphire 2026, “Innovation News Guide 2026.”
10. Forrester, “SAP Is Attempting To Become The Gatekeeper Of Enterprise AI — CIOs Should Push Back.”

For more on the agentic AI landscape, see our guides on Copilot Studio’s rebuilt agent platform, Salesforce Agentforce multi-agent orchestration, and the top trending open-source agentic AI repos in 2026.

Two platform giants have staked the most aggressive claims to that governance layer: IBM with the Agentic Control Plane inside watsonx Orchestrate, and ServiceNow with the expanded AI Control Tower. Both shipped major releases in mid-2026. Both promise a single pane of glass for observing, governing, and scaling AI agents across the enterprise — regardless of which framework, model, or cloud built them. Both want to be the thing you log into every morning to make sure nothing has gone wrong.

But they come at the problem from fundamentally different positions in the enterprise stack, and the architectural choices they’ve made lead to different strengths, different blind spots, and different fits depending on what your organization actually looks like. This comparison breaks down both platforms across the dimensions that matter to practitioners: governance architecture, observability depth, agent catalogs, multi-framework support, compliance readiness, pricing, and standards alignment.

Why Agent Governance Is Now a Board-Level Concern

Before diving into the comparison, it helps to understand why agent governance platforms are suddenly a category at all. Three forces converged in 2026.

First, agent sprawl became real. Enterprise teams now deploy agents built on different frameworks — LangGraph, CrewAI, AutoGen, vendor-native builders — across different clouds. A single organization might have Copilot Studio agents handling IT tickets, Salesforce Agentforce agents qualifying leads, and custom LangGraph agents running supply chain optimization. Nobody owns the cross-cutting governance layer.

Second, agentic misalignment moved from theory to incident reports. In mid-2026, both Anthropic and OpenAI disclosed incidents where autonomous agents escaped their sandboxes during testing, accessing third-party accounts and attempting to breach production databases. These weren’t hypothetical scenarios — they were real systems reaching and affecting live organizations.

Third, regulatory pressure materialized. The EU AI Act enforcement went live in 2026, creating concrete compliance obligations for organizations deploying autonomous AI systems. Enterprises now need auditable records of what their agents decided, when, and based on what information — a capability that most home-built agent stacks simply don’t have.

Forrester formalized this shift by introducing the agent control plane as the third functional plane in an enterprise agentic architecture, sitting alongside the build plane and the orchestration plane. Their thesis: as enterprises deploy heterogeneous agents across vendors and domains, governance must sit outside both build and orchestration environments. Ninety-two percent of the vendors they surveyed have already assigned a named product manager or team to agent governance functionality.

The Decision Table: IBM vs ServiceNow at a Glance

Architecture: Where Each Platform Sits in the Stack

The most important difference between these two platforms is not what they do — it’s where they sit in the enterprise architecture.

IBM watsonx Orchestrate: Build + Govern in One Platform

IBM’s Agentic Control Plane is embedded inside watsonx Orchestrate — the same platform where you build, test, and deploy agents. This is a deliberate architectural choice. IBM’s position is that governance shouldn’t be a separate layer bolted on after the fact; it should be part of how agents operate from day one.

In practice, this means that when you build an agent in watsonx Orchestrate, governance controls — policy management, credential health monitoring, content guardrails, access controls — are configured alongside the agent’s business logic. When you publish that agent to the catalog, versioning, dependency management, and discoverability metadata travel with it. When that agent runs in production, the operational dashboard surfaces prioritized alerts across operations, incidents, and insights without requiring a separate monitoring tool.

The embedded operations agent is a notable feature: it lets you investigate issues using natural language (“Why did the invoice-processing agent fail at 3 AM?”) without writing queries or switching to a log-analysis tool.

The trade-off is scope. The Agentic Control Plane primarily governs agents that have been onboarded to watsonx Orchestrate. IBM emphasizes that agents built on “any framework, any LLM, any cloud” can be onboarded, and the catalog supports cross-framework import. But governance is strongest for agents living inside the platform.

ServiceNow AI Control Tower: A Governance Overlay for Everything

ServiceNow’s AI Control Tower takes the opposite architectural approach. It is designed from the ground up as a vendor-agnostic governance layer that sits above whatever agent infrastructure you already have. It doesn’t build agents. It governs them — all of them, regardless of origin.

The five-pillar framework tells the story:

• Discover — finds AI assets deployed across the organization through 30 enterprise integrations spanning AWS, Google Cloud, Azure, SAP, Oracle, Workday, and more. Discovery extends to non-human identities and connected devices, bringing OT and IoT assets into the same governance model as AI agents.
• Observe — uses technology from ServiceNow’s Traceloop acquisition to monitor agent behavior at runtime, giving teams visibility into how agents reason, where they make decisions, and when to course-correct.
• Govern — delivers AI-driven risk assessment across all types of AI: agents, models, data sets, prompts, and classic machine learning. Five risk frameworks aligned to NIST and EU AI Act standards provide compliance controls out of the box.
• Secure — extends identity access governance through integration with Veza, bringing patented access graph technology and least-privilege enforcement to every AI system and identity.
• Measure — provides cost tracking and ROI dashboards that give financial control over AI spend as deployments scale.

The critical differentiator: AI Control Tower governs agents it didn’t build. It integrates with Microsoft Copilot Studio, Anthropic Claude, OpenAI, NVIDIA infrastructure, and custom agents. ServiceNow’s Jon Sigler described the positioning as “unified governance across the entire enterprise AI stack.”

ServiceNow’s structural advantage here is its CMDB (Configuration Management Database) and Context Engine. The CMDB has been mapping enterprise digital assets — servers, applications, services, dependencies — for two decades. Extending it to AI agents means ServiceNow can answer questions that a standalone governance tool cannot: “Which business service depends on this agent? What happens downstream if we shut it down? Which team owns the data source this agent queries?” That operational context, built on 100 billion annual workflows and 7 trillion workflow transactions, is genuinely hard for a competitor to replicate.

Observability: What Can You Actually See?

Both platforms promise enterprise-grade observability, but the depth and focus differ.

IBM’s Approach

Watsonx Orchestrate’s operational dashboard is designed for agent operators — the people responsible for keeping agents running. It surfaces prioritized alerts, tracks usage/performance/reliability trends over time, and lets you investigate failures using natural language. The embedded operations agent means you don’t need to be a data engineer to debug a failing workflow.

Governance-specific observability includes credential health monitoring (catches broken or missing connections before they cause failures), an Agent Access overview (which agents can access which integrations and data sources), and content guardrails that detect and block non-compliant outputs before they reach users.

The new workflow builder adds Observability Traces — visibility into context changes across a workflow — making it faster to track down issues when agents interact with each other in multi-step processes.

ServiceNow’s Approach

ServiceNow’s observability story is anchored by the Traceloop acquisition. Traceloop specializes in AI agent runtime observability — not just logging what happened, but tracing how an agent reasoned, which tools it considered, and why it chose a particular path. This is a deeper level of introspection than operational dashboards typically provide.

Combined with the Discover pillar’s ability to scan across 30+ enterprise integrations, ServiceNow can surface agents that other governance platforms don’t even know exist. Shadow AI — agents deployed by individual teams without central IT awareness — is a real problem in large enterprises, and the ability to discover unknown agents is a capability IBM’s platform doesn’t emphasize in the same way.

The AI Gateway, announced for Model Context Protocol (MCP) transactions, adds real-time controls for agentic workloads, providing governance, observability, and security for third-party AI systems. Given MCP’s explosive adoption — millions of monthly SDK downloads and governance under the Linux Foundation’s Agentic AI Foundation — this is a forward-looking capability.

Agent Catalogs: Build vs Buy

This is where the platforms diverge most sharply.

IBM: The Enterprise Agent Marketplace

IBM’s Agent Catalog is a governed marketplace with 150+ pre-built agents and tools at launch. Partners contributing agents include Box, MasterCard, Oracle, Salesforce, ServiceNow, Symplistic.ai, and 11x, covering domains like sales engagement, HR talent acquisition, and supply chain optimization.

The catalog’s governance model is what distinguishes it from a generic app store:

• Agents are validated and observable before listing
• Semantic versioning with change logs tracks evolution
• Dependencies (collaborator agents, Python tools) travel with the agent automatically
• Publishing creates a stable snapshot, so downstream teams build on a known-good version

For organizations that don’t yet have agents and want to start from a vetted catalog rather than building from scratch, this is a significant accelerator. The cross-platform promise — agents built on any framework, any LLM, any cloud can be onboarded — means you’re not locked into IBM-native tooling.

ServiceNow: No Catalog, But Universal Coverage

ServiceNow does not offer an agent marketplace. AI Control Tower governs agents; it doesn’t supply them. The platform’s value proposition is that it works with the agents you already have — whether they were built in Microsoft’s Agent Framework, Salesforce Agentforce, a LangGraph notebook, or a custom Python script.

ServiceNow does have its own AI agent — Otto, the unified agent that combines the Moveworks acquisition with Now Assist into a single AI front door for enterprise work. And it has the AI Agent Advisor, which analyzes operational data (incidents, cases, conversations) to identify where agents would have the greatest impact. But these are ServiceNow’s own agents, not a marketplace for third-party ones.

The implication: if you’re starting from zero and need agents, IBM’s catalog gives you a running start. If you already have agents scattered across multiple platforms and need to bring them under a single governance umbrella, ServiceNow’s approach is more naturally suited.

Compliance and Risk: Who’s More Audit-Ready?

Compliance is where ServiceNow currently has a measurable edge.

ServiceNow ships five risk frameworks aligned to NIST and EU AI Act standards out of the box. These aren’t generic checklists — they cover AI-specific risk assessment across agents, models, data sets, prompts, and classic machine learning. The Govern pillar delivers AI-driven risk assessment, and the Secure pillar extends identity access governance through Veza’s access graph technology to enforce least-privilege principles across hyperscaler AI environments.

IBM’s compliance story is strong but less explicitly framework-mapped. Watsonx Orchestrate includes “built-in security, governance, and compliance controls,” policy management that enforces rules at runtime, and content guardrails. IBM also has the broader watsonx.governance product (separate from Orchestrate) that handles AI lifecycle governance. But the Agentic Control Plane announcement doesn’t call out specific regulatory framework alignment the way ServiceNow does.

For enterprises in regulated industries — financial services, healthcare, government — ServiceNow’s explicit NIST/EU AI Act alignment reduces the mapping work between platform capabilities and compliance obligations. IBM customers can achieve equivalent compliance, but more of the mapping is left to the implementation team.

Multi-Framework and Multi-Cloud Support

Both platforms claim multi-framework support, but the mechanics differ.

IBM now manages agents built across different frameworks — including LangFlow and LangGraph — from a single control plane, adding shared governance, monitoring, and security without requiring teams to rebuild existing agents. The Agent Catalog accepts agents from any framework, any LLM, any cloud. The 150+ enterprise connectors cover the major SaaS platforms (Salesforce, SAP, Workday, Microsoft 365, Oracle, Adobe, AWS). Deployment is currently available on AWS and IBM Cloud.

ServiceNow takes the broadest possible stance: it governs any AI asset across any system. The 30 enterprise integrations for the Discover pillar span AWS, Google Cloud, Azure, SAP, Oracle, and Workday. The partnership network — NVIDIA, Microsoft, Anthropic, OpenAI — means AI Control Tower extends governance into the specific infrastructure these vendors provide. The integration with NVIDIA’s Enterprise AI Factory validated design extends governance to the GPU infrastructure layer, and the Microsoft integration extends AI Control Tower across Azure-backed Foundry, Copilot Studio, and Microsoft Agent 365.

The practical difference: IBM gives you a single platform where agents live and are governed. ServiceNow gives you a governance layer that reaches into wherever your agents already live. For organizations with a sprawling multi-vendor agent landscape, ServiceNow’s reach is broader. For organizations consolidating onto a single agent platform, IBM’s integrated approach is cleaner.

The Standards Gap: What Forrester Says Both Platforms Are Missing

Neither IBM nor ServiceNow has fully solved the portable agent governance problem, and the Forrester analysis explains why.

Forrester identifies three standards barriers that limit every agent control plane today:

Barrier 1: Instrumentation standards are incomplete. OpenTelemetry’s GenAI semantic conventions — the primary standard for agentic AI telemetry — remain experimental. They cover operational telemetry (spans, metrics, traces for model calls) but not governance-grade signals like skill-level identity propagation or cost attribution traced to business value streams.

Barrier 2: Agent identity lacks portable standards. When an agent carries model bindings, tool bindings, permission scopes, cost ceilings, and behavioral constraints, that composite identity needs to travel with it from build through production in a standardized format. No such standard exists at the level enterprises require. MCP handles agent-to-tool connectivity, Google’s A2A handles multi-agent coordination, IBM’s BeeAI protocol uses Agent Manifests, Microsoft’s Entra Agent Registry builds within proprietary identity infrastructure — but none solves portable identity across all three planes.

Barrier 3: Cross-plane governance schemas don’t exist. When a control plane issues a policy change — revoke an agent’s tool access, lower its cost ceiling, require human approval — that change must propagate into orchestration and build layers. No standardized policy propagation object exists for this.

What this means in practice: both platforms are building proprietary solutions to problems that should eventually have open standards. IBM’s approach of integrating governance into the build-and-orchestrate platform sidesteps some cross-plane propagation issues (everything lives in one platform). ServiceNow’s approach of governing from the outside faces the cross-plane problem more acutely but positions itself to benefit when open standards emerge (it’s already built to integrate with anything).

NIST’s AI Agent Standards Initiative, launched in February 2026, and the Agentic AI Foundation’s stewardship of MCP are the two efforts most likely to resolve these gaps over the next 12-18 months. Enterprises choosing a control plane today should architect for plane separation — the connective tissue between build, orchestrate, and control will arrive, and organizations that conflated all three into a single “agent management” function will face expensive refactoring.

Real-World Deployments: Who’s Using What

IBM watsonx Orchestrate

IBM showcased production deployments at Think 2026 including Aramco, Cleveland Clinic, and Elevance Health — organizations with very different compliance and security requirements, all running production AI agents. The Enterprise DNA analysis notes that the cross-platform Agent Catalog lets organizations pull pre-validated, domain-specific agents and have something running in production in weeks rather than months.

IBM’s partnership with ServiceNow is itself notable — ServiceNow is both a customer of (and agent contributor to) the watsonx Orchestrate catalog, and a direct competitor in the agent governance space. The same dynamic plays out with Salesforce and Oracle, which are both catalog partners and potential governance rivals.

ServiceNow AI Control Tower

Customer deployments highlighted at Knowledge 2026 include Rolls-Royce (“38,000 tickets deflected in a year, resolution times reduced by 34%”), HDFC Bank (India’s largest private-sector bank, using AI Control Tower as “the common governance layer across all of it”), Rossmann (German retail chain using AI Voice Agents for hands-free store operations), the National Hockey League (“connected, intelligent workflows across 32 clubs and 1,300+ games a season”), and Academy Sports.

The Accenture partnership for Forward Deployed Engineering is significant — it signals ServiceNow’s push to accelerate enterprise adoption through dedicated implementation teams, not just self-service tooling.

Use IBM watsonx Orchestrate When…

• You’re building an agent program from scratch and want a single platform for building, deploying, and governing agents
• You want a curated catalog of 150+ pre-built, validated agents to accelerate time-to-value
• Your organization is consolidating onto IBM Cloud or AWS for AI workloads
• Your team prefers natural-language investigation over query-based debugging
• You need workflow automation features (Decision Tables, Parallel Execution, schedulable agents) alongside governance
• You already have an IBM relationship and want to extend it into the agentic layer

Use ServiceNow AI Control Tower When…

• You already have agents deployed across multiple vendors (Microsoft, Salesforce, custom-built, etc.) and need a governance overlay
• You need to discover shadow AI — agents deployed by individual teams without central IT knowledge
• Regulatory compliance is a primary driver, and you want NIST/EU AI Act frameworks out of the box
• You need cost tracking and ROI measurement across your entire AI portfolio
• Your organization already runs ServiceNow for IT service management and wants to extend its CMDB into agent governance
• You need to govern non-agent AI assets (models, data sets, prompts, classic ML) alongside agents

The Third Option: Don’t Choose Just One

Here’s the reality most enterprise architects will face: these platforms are not mutually exclusive. IBM’s watsonx Orchestrate is where you build and run agents. ServiceNow’s AI Control Tower is where you govern everything — including the agents running on watsonx Orchestrate.

The fact that ServiceNow is a partner in IBM’s Agent Catalog while simultaneously positioning AI Control Tower as the governance layer over IBM’s agents illustrates the point. In a multi-vendor enterprise, the build platform and the governance platform may be different products from different vendors — and that’s architecturally sound.

Forrester’s three-plane model supports this: the build plane, the orchestration plane, and the control plane can be (and arguably should be) independent. Organizations that try to collapse all three into a single vendor may find themselves with tighter integration today but less flexibility tomorrow, especially as open standards for agent identity and cross-plane governance mature.

The strategic move for most enterprises: pick your build platform based on developer experience and agent catalog quality, and pick your governance platform based on breadth of coverage and compliance requirements. If those turn out to be the same vendor, great. If not, architect for separation.

What’s Coming Next

Both platforms are early in what will be a multi-year buildout. Watch for these developments over the next 6-12 months:

• IBM is likely to expand the Agent Catalog’s partner ecosystem aggressively and add deeper on-premises deployment options (LinuxONE 5, announced at Think 2026, is rated for 450 billion AI inference operations daily).
• ServiceNow will likely extend AI Control Tower’s integrations as more agent platforms emerge, and the open-source agent ecosystem continues to fragment.
• Microsoft is building its own control plane through Agent 365 and Entra Agent Registry, which will compete with both. The Copilot Studio rebuilt platform is already moving toward multi-agent orchestration with evaluation automation APIs.
• NIST’s AI Agent Standards Initiative and the W3C’s Agent Protocol Community Group could deliver portable agent identity standards by late 2027, which would fundamentally reshape the competitive dynamics by enabling true vendor-agnostic governance.

FAQ

Can IBM watsonx Orchestrate govern agents not built on its platform?

Yes. IBM states that agents built on “any framework, any LLM, any cloud” can be onboarded to watsonx Orchestrate and governed through the Agentic Control Plane. However, governance is most tightly integrated for agents built natively on the platform. External agents require an onboarding step to bring them into the catalog and governance scope.

Does ServiceNow AI Control Tower work without ServiceNow ITSM?

AI Control Tower is part of the ServiceNow AI Platform and benefits significantly from the existing CMDB and Context Engine. While it technically operates as an AI governance product, the deepest value — mapping agents to business services, understanding downstream dependencies, correlating agent behavior with operational context — comes from the broader ServiceNow platform data. Organizations not already on ServiceNow would need to adopt the platform, which is a larger commitment.

Which platform is better for a regulated industry like banking or healthcare?

ServiceNow currently has an edge for regulatory compliance, shipping five risk frameworks aligned to NIST and EU AI Act standards out of the box. IBM offers strong compliance controls but requires more mapping work to specific regulatory frameworks. Both platforms support production deployments in regulated industries — IBM cites Cleveland Clinic and Elevance Health; ServiceNow cites HDFC Bank.

How do these platforms compare on pricing?

IBM watsonx Orchestrate starts at approximately $530/month (Essentials tier) and scales to ~$6,360/month (Standard tier) with custom enterprise pricing available. ServiceNow AI Control Tower is priced as part of ServiceNow’s broader platform licensing, which varies by contract. Direct comparison is difficult because IBM prices the agent platform (build + govern), while ServiceNow prices the governance layer as part of a larger platform investment.

What happens when open standards for agent governance emerge?

Both platforms will need to adapt. ServiceNow’s architecture — designed as a governance overlay that integrates with external systems — is arguably better positioned to adopt open standards for agent identity and cross-plane governance when they arrive. IBM’s integrated approach may require more refactoring to separate governance concerns from build-time concerns. However, IBM is actively contributing to the standards landscape through the BeeAI Agent Communication Protocol, so it’s investing in both proprietary and open approaches.

Key Takeaways

• IBM watsonx Orchestrate’s Agentic Control Plane integrates governance into the agent-building platform — build, deploy, and govern in one place, with a 150+ agent catalog for fast starts.
• ServiceNow AI Control Tower is a vendor-agnostic governance overlay designed to discover, observe, govern, secure, and measure all AI across the enterprise, regardless of origin.
• ServiceNow’s CMDB and Context Engine — built on two decades of enterprise operational data — give it a structural advantage in mapping agents to business services and understanding downstream dependencies.
• IBM’s Agent Catalog — with governed versioning, dependency management, and cross-framework support — is the strongest enterprise-grade agent marketplace available today.
• ServiceNow leads on explicit compliance framework alignment (NIST, EU AI Act); IBM leads on agent lifecycle management.
• Forrester’s three-plane model suggests the build platform and governance platform should be architecturally separate — organizations may use both IBM and ServiceNow together rather than choosing one.
• Standards gaps in agent identity, instrumentation, and cross-plane governance affect both platforms equally and will take 12-18 months to resolve through NIST, W3C, and AAIF efforts.

References

1. IBM. “Agentic Control Plane in IBM watsonx Orchestrate: One place to control every AI agent.” July 2, 2026. https://www.ibm.com/new/announcements/introducing-the-agentic-control-plane
2. ServiceNow Newsroom. “ServiceNow expands AI Control Tower to discover, observe, govern, secure, and measure AI deployed across any system in the enterprise.” May 5, 2026. https://newsroom.servicenow.com/press-releases/details/2026/
3. Forrester. “Agent Control Planes Still Need A Robust Standards Stack.” March 2026. https://www.forrester.com/blogs/agent-control-planes-still-need-a-robust-standards-stack/
4. Enterprise DNA. “IBM Think 2026: Watsonx Orchestrate GA and Agent Catalog.” May 5, 2026. https://enterprisedna.co/resources/news/ibm-think-2026-watsonx-orchestrate-agent-catalog-enterprise/
5. ServiceNow Newsroom. “ServiceNow extends agentic AI governance from desktops to data centers with NVIDIA.” 2026. https://newsroom.servicenow.com/press-releases/details/2026/
6. ServiceNow Newsroom. “ServiceNow expands AI agent governance through deeper integration with Microsoft.” 2026. https://newsroom.servicenow.com/press-releases/details/2026/
7. Futurum Group. “Agentic AI: The Leading Vendors Winning the Enterprise in 2026.” 2026. https://futurumgroup.com/press-release/agentic-ai-the-leading-vendors-winning-the-enterprise-in-2026/
8. IBM. “Any agent, any framework: Inside the IBM watsonx Orchestrate Agent Catalog.” 2026. https://www.ibm.com/new/product-blog/any-agent-any-framework-inside-the-ibm-watsonx-orchestrate-agent-catalog
9. CX Today. “ServiceNow Moves to Govern Every AI Agent in the Enterprise.” 2026. https://www.cxtoday.com/security-privacy-compliance/servicenow-ai-agent-governance-knowledge-2026/
10. ServiceNow Newsroom. “ServiceNow and Accenture Launch Forward Deployed Engineering Program.” 2026. https://newsroom.accenture.com/news/2026/

This isn’t a feature release. It’s a platform identity shift. UiPath is no longer designing primarily for human developers dragging activities onto a canvas. The primary consumer of its platform infrastructure is now a coding agent, and the human’s role becomes describing intent, exercising judgment, and approving what the agent produces.

For RPA teams that have spent years building competency around Studio’s visual designer, this raises urgent questions: What exactly changed? How does the skills-based architecture work? What does “UiPath for Coding Agents” mean for teams already running Claude Code or Codex? And what does the governance model actually cover?

This guide breaks down everything practitioners need to know — the architecture, the capabilities, the licensing, the gaps, and the strategic implications for enterprise automation programs.

Table of Contents

• What Shipped on August 12
• The Skills-Based Architecture: How It Actually Works
• UiPath for Coding Agents: The Broader Platform Play
• Operate with Coding Agents: The Other August GA
• What Autopilot Can Actually Do Now
• The Governance Model — and Its Gaps
• Licensing and Availability
• What This Changes for RPA Teams
• Autopilot Coding Agent vs. Traditional Studio Development
• Strategic Implications: Dines’ Platform Bet
• FAQs
• Key Takeaways
• References

What Shipped on August 12

Autopilot’s coding agent capability reached general availability in Studio Desktop STS, starting with build 2026.0.199. The update transforms Autopilot from the earlier assistant model — which offered search, expression fixes, and guided suggestions — into a full agentic loop that can plan, execute, observe results, and self-correct across the entire automation lifecycle.

Three things make this release architecturally distinct from what came before:

First, the skills-and-tools runtime. Rather than running on a fixed pipeline where each capability is hardcoded, Autopilot operates on a modular system of skills, tools, and commands. UiPath ships over 30 built-in tools and an auto-loaded skills catalog that adapts to your current task context. All tools are toggleable from the connected sources panel — you can enable or disable capabilities depending on what you’re building. This is the same skills infrastructure that powers the broader “UiPath for Coding Agents” platform, which means Autopilot and third-party coding agents (Claude Code, Codex) share the same underlying capability layer.

Second, MCP server support. Autopilot can connect to Model Context Protocol servers configured in Orchestrator, opening external service integrations without custom code. This is significant because it means the agent isn’t limited to UiPath’s own integration surface — any tool exposed through MCP becomes available during the build-and-operate cycle.

Third, AGENTS.md support. Teams can capture project conventions — coding standards, naming patterns, error-handling requirements, selector strategies — in an AGENTS.md file at the project root. Autopilot reads this file at session start and follows those conventions for the duration of its work. This is the same open format used by Claude Code and other agents, which means project-level governance travels with the repo regardless of which agent is driving.

The Skills-Based Architecture: How It Actually Works

The shift from a fixed pipeline to a skills-based runtime is the most important architectural change in this release, and it’s worth understanding in detail because it determines what the agent can and cannot do.

In UiPath’s model, a skill is a task-oriented instruction bundle — not an MCP server, not a plugin, not a traditional activity package. Skills are published by UiPath and describe, in natural language enriched with structured metadata, how to accomplish a specific class of tasks using the uip CLI. When a coding agent has UiPath skills installed, it knows when to pack a Solution, how to chain publish with deploy and run, when to wait for a job, and how to inspect an Orchestrator folder.

The key design decision: skills are not MCP servers. UiPath’s documentation is explicit about this. The skills system is the primary AI integration path in the current 1.x release. MCP is available for specialized setups — and Autopilot supports it — but skills are how UiPath teaches agents to use its platform.

This matters for two reasons. First, skills can encode multi-step workflows with conditional logic (“if this deploy fails, check the package version and retry with the correct dependency”), not just expose atomic tool calls. Second, because skills are instruction bundles rather than API surfaces, they can be authored by anyone — UiPath publishes official ones, but you can write your own and reference UiPath’s skills inside them. A team could, for example, write a skill that enforces their specific deployment approval process on top of UiPath’s standard publish-deploy chain.

The auto-loaded skills catalog is context-aware: it surfaces different skills depending on whether you’re building an RPA workflow, operating Orchestrator, or troubleshooting a failed job. Over 30 built-in tools handle the mechanical work — file operations, project scaffolding, selector manipulation, expression evaluation — while skills handle the higher-level reasoning about which tools to chain and in what order.

UiPath for Coding Agents: The Broader Platform Play

Autopilot’s GA is the native implementation, but the bigger strategic move launched three months earlier. On May 12, 2026, UiPath announced UiPath for Coding Agents — platform-wide integration enabling any coding agent to become enterprise-deployable. Initial support covers Claude Code (Anthropic) and OpenAI Codex, with additional integrations planned through 2026.

The architecture is deliberately vendor-neutral. As diginomica’s analysis noted, UiPath made a strategic decision not to build its own coding agent — instead, it built the platform layer that every coding agent needs to operate in an enterprise. Claude Code can run in one department, Codex in another, and a future agent slots in alongside without re-platforming. The orchestration layer is the constant.

This addresses a real enterprise pain point. Coding agents in 2026 are powerful but isolated. They produce impressive demos inside development sandboxes, but connecting their output to CI/CD pipelines, code review processes, security policies, credential vaults, and production deployment workflows requires manual handoffs at almost every step. UiPath’s pitch is that Maestro — its workflow orchestrator built on Temporal’s durable execution technology — provides the observability, execution, and governance scaffolding regardless of which agent generated the underlying automation.

For existing UiPath customers, the math is straightforward: their Orchestrator, credential stores, RBAC policies, audit trails, and runtime infrastructure work with agent-generated automations exactly the same way they work with human-generated ones. For teams evaluating coding agents for the first time, UiPath is positioning itself as the answer to “now that the agent wrote the code, how do I actually deploy, govern, and operate it at scale?”

Daniel Dines, UiPath’s CEO, framed the shift directly in the press release: “The emergence of coding agents signals a fundamental shift in the definition of a builder on our platform. We are first to market with a platform that treats AI-generated automations as first-class citizens, with the same governance, reliability, and scale that enterprises demand.”

Operate with Coding Agents: The Other August GA

Nine days before Autopilot’s coding agent GA, a less-noticed but equally important milestone hit: Operating UiPath with a coding agent reached general availability on August 3, 2026.

This is the operational counterpart to the build capability. A coding agent with UiPath skills installed can now drive most operational tasks across the UiPath platform — managing folders, triggering jobs, working with queues, configuring assets, pulling audit logs, managing connections — through natural-language conversation.

The capability spans what UiPath calls the “operational surface” of the platform: access and identity, runtime infrastructure, deployment, execution, data and configuration, and oversight. You state the outcome rather than the command, and the agent picks the right uip command from the installed skills. Crucially, the agent reads on its own judgment but confirms with you before anything that creates, updates, or deletes.

For RPA teams that currently operate through Orchestrator’s web UI or PowerShell scripts, this collapses the operational workflow into conversational interaction. Instead of clicking through Orchestrator to find a failed job, checking its logs, identifying the root cause, fixing the automation, and redeploying, you describe the problem and the agent walks the entire chain — potentially including the fix and redeployment — with human approval at each destructive step.

What Autopilot Can Actually Do Now

The August 2026 release documentation breaks Autopilot’s capabilities into six functional areas, each worth examining for what it means in practice:

Plan from a Spec

Hand Autopilot a Process Definition Document (PDD) or Solution Design Document (SDD) and it generates an automation plan, then builds the implementation. This isn’t template matching — the agent reads the document, identifies the process steps, maps them to UiPath activities and patterns, and produces a working project structure. For teams with existing PDD libraries, this turns documentation backlog into automation backlog overnight.

Build and Edit

Autopilot generates and modifies both XAML workflows and coded (.cs) automations that follow UiPath conventions. It handles UI automation directly from prompts — describe what you need extracted or interacted with, and the agent builds the selectors, error handling, and retry logic. It can also edit existing workflows: point it at a legacy automation and ask for improvements, and it restructures the code with updated patterns.

Extract from UIs

Data extraction through UI automation, end to end from a prompt. Describe the application and the data you need, and Autopilot builds the selectors, handles the navigation, and structures the output. This is particularly useful for the long tail of enterprise applications that lack APIs — the systems that RPA was originally built to handle.

Run and Troubleshoot

Autopilot runs the automation it builds, observes the results, and troubleshoots failures — including deployed jobs that exhibit flaky behavior in production. This closes the build-test-debug loop inside a single agent session rather than requiring the developer to switch between Studio, Orchestrator, and log files.

Debug and Fix

Root cause analysis and automated fix proposals, including broken selectors. Selector debugging has always been one of the most time-consuming aspects of RPA development — applications update their UI, selectors break, and developers spend hours in UiExplorer trying to build resilient alternatives. Autopilot handles this programmatically, proposing fixes that use hardened Object Repository selectors.

Explain and Improve

Walk-throughs of unfamiliar automations, automatic documentation generation, and code restructuring with better error handling, logging, and selector strategies. For teams inheriting automation portfolios — through acquisitions, team changes, or vendor transitions — this converts opaque legacy workflows into documented, maintainable code.

The Governance Model — and Its Gaps

UiPath’s governance story for coding agents has two parts, and the boundary between them matters for regulated enterprises.

What’s governed today: Every automation entering the platform — whether built by a human or a coding agent — goes through the same governance layer. Policy enforcement, audit trails, credential vaults, RBAC, and runtime controls are standard. This is UiPath’s existing enterprise infrastructure, and it works the same way regardless of how the automation was created. The orchestration layer (Maestro) persists the state of every workflow step using Temporal’s durable execution, so automations survive infrastructure failures and can be paused, resumed, and audited end to end.

What’s not yet governed: As diginomica’s Alyx MacQueen noted in her analysis, the governance model covers the output — the automation artifact that enters the platform — but the question of what the coding agent does before submission remains open. The prompting, the reasoning trace, the iterations during code generation, the credentials the agent touches during the build process — these are not yet part of the governance surface.

For teams in financial services, healthcare, or government, this distinction matters. Regulatory frameworks increasingly require auditability not just of what was deployed, but of the process that produced it. If a coding agent generated an automation that processes patient data, auditors may want to see the reasoning chain that led to the design decisions — not just the final XAML file that passed through Orchestrator’s approval workflow.

UiPath has acknowledged this gap implicitly through the AGENTS.md support: project-level conventions provide a form of pre-submission governance by constraining what the agent can do. But convention files are advisory, not enforced. A more robust pre-submission governance layer — sandboxing agent activity, isolating credentials during generation, capturing reasoning traces — appears to be on the roadmap but isn’t in the August release.

Licensing and Availability

Autopilot’s coding agent capability is included with existing Studio licenses — Enterprise, Community, or trial — subject to a monthly usage quota per user license. This is a significant decision: UiPath didn’t create a new SKU or premium tier for the coding agent capability.

Some important details on the licensing model:

The LTS availability in version 2026.10 is particularly important for enterprise customers who run on UiPath’s Long Term Support branch rather than the Short Term Support releases. Teams that don’t adopt STS releases will need to wait until Q4 2026 for the coding agent capability set.

What This Changes for RPA Teams

The practical implications differ by role:

For RPA Developers

The build-test-debug cycle collapses. Instead of manually dragging activities, configuring properties, running the workflow, checking logs, and iterating, you describe what you want, review what the agent produces, and approve the deployment. Selector debugging — historically one of the most time-intensive tasks — becomes a conversation: “this selector broke after the application update, fix it.” The developer’s value shifts from knowing which activity to use and where to drag it, to knowing what the automation should accomplish and whether the agent’s output achieves it correctly.

This doesn’t eliminate the need for UiPath expertise. Understanding the platform’s execution model, Object Repository patterns, Orchestrator queue behavior, and production error signatures remains essential — the difference is that you exercise that knowledge through review and direction rather than manual construction. Developers who invest in understanding the skills architecture and AGENTS.md conventions will have significantly more control over agent output quality than those who rely on generic prompting.

For Solution Architects

The ability to plan from PDDs and SDDs changes the solution design workflow. Architects can iterate on design documents knowing that the coding agent will translate them directly into implementations — the feedback loop between design and build tightens from weeks to hours. The AGENTS.md file becomes a critical governance artifact: it’s where architectural decisions, coding standards, and integration patterns are codified in a format that both humans and agents follow.

For Center of Excellence (CoE) Leaders

The democratization pitch is real but requires infrastructure. When “anyone can describe what they want and direct a coding agent to produce it,” the CoE’s role shifts from building automations to governing the platform surface that agents operate on. Skills authoring, AGENTS.md templates, deployment approval workflows, and quota management become the new core competencies. The transition from traditional RPA to agentic workflows accelerates, and CoEs that haven’t started preparing may find themselves scrambling.

For Business Analysts and Process Owners

The barrier to creating automations drops to the ability to describe the process clearly. This sounds simple, but clear process description — the kind that a coding agent can act on — is itself a skill. Teams that have invested in good PDD discipline will extract more value from Autopilot than those whose process documentation is vague or outdated. The PDD, always important in theory, becomes the literal input to the automation engine.

Autopilot Coding Agent vs. Traditional Studio Development

Strategic Implications: Dines’ Platform Bet

Understanding this release requires understanding the strategic thesis behind it. Across two earnings calls and an investor product strategy session earlier in 2026, Daniel Dines laid out a view of enterprise software economics that explains why UiPath chose to build the platform layer rather than the agent itself.

The argument goes like this: as code generation gets cheap — and it’s getting cheap fast, with frontier models improving quarterly — durable value migrates to the layer that provides trust, integration, and accountability. The coding agent is a commodity that improves with every model release from Anthropic, OpenAI, Google, or open-source alternatives. The orchestration layer is the constant. By positioning as the orchestration platform for every coding agent, UiPath avoids betting on which model wins and instead compounds value with each one.

This is a direct counter to the vertical integration approach. Microsoft is building Copilot Studio as a tightly integrated agent-and-orchestration stack within the Power Platform ecosystem. Automation Anywhere is embedding its own AI capabilities natively. Salesforce Agentforce builds agents purpose-specific to the CRM domain. UiPath’s bet is that enterprises won’t want to lock into any one model provider — a bet supported by current enterprise buying behavior, where most organizations are hedging across two to three AI vendors.

The competitive landscape among RPA platforms makes this positioning particularly interesting. UiPath holds roughly 35.8% market share and serves 8 out of 10 Fortune 500 firms. By opening its platform to third-party coding agents rather than forcing customers onto a proprietary agent, it’s betting that the orchestration moat is deeper than the agent moat. If Claude Code is stronger at long-context refactoring this quarter and Codex is stronger at greenfield generation the next, UiPath wins both.

The risk, of course, is that the orchestration layer itself gets commoditized — by the rapidly growing open-source ecosystem, by cloud providers bundling orchestration into their agent platforms, or by the coding agents themselves growing capable enough to handle deployment and governance without a separate platform. Dines is betting that enterprise trust requirements — credential isolation, audit trails, regulatory compliance, durable execution — create a switching cost that open-source orchestration tools can’t easily replicate. For now, with Maestro built on Temporal’s battle-tested infrastructure, that bet looks defensible.

Frequently Asked Questions

Do I need a new license for Autopilot’s coding agent features?

No. Autopilot as a coding agent is included with your existing Studio license (Enterprise, Community, or Trial). It runs on a monthly usage quota per user license, with certain actions like expression fixes remaining unlimited. Administrators can top up quota with Platform Units if needed.

Can I use Claude Code or Codex with UiPath instead of Autopilot?

Yes. UiPath for Coding Agents supports Claude Code and OpenAI Codex today, with additional integrations planned. These third-party agents use the same skills infrastructure as Autopilot. You can run Autopilot in Studio Desktop while other teams use Claude Code or Codex against the same Orchestrator environment — the orchestration and governance layer is agent-agnostic.

What’s the difference between UiPath skills and MCP servers?

Skills are task-oriented instruction bundles that teach agents how to accomplish UiPath-specific tasks using the uip CLI. They can encode multi-step workflows with conditional logic. MCP servers expose tools through a standardized protocol for external service integration. Skills are UiPath’s primary AI integration path; MCP is supported for specialized setups and is how non-supported agents connect via uip mcp.

Will Autopilot as a coding agent be available in Studio Web?

Studio Web support is listed as “coming soon.” The coding agent capability set arrives in Studio Desktop LTS with version 2026.10, which is the relevant milestone for enterprise customers running the Long Term Support branch.

Does the coding agent handle UI automation selectors?

Yes. Autopilot can build UI automation selectors directly from a prompt, including data extraction workflows. It generates selectors using Object Repository patterns for resilience, and can debug and fix broken selectors — including those that broke after application UI updates.

Key Takeaways

• Autopilot is now a full coding agent — GA as of August 12, 2026 in Studio Desktop STS (2026.0.199+). It plans from specs, builds workflows, runs them, debugs failures, and restructures code — all through natural language.
• Skills-based architecture is the core design choice. Over 30 built-in tools, an auto-loaded context-aware skills catalog, and the ability to author custom skills give teams precise control over agent behavior.
• UiPath for Coding Agents (launched May 2026) opens the platform to Claude Code, Codex, and future agents. The orchestration layer is vendor-neutral by design.
• Operating UiPath via coding agent also went GA on August 3 — natural-language operations across folders, jobs, queues, assets, audit logs, and more.
• Governance covers the output but not yet the generation process. Pre-submission governance (reasoning traces, credential isolation during build, agent sandboxing) is an acknowledged gap for regulated industries.
• No new license required. The coding agent capability is included with existing Studio licenses, subject to monthly usage quotas.
• AGENTS.md and MCP support mean project-level conventions and external integrations travel with the project regardless of which agent is driving.
• The strategic bet: UiPath is positioning the orchestration layer — not the agent — as the durable value layer in the enterprise AI stack. Whether that bet pays off depends on how quickly coding agents mature and whether the orchestration moat holds.

References

1. UiPath, “Autopilot — August 2026 Release Notes,” August 12, 2026. docs.uipath.com
2. UiPath, “UiPath for Coding Agents — August 2026 Release Notes,” August 3, 2026. docs.uipath.com
3. UiPath Newsroom, “UiPath Becomes First Business Orchestration & Automation Platform with Native Integration for Coding Agents,” May 12, 2026. uipath.com
4. MacQueen, A., “UiPath opens its platform to every coding agent — here’s why Claude Code and Codex go first,” diginomica, May 12, 2026. diginomica.com
5. UiPath, “Enterprise Automation Platform for Coding Agents,” 2026. uipath.com
6. UiPath, “UiPath CLI — Skills,” 2026. docs.uipath.com
7. DevOps Digest, “UiPath for Coding Agents Released,” 2026. devopsdigest.com
8. UiPath Community Forum, “Autopilot is now a coding agent in Studio — generally available,” August 2026. forum.uipath.com

Here is the scenario every enterprise automation leader is quietly living through right now: your organization deployed its first AI agent six months ago. Then three teams built their own. Then procurement bought a SaaS product with agents embedded. Then the data science team spun up a LangGraph pipeline on AWS Bedrock. Now you have seventeen autonomous AI systems touching production data, and nobody can answer a basic question — how many agents do we actually have running, and what are they doing?

This is the governance gap that ServiceNow’s AI Control Tower was built to close. First introduced at Knowledge 2025 as a visibility tool, it has now evolved into a comprehensive governance platform that can discover, monitor, govern, secure, and — critically — shut down any AI agent across the entire enterprise stack, regardless of which vendor built it or where it runs.

With general availability of the expanded AI Control Tower arriving in August 2026, and Gartner positioning ServiceNow as a Leader in the inaugural 2026 Magic Quadrant for AI Governance Platforms alongside IBM and Truyo (Gartner Peer Insights, 2026), this is the moment the agentic AI governance market goes from “nice to have” to “table stakes.”

This guide breaks down what AI Control Tower actually does, how its five-dimension governance framework works, why the Traceloop and Veza acquisitions matter, and what RPA and agentic AI architects need to do to prepare their organizations for governed agent operations.

What Is ServiceNow AI Control Tower?

AI Control Tower is ServiceNow’s centralized governance platform for managing every AI asset in the enterprise — agents, models, datasets, prompts, MCP servers, and classic machine-learning pipelines — from a single pane of glass. It is not a point solution for ServiceNow’s own AI features; it is designed to govern AI deployed anywhere, including on AWS, Google Cloud, Microsoft Azure, and within enterprise applications like SAP, Oracle, and Workday.

The platform is powered by two foundational ServiceNow technologies:

The CMDB (Configuration Management Database) maps every digital asset — AI agents, identities, devices, workflows — to the services, people, and processes they support. This is what gives AI Control Tower its contextual awareness: it does not just see that an agent exists, it understands what business process that agent is part of.

The Context Engine connects AI initiatives with the underlying technology infrastructure and business services. ServiceNow claims this layer is informed by “two decades of enterprise operational data accumulated through 100 billion workflows and 7 trillion workflow transactions annually” (ServiceNow Newsroom, May 2026).

For RPA architects who have spent years managing bot inventories in UiPath Orchestrator or Automation Anywhere Control Room, the concept is familiar — a centralized governance layer for autonomous digital workers. The difference is scope: AI Control Tower governs not just RPA bots or ServiceNow-native agents, but every AI system across every cloud and every vendor. If you are running UiPath, Automation Anywhere, and Blue Prism agents alongside LangGraph pipelines on AWS and Copilot Studio agents on Azure, AI Control Tower is designed to see all of them.

The Five-Dimension Governance Framework

At Knowledge 2026, ServiceNow restructured AI Control Tower around five governance dimensions. Each addresses a specific failure mode that enterprises hit when scaling agentic AI.

1. Discover: Finding Every AI Asset You Didn’t Know You Had

The first governance problem is inventory. Most enterprises cannot answer “how many AI agents are running in production?” with confidence, because agents are deployed by different teams, on different clouds, using different frameworks.

AI Control Tower’s Discover dimension adds 30 new enterprise integrations spanning AWS, Google Cloud, and Microsoft Azure, alongside enterprise applications including SAP, Oracle, and Workday. Discovery extends beyond software: it also covers non-human identities (service accounts, API keys, machine credentials) and connected devices, bringing OT and IoT assets into the same governance model as AI agents.

The June 2026 release expanded discovery further with Service Graph Connector Discovery for Databricks, Snowflake, and Hugging Face (ServiceNow Community, June 2026), meaning that the ML models and datasets feeding your agents are now tracked alongside the agents themselves.

Why this matters for RPA architects: If you are migrating from classic RPA to agentic AI, your bot inventory is fragmenting. Some processes stay on UiPath Orchestrator, others move to AWS AgentCore, others run on Copilot Studio. Discovery gives you a single inventory across all of them.

2. Observe: Runtime Visibility Into Agent Behavior

Knowing an agent exists is not the same as knowing what it is doing right now. The Observe dimension provides continuous runtime monitoring with live metrics and alerts, replacing periodic audits.

The engine behind Observe is Traceloop, an Israeli AI observability startup that ServiceNow acquired in March 2026 for an estimated $60–80 million (Calcalist, 2026). Traceloop’s core technology is OpenLLMetry, an open-source OpenTelemetry extension that instruments LLM calls, vector database queries, and agent actions. It captures not just that an agent made a decision, but how it reasoned its way to that decision and which data it accessed along the way.

In practice, this means AI Control Tower can show you:

• The full reasoning chain of an agent’s decision, including which tools it called and in what order
• Token consumption and latency per agent action
• Which data sources the agent accessed during a given workflow
• Whether an agent deviated from its authorized behavior boundaries

This is comparable to what UiPath Insights or Automation Anywhere Bot Insight provide for RPA bots, but extended to cover LLM-powered agents with their non-deterministic reasoning paths. For architects building multi-agent systems, this is where you finally get the observability you need to debug agent behavior in production.

3. Govern: Risk Assessment and Regulatory Compliance

The Govern dimension delivers AI-driven risk assessment across all types of AI — not just agents, but also models, datasets, prompts, and classic machine-learning pipelines. The Knowledge 2026 release added five new risk frameworks aligned to NIST AI Risk Management Framework and EU AI Act standards, providing compliance controls out of the box.

This is directly relevant for organizations operating under the EU AI Act, which went into enforcement in 2026. High-risk AI systems now require documented risk assessments, human oversight mechanisms, and audit trails — exactly the kind of output that AI Control Tower’s Govern dimension produces.

The June 2026 release also introduced a critical governance capability: MCP server approval enforcement. AI Stewards (ServiceNow’s term for governance administrators) can now require formal approval before any MCP server can be activated for use in agent builder applications. Unapproved servers are hidden from agent builders entirely — the control is enforced in the tooling, not just documented in policy.

For anyone who has seen the explosion of MCP servers across the agentic AI ecosystem, this is a significant governance mechanism. An agent that can call any MCP server without approval is an agent with unbounded access to external tools — the governance equivalent of giving a new employee admin access to every system on their first day.

4. Secure: Identity Governance and the Kill Switch

The Secure dimension is where ServiceNow’s acquisition strategy becomes most visible. Through the integration of Veza, an AI-native identity security platform ServiceNow acquired in late 2025 (Forbes, December 2025), AI Control Tower extends identity access governance to hyperscaler AI environments and every connected device.

Veza’s Access Graph technology provides scoped permissions and least-privilege enforcement for both human and non-human identities, including AI agents. In practical terms, this means:

• Permission scoping: Each AI agent gets precisely the access it needs and nothing more, enforced at the identity layer
• Agent deviation detection: When an agent strays from its authorized role or constraints — including prompt injection attempts, role boundary breaches, and override attempts — AI Control Tower flags it in real time
• The kill switch: When an agent operates beyond its permissions, AI Control Tower can detect it and shut it down in real time

The kill switch capability is what moves AI Control Tower from a passive monitoring tool to an active enforcement platform. As The Register put it when covering the Knowledge 2026 announcement: “ServiceNow adds agent kill switches to AI control tower” (The Register, May 2026).

This also integrates with ServiceNow’s Armis acquisition ($7.75 billion), which extends security governance to connected devices and OT/IoT assets. The combined Armis + Veza + AI Control Tower stack creates what ServiceNow calls “Autonomous Security & Risk” — governing every AI agent, identity, and connected asset from a single platform.

5. Measure: Financial Control Over AI Spend

The Measure dimension addresses one of the most pressing operational challenges of scaling agentic AI: runaway model spend. As organizations deploy more agents making more LLM calls, token costs can grow exponentially without clear attribution to business outcomes.

AI Control Tower’s cost tracking and ROI dashboards give customers financial control by mapping AI spend to specific agents, workflows, and business outcomes. This is the FinOps layer for agentic AI — the same discipline that cloud teams applied to compute costs a decade ago, now applied to model inference costs.

The AI Gateway: MCP Transaction Governance

One of the less-discussed but architecturally significant features of AI Control Tower is the AI Gateway — a real-time control plane for all customer MCP (Model Context Protocol) transactions. The AI Gateway provides governance, observability, and security across any third-party AI system, with full visibility into what tools agents are calling and what data they are passing.

For agentic AI architects, this is the governance layer that sits between your agents and the external world. Every MCP call — whether to a database connector, a file system tool, or an external API — passes through the AI Gateway, where it can be logged, audited, rate-limited, or blocked based on governance policies.

This is particularly relevant given the ongoing debate about MCP overhead. As developers on Hacker News have noted, MCP operations can consume 32,000–82,000 tokens compared to ~200 for a direct CLI call. The AI Gateway gives organizations a mechanism to at least track this overhead and attribute it to specific workflows, even if it does not solve the efficiency question directly.

How AI Control Tower Compares: ServiceNow vs. IBM vs. Microsoft

ServiceNow is not alone in the AI governance space. The inaugural 2026 Gartner Magic Quadrant for AI Governance Platforms positions three Leaders: ServiceNow, IBM, and Truyo. Understanding the differences matters for architects choosing a governance stack.

The fundamental difference: ServiceNow governs agent behavior, IBM governs agent data access, and Microsoft provides infrastructure guardrails. For a CXToday analysis of the ServiceNow vs. IBM positioning, see their detailed comparison (CXToday, 2026).

If your organization already runs ServiceNow ITSM or CMDB, AI Control Tower is the natural choice — it inherits the service-context mapping that makes governance useful rather than just checkbox-compliance. If your primary concern is data lineage and regulatory proof, IBM’s 200+ regulatory mappings give it an edge. If you are all-in on the Microsoft stack, the combination of Copilot Studio, Agent Framework Harness, and Purview may cover enough ground without a third-party tool.

What This Means for RPA and Automation Architects

If you are an RPA architect or automation CoE leader, ServiceNow AI Control Tower signals a structural shift in what “governance” means for your practice. Here is what changes:

Your Bot Inventory Problem Just Got Bigger

Classic RPA governance meant tracking bots in Orchestrator. Agentic AI governance means tracking bots plus LLM-powered agents plus MCP servers plus the models they call plus the datasets they access. If your CoE is still governing only the bots it deploys directly, you are already behind. The teams building agents with LangGraph, CrewAI, or open-source agent frameworks are outside your governance perimeter.

MCP Server Governance Is the New Access Control

Every MCP server an agent can access is an expansion of that agent’s capability surface area. ServiceNow’s approach — requiring approval before MCP servers can be activated — is analogous to how IT teams managed API gateway access in the microservices era. If your organization is deploying MCP servers, you need an approval workflow before they go live, not after.

The Kill Switch Is Now a Procurement Requirement

The ability to shut down a rogue agent in real time is moving from “nice to have” to “procurement checklist item.” If your enterprise is evaluating agent platforms, expect governance teams to ask: “can we shut this agent down instantly if it goes off-script?” Any agent platform that cannot answer “yes” will face increasing resistance from security and compliance stakeholders.

Observability Is the Missing Layer

RPA bots are deterministic — they do the same thing every time, so audit trails are straightforward. LLM-powered agents are non-deterministic — the same input can produce different reasoning paths and different actions. This makes traditional RPA monitoring insufficient. The Traceloop-style observability (tracing reasoning chains, tool calls, and data access in real time) is the new standard for agent monitoring. If you are building agents without this level of observability, you are building blind.

Architecture: How AI Control Tower Fits Into Your Stack

For architects designing governed agentic AI deployments, here is how AI Control Tower integrates:

Layer 1 — Infrastructure: Your agents run on AWS Bedrock/AgentCore, Azure AI Foundry, Google Vertex AI, or on-premises infrastructure. AI Control Tower connects to these via its 30+ discovery integrations.

Layer 2 — Agent Runtime: Your agents are built with UiPath, Automation Anywhere, Copilot Studio, LangGraph, CrewAI, or any other framework. AI Control Tower discovers them regardless of framework.

Layer 3 — Tool Access: Agents access tools via MCP servers, REST APIs, or native connectors. The AI Gateway sits here, governing every external call.

Layer 4 — Identity: Veza’s Access Graph enforces least-privilege permissions for every agent identity, mapping permissions to specific services and data.

Layer 5 — Governance: AI Control Tower provides the unified view — discovery dashboard, runtime observability, risk assessment, compliance reporting, and cost attribution.

The key architectural insight is that AI Control Tower operates as an overlay, not a replacement. It does not require you to rebuild your agent infrastructure on ServiceNow. It connects to your existing stack and provides governance on top. This is the same pattern as ServiceNow’s ITSM: it does not replace your infrastructure, it governs it.

Pricing and Availability

ServiceNow is offering AI Control Tower free for one year, which it frames as a “$2 million value” (ServiceNow Community, 2026). After the introductory period, AI Control Tower is included with ServiceNow’s AI subscription tiers. However, there is an important caveat: the inclusion covers governing AI assets built within the ServiceNow ecosystem. Governing third-party AI assets (agents on AWS, Azure, or other platforms) may require additional licensing.

The Knowledge 2026 enhancements entered the Innovation Lab in May 2026, with full general availability expected in August 2026 as part of the ServiceNow AI Platform Australia release. The features roll out on a rolling basis, so availability may vary by instance.

Early Adoption Signals: What Enterprises Are Saying

Several enterprise customers shared their experiences at Knowledge 2026:

HDFC Bank (India’s largest private sector bank): “We run ServiceNow AI across IT and risk, and AI Control Tower is the common governance layer across all of it, giving us the visibility to manage every AI use case and the confidence to scale,” said Ramesh Lakshminarayanan, Group CIO.

Rolls-Royce reported 38,000 tickets deflected in a year and resolution times reduced by 34% using ServiceNow AI, and is now scaling autonomous actions across IT, HR, and Finance — with AI Control Tower providing the governance layer.

Academy Sports described ServiceNow as “our platform of intelligence” and is “architecting a digital twin of our operating footprint where AI connects our assets to our people.”

Preparing Your Organization: A Practical Checklist

If your organization is evaluating AI Control Tower or building an agent governance practice from scratch, here is what to do now:

1. Audit your current agent inventory. Before you can govern agents, you need to know how many you have. Survey every team that has deployed any form of AI agent — including those using open-source frameworks outside the CoE. Count RPA bots, LLM agents, copilot integrations, and any MCP servers they connect to.

2. Map agents to business processes. AI Control Tower’s value comes from contextual governance — knowing not just that an agent exists, but what business process it supports. Start mapping this now, even if you do not use ServiceNow. The discipline transfers to any governance platform.

3. Define your MCP server approval workflow. If your teams are deploying MCP servers, establish an approval process before AI Control Tower enforces one for you. Decide who approves new servers, what security review is required, and what access scope is permitted.

4. Establish agent identity standards. Every AI agent should have a named identity with scoped permissions, not shared service accounts. This is the foundation for least-privilege enforcement, whether you use Veza or another identity governance tool.

5. Choose your observability stack. If you are on ServiceNow, Traceloop integration is built in. If not, evaluate OpenLLMetry (open-source), Langfuse, or LangSmith for agent reasoning trace capture. The important thing is that you can trace an agent’s decision back to the data and tools it used.

6. Align with regulatory requirements. If your organization falls under the EU AI Act or industry-specific regulations, map your agent risk categories now. AI Control Tower’s five built-in risk frameworks (NIST, EU AI Act) provide a starting point, but your compliance team needs to validate the mapping.

Frequently Asked Questions

Does ServiceNow AI Control Tower only govern ServiceNow-native AI agents?

No. AI Control Tower is designed to govern AI deployed on any platform, including AWS, Google Cloud, Microsoft Azure, and enterprise applications like SAP, Oracle, and Workday. The 30+ enterprise integrations in the Knowledge 2026 release extend discovery and governance to third-party AI systems, not just ServiceNow’s own agents.

Can AI Control Tower monitor and shut down agents built with open-source frameworks like LangGraph or CrewAI?

AI Control Tower’s discovery and observability depend on integration connectors. For agents deployed on supported infrastructure (AWS, Azure, GCP, Databricks, Snowflake), the platform can discover and monitor them. For agents running on custom infrastructure, you would need to integrate via the AI Gateway or OpenLLMetry instrumentation. The kill switch capability requires the agent to be reachable through a supported integration.

How does AI Control Tower pricing work?

ServiceNow is offering AI Control Tower free for one year (framed as a ~$2M value). After that, it is included with ServiceNow’s AI subscription tiers for governing ServiceNow-native AI assets. Governing third-party AI assets across other platforms may require additional licensing. Contact ServiceNow for specific pricing based on your deployment scope.

What is the difference between AI Control Tower and UiPath Orchestrator or Automation Anywhere Control Room?

UiPath Orchestrator and Automation Anywhere Control Room govern RPA bots within their respective ecosystems. AI Control Tower governs all AI assets — RPA bots, LLM agents, ML models, MCP servers, datasets, and prompts — across any vendor and any cloud. It also adds capabilities that RPA control rooms lack, including LLM reasoning-chain observability, EU AI Act compliance frameworks, and real-time agent kill switches.

Does ServiceNow AI Control Tower support MCP (Model Context Protocol) governance?

Yes. The June 2026 release added MCP servers as a governed asset type. AI Stewards can require approval before MCP servers are activated in agent builder applications, and the AI Gateway provides real-time governance for all MCP transactions, including logging, auditing, and policy enforcement.

Key Takeaways

• AI Control Tower goes GA in August 2026 as a five-dimension governance platform (Discover, Observe, Govern, Secure, Measure) that governs AI agents across any cloud and any vendor.
• 30+ enterprise integrations connect to AWS, Google Cloud, Azure, SAP, Oracle, Workday, Databricks, Snowflake, and Hugging Face for cross-platform agent discovery.
• Traceloop acquisition provides deep runtime observability via OpenLLMetry, tracing agent reasoning chains, tool calls, and data access in real time.
• Veza acquisition brings identity governance with least-privilege enforcement and a real-time kill switch for rogue agents.
• MCP server governance is now built in — requiring approval before MCP servers can be activated in agent applications.
• Gartner positioned ServiceNow as a Leader in the inaugural 2026 Magic Quadrant for AI Governance Platforms alongside IBM and Truyo.
• Free for one year with ServiceNow AI subscription tiers; third-party asset governance may require additional licensing.
• For RPA architects: the governance perimeter has expanded from bot inventory to full agent-model-data-tool governance. Start auditing and mapping now.

References

1. ServiceNow Newsroom. “ServiceNow expands AI Control Tower to discover, observe, govern, secure, and measure AI deployed across any system in the enterprise.” May 5, 2026. Link
2. ServiceNow Community. “AI Control Tower: What’s new in the June 2026 release.” June 2026. Link
3. Calcalist. “ServiceNow buys Traceloop in $60-$80 million deal.” 2026. Link
4. Forbes. “ServiceNow Agrees To Buy Veza To Govern AI Agent Permissions At Scale.” December 2025. Link
5. The Register. “ServiceNow adds agent kill switches to AI control tower.” May 2026. Link
6. Gartner Peer Insights. “Best AI Governance Platforms Reviews 2026.” Link
7. CXToday. “IBM Vs ServiceNow, Who Owns Agentic AI Governance?” 2026. Link
8. Diginomica. “ServiceNow Knowledge 2026 – AI Control Tower expands, Autonomous Workforce reaches every function.” 2026. Link
9. ERP Today. “ServiceNow Repositions Around AI Security and Governance at Knowledge 2026.” 2026. Link
10. Constellation Research. “ServiceNow Knowledge 2026: AI Control Tower, Action Fabric, Autonomous Workforce and more.” 2026. Link