Multi-Agent Orchestration

01 - The Coordination Problem

The agentic commerce ecosystem did not emerge as a single, coordinated architecture. It emerged as a series of independent protocol initiatives, each solving a different problem for a different constituency. Google and Shopify built the Universal Commerce Protocol (UCP) to enable AI agents to interact with merchant catalogues, shopping carts, and checkout flows through a single open standard. OpenAI and Stripe built the Agentic Commerce Protocol (ACP) to define how AI agents discover products, initiate checkouts, and complete purchases within conversational AI surfaces. Anthropic built the Model Context Protocol (MCP) to connect AI agents to backend infrastructure, databases, and enterprise tools through a standardised interface. Google built the Agent-to-Agent Protocol (A2A) to enable peer-to-peer task delegation between autonomous agents across organisational boundaries. Visa built Visa Intelligent Commerce (VIC) to provide payment authentication and agent verification through its Trusted Agent Protocol. Mastercard built Agent Pay to deliver tokenised payment infrastructure with Agentic Tokens that bind agents to individual users.

Each protocol is rational in isolation. Each addresses a genuine gap in the agentic commerce infrastructure. But the consumer does not experience protocols in isolation. The consumer delegates a task - "buy me running shoes" - and expects a result. Between that delegation and that result, the agent must traverse multiple protocol boundaries, coordinate with multiple other agents, and maintain trust continuity across systems that were not designed to work together.

This is the coordination problem. It is not a problem of protocol design. It is a problem of orchestration design - the discipline of specifying how autonomous agents sequence their actions, hand off trust, propagate delegation, and recover from failures across protocol boundaries. Microsoft's Azure Architecture Centre identifies several canonical multi-agent patterns - sequential pipelines, parallel fan-out, hierarchical delegation, and event-driven choreography. But these patterns were developed for enterprise software orchestration. Agentic commerce introduces a dimension that enterprise patterns do not address: the trust dimension. In enterprise orchestration, agents share a common trust domain. In agentic commerce, agents operate across trust boundaries, and the orchestration must design how trust propagates across those boundaries.

02 - Six Protocols, One Transaction

Consider a single transaction: a consumer's agent purchasing a pair of running shoes from a merchant's catalogue. In the fully orchestrated agentic commerce stack, this transaction touches all six protocols in sequence.

The journey begins with discovery and evaluation. The consumer's agent uses Google's Universal Commerce Protocol to query merchant catalogues, compare product specifications, check real-time inventory, and evaluate pricing across multiple merchants. UCP provides the structured data layer that makes merchant offerings legible to agents. Without UCP, the consumer's agent would need to scrape websites or rely on unstructured data - a fragile approach that cannot scale.

Once the agent has identified the optimal product, the transaction moves to checkout execution. If the consumer is operating within a conversational AI surface like ChatGPT, OpenAI's Agentic Commerce Protocol governs how the agent initiates the checkout, confirms the order details, and executes the purchase through Stripe's payment rails. ACP defines the transaction semantics - the structured, permission-based interactions between the AI agent, the merchant system, and the user.

Behind the scenes, both the consumer's agent and the merchant's agent need access to backend systems. Anthropic's Model Context Protocol provides the standardised interface through which agents connect to databases, inventory systems, CRM platforms, and fulfilment infrastructure. MCP is the plumbing layer - it does not govern the commerce transaction itself, but it enables the agents to access the data and capabilities they need to execute it.

When the transaction involves multiple agents from different organisations - a consumer's agent, a merchant's agent, and perhaps a logistics agent - Google's Agent-to-Agent Protocol enables the peer-to-peer coordination between these agents, allowing them to discover each other's capabilities, delegate tasks, and exchange structured data across organisational boundaries. A2A is the protocol that makes multi-party agent commerce possible.

The payment layer introduces its own protocol requirements. Visa's Intelligent Commerce platform authenticates the agent's identity and authorises the payment through its Trusted Agent Protocol, which verifies that the agent is a legitimate actor with valid credentials before permitting the transaction to proceed. Simultaneously, Mastercard's Agent Pay provides the tokenised payment infrastructure, issuing Agentic Tokens that bind the agent's spending authority to the specific consumer and the specific transaction parameters they delegated.

Six protocols. One pair of running shoes. The consumer sees none of this. They delegated a task and received a result. But between delegation and result, a complex orchestration occurred - and the quality of that orchestration determined whether the consumer's intent was faithfully executed, whether their trust was maintained, and whether the transaction completed successfully.

Interactive Reference

The diagram below maps the three-layer protocol stack described in this essay. Click any protocol to see its coordination partners, or select a coordination pattern to trace the flow across layers. Each node links to its Protocol Lab walkthrough and Observatory essay.

03 - Orchestration Patterns in Agentic Commerce

Google's Agent Development Kit documentation identifies eight essential multi-agent design patterns: sequential pipelines, parallel fan-out, hierarchical delegation, loop patterns, dynamic routing, specialised workers, consensus patterns, and event-driven choreography. Confluent's research on event-driven multi-agent systems adds four more: the supervisor pattern, the swarm pattern, the map-reduce pattern, and the human-in-the-loop pattern. These patterns provide useful structural vocabulary. But agentic commerce requires a different taxonomy - one organised not by computational structure but by trust architecture and delegation design.

The first pattern is sequential trust-chain orchestration. This is the simplest model: the consumer's agent moves through protocol layers in sequence - discovery via UCP, checkout via ACP, payment via VIC or Agent Pay. Trust is established at each boundary before the next step begins. This pattern is reliable but slow, and it creates a single point of failure at each trust boundary.

The second pattern is parallel trust-verified orchestration. Here, the consumer's agent initiates multiple protocol interactions simultaneously - querying catalogues via UCP while pre-authenticating payment via VIC and establishing A2A connections with merchant agents. Trust verification happens in parallel rather than sequentially. This pattern is faster but introduces synchronisation challenges: what happens if the payment authentication completes before the product discovery, and the consumer's preferences change based on what is available?

The third pattern is hierarchical delegation orchestration. In this model, the consumer's agent delegates to a commerce orchestrator agent, which in turn delegates to specialised sub-agents for discovery, checkout, and payment. The orchestrator maintains the overall transaction state and coordinates the sub-agents. This pattern maps naturally to B2B2C agentic commerce, where platform intermediaries act as orchestrators between brand agents and consumer agents.

The fourth pattern is event-driven choreography. Rather than a central orchestrator, each agent reacts to events published by other agents. The consumer's agent publishes a "product selected" event; the payment agent reacts by initiating authentication; the merchant agent reacts by reserving inventory. This pattern is the most resilient - no single point of failure - but it is also the hardest to design for observability, because no single agent has a complete view of the transaction state.

Each pattern makes different demands on the protocol stack. Sequential orchestration requires clean handoff interfaces between protocols. Parallel orchestration requires synchronisation primitives that the current protocols do not provide. Hierarchical delegation requires trust to propagate through intermediary agents. Event-driven choreography requires a shared event bus that no current protocol defines. The choice of orchestration pattern is not a technical decision. It is a design decision with direct implications for trust, observability, and failure recovery.

04 - The Trust Propagation Challenge

The most consequential design challenge in multi-agent orchestration is trust propagation. When a consumer delegates purchasing authority to their agent, that trust must propagate across every protocol boundary the transaction traverses. The consumer trusts their agent. But does the merchant's agent trust the consumer's agent? Does the payment network trust the agent presenting credentials? Does the logistics agent trust the delegation chain that originated with the consumer?

Each protocol handles trust differently. UCP relies on structured data standards and merchant-verified catalogues - trust is embedded in the data quality. ACP relies on Stripe's existing payment trust infrastructure and OpenAI's platform verification. MCP relies on server-side authentication and capability declarations. A2A relies on Agent Cards - machine-readable capability declarations that agents publish for discovery. VIC relies on Visa's Trusted Agent Protocol, which verifies agent identity against Visa's network credentials. Agent Pay relies on Mastercard's tokenisation infrastructure, binding agent authority to specific consumers through Agentic Tokens.

These trust mechanisms are not interoperable. An agent verified by Visa's Trusted Agent Protocol is not automatically trusted by Mastercard's Agentic Token system. An agent authenticated via MCP server credentials is not automatically recognised by A2A Agent Cards. Trust established in one protocol layer does not automatically propagate to the next. This is the trust propagation gap - and it is the gap that multi-agent orchestration must bridge.

The Trust Triangle framework from AXD practice identifies three vertices of trust in any agentic relationship: the principal (the human who delegates), the agent (the system that acts), and the counterparty (the entity the agent transacts with). In multi-agent orchestration, the Trust Triangle multiplies. Each protocol boundary introduces a new triangle. The consumer trusts their agent. Their agent must be trusted by the merchant's agent. The merchant's agent must be trusted by the payment network. The payment network must verify the delegation chain back to the consumer. At each vertex, trust must be established, verified, and maintained - and the orchestration layer must design how this happens.

Forbes reported in March 2026 that coordination governance is emerging as a critical concern in enterprise multi-agent systems. Deloitte's 2026 technology predictions explicitly frame agent orchestration as a key unlock for modular, agent-powered workflows. But neither governance frameworks nor enterprise orchestration patterns address the specific challenge of trust propagation across heterogeneous protocol boundaries in commerce. That challenge belongs to Agentic Experience Design.

05 - Failure Modes in Multi-Agent Systems

Multi-agent orchestration introduces failure modes that do not exist in single-protocol systems. Understanding these failure modes is essential for designing resilient orchestration, because the consumer's experience of agentic commerce is determined not by how the system works when everything succeeds, but by how it behaves when something fails.

The first failure mode is trust boundary failure. An agent successfully authenticated in one protocol layer fails verification in the next. The consumer's agent discovers products via UCP and selects a merchant, but the merchant's payment system, operating through VIC, does not recognise the agent's credentials. The transaction stalls at the protocol boundary. The consumer's agent has no mechanism to resolve the trust mismatch because the two protocols have no shared trust vocabulary.

The second failure mode is delegation cascade failure. The consumer delegates "buy running shoes under 150 pounds." The consumer's agent delegates to a commerce orchestrator. The orchestrator delegates to a merchant agent. At each delegation step, the original constraints must be preserved and propagated. If the merchant agent receives a delegation that has lost the price constraint - because the orchestrator's A2A message did not include it, or because the MCP context window truncated it - the agent may purchase shoes that violate the consumer's intent. The delegation cascade failed not because any single agent failed, but because the orchestration did not design for constraint propagation across protocol boundaries.

The third failure mode is temporal synchronisation failure. Agents operating at different speeds create race conditions. The consumer's agent reserves a product via UCP, but the payment authentication via VIC takes longer than the merchant's inventory hold period. By the time payment is authorised, the product is no longer available. The transaction fails not because any protocol failed, but because the orchestration did not account for the temporal mismatch between protocol layers.

The fourth failure mode is partial completion failure. The most dangerous failure in multi-agent orchestration. The payment succeeds via Agent Pay, but the order confirmation via ACP fails. The consumer has been charged but has no order. Or the order is placed but the payment authentication is revoked. The system is in an inconsistent state that no single protocol can resolve, because the inconsistency spans protocol boundaries. Partial completion failures require cross-protocol rollback mechanisms that the current protocol stack does not provide.

The fifth failure mode is observability gap failure. The consumer asks their agent what happened. The agent can report what it did within its own protocol interactions, but it cannot provide a complete audit trail across all six protocol layers. The MCP interactions are logged differently from the A2A interactions, which are logged differently from the VIC authentication records. There is no unified observability layer that spans the entire orchestration chain. The consumer cannot determine what happened, where it failed, or why - which means they cannot calibrate their trust in the system. This is the agent observability problem at its most acute.

06 - The Orchestration Layer as Design Material

The argument of this essay is that multi-agent orchestration is not an infrastructure concern to be solved by engineers after the protocols are deployed. It is a design material - as fundamental to Agentic Experience Design as trust, delegation, and observability. The orchestration layer determines the consumer's experience of agentic commerce just as surely as any individual protocol does.

NVIDIA's Retail Agentic Commerce Blueprint, released at GTC in March 2026, provides the first reference implementation of dual-protocol support - integrating UCP and ACP into a single merchant-controlled checkout flow. This blueprint demonstrates that protocol integration is technically feasible. But technical feasibility is not design. The blueprint shows how to connect two protocols. It does not show how to design the trust handoffs, delegation cascades, and failure recovery paths that determine whether the consumer's experience is trustworthy.

The Orchestration Visibility Model from AXD Practice provides a framework for designing observability across multi-agent systems. But observability is only one dimension of orchestration design. The orchestration layer must also design for trust propagation (how trust established in one protocol layer transfers to the next), delegation integrity (how the consumer's original intent is preserved across protocol boundaries), temporal coordination (how agents operating at different speeds synchronise their actions), and graceful degradation (how the system behaves when one protocol layer fails while others succeed).

Each of these design dimensions maps to an existing AXD framework. Trust propagation maps to the Trust Triangle. Delegation integrity maps to Delegation Scope. Temporal coordination maps to Temporal Trust. Graceful degradation maps to Failure Architecture. Multi-agent orchestration is where these frameworks converge - where the theoretical principles of AXD become operational requirements in a real, multi-protocol commerce system.

07 - From Protocol Stack to Coordination Architecture

The current agentic commerce ecosystem is building a protocol stack. What it needs is a coordination architecture. The distinction matters. A protocol stack is a collection of protocols that can technically interoperate. A coordination architecture is a designed system that specifies how agents coordinate across protocol boundaries to achieve outcomes that no single protocol can deliver.

The coordination architecture must address four structural gaps in the current protocol stack. First, the trust bridge gap. There is no standard mechanism for translating trust credentials between protocols. An agent verified by Visa's Trusted Agent Protocol should be recognisable to Mastercard's Agentic Token system, and vice versa. An agent authenticated via MCP should carry that authentication into A2A interactions. The coordination architecture needs a trust bridge layer that translates credentials across protocol boundaries.

Second, the delegation propagation gap. There is no standard mechanism for propagating delegation constraints across protocol boundaries. When a consumer delegates "buy running shoes under 150 pounds with next-day delivery," that delegation must be faithfully represented in UCP queries, ACP checkout parameters, A2A task descriptions, and VIC/Agent Pay payment authorisations. The coordination architecture needs a delegation propagation layer that ensures constraint fidelity across protocol boundaries.

Third, the state synchronisation gap. There is no shared state layer across protocols. Each protocol maintains its own transaction state. The coordination architecture needs a shared state layer - or at minimum, a state reconciliation mechanism - that enables agents to maintain a consistent view of the transaction across protocol boundaries.

Fourth, the unified observability gap. There is no cross-protocol audit trail. The coordination architecture needs a unified observability layer that enables the consumer - and the consumer's agent - to trace the complete transaction history across all protocol interactions. This is not merely a logging concern. It is a trust concern. If the consumer cannot observe what happened across the orchestration chain, they cannot calibrate their trust in the system, and the entire trust architecture collapses.

08 - What This Demands of AXD

Multi-agent orchestration is the integration test for Agentic Experience Design. Every principle, every framework, every vocabulary term in the AXD discipline finds its most demanding application in the orchestration of multiple agents across multiple protocol boundaries.

Trust architecture must extend beyond single-agent relationships to encompass multi-agent trust chains. Delegation design must account for delegation cascades that traverse protocol boundaries. Observability must span the entire orchestration chain, not just individual protocol interactions. Failure architecture must handle partial completion failures that span multiple protocols. Consent must be designed for systems where the consumer's original delegation is interpreted and re-delegated by multiple intermediary agents.

The machine customer does not care which protocol handles which layer. The machine customer cares about outcomes: was the right product purchased, at the right price, with the right delivery terms, within the delegated authority? The orchestration layer is where outcomes are determined. It is where the consumer's intent is either faithfully executed or silently corrupted. It is where trust is either maintained or broken.

The six protocols in the AXD Protocol Lab - UCP, ACP, MCP, A2A, VIC, and Agent Pay - are the building materials of agentic commerce. Multi-agent orchestration is the architecture. And architecture, as every designer knows, is not the sum of its materials. It is the design of how those materials work together to create something that none of them could achieve alone.

The organisations that master multi-agent orchestration will not be the ones that adopt the most protocols. They will be the ones that design the best coordination between protocols - the trust bridges, the delegation propagation, the state synchronisation, and the unified observability that transform a protocol stack into a coherent commerce system. That is the work of Agentic Experience Design. And it is the most consequential design challenge in the agentic commerce ecosystem today.

References