AI agent protocols are the open standards that let an agent talk to the things around it without custom glue code for every pairing. Each one covers a different connection: MCP connects an agent to tools and data, A2A connects an agent to other agents, AG-UI connects an agent to the user interface, and a newer group of payments and commerce protocols (AP2, the Agentic Commerce Protocol, UCP and x402) govern how an agent buys things on someone's behalf. They are layers in one stack, not rivals. This guide maps where each one sits, who looks after it, how mature it is, and which to learn first.
Why agents need protocols at all
An agent in production deals with four kinds of counterparty. It calls tools and data (a CRM, a ticketing system, a database). It may hand work to other agents, sometimes built by another team or vendor. It streams progress to a human through a web or chat interface. And more and more often it acts in the world on the user's behalf, which can mean spending money.
Without standards, every one of those links is bespoke. Protocols turn that many-to-many problem into "implement the standard once on each side".
One thing to keep in mind throughout: a protocol defines how two parties talk, not whether either one can be trusted. Identity, permissions, approvals and audit remain your job.
The agent protocol stack: where each protocol sits
Think of an agent as the centre of a diagram, with a different protocol on each side of it:
+----------------------+
| User / frontend |
+----------+-----------+
| AG-UI (events)
+----------v-----------+ A2A +-------------+
| Your agent |<-------->| Other agent |
| (LLM + logic/state) | tasks | (any vendor)|
+---+--------------+---+ +-------------+
| |
MCP | | AP2 / ACP / UCP / x402
v v
+--------------+ +-------------------+
| Tools, data, | | Merchants, PSPs, |
| enterprise | | paid APIs |
| systems | +-------------------+
+--------------+
Underneath all of it: identity and authorization
(OAuth 2.x, OIDC, workload identity, audit)
MCP: agent to tools and data
The Model Context Protocol (MCP) is an open protocol that Anthropic introduced in late 2024 for connecting AI applications to external tools and data. A host (the AI application) runs clients that connect to servers. Servers expose tools (functions the model can call), resources (context and data) and prompts (reusable templates). Messages are JSON-RPC 2.0. If you are new to it, start with our explainer on what MCP is and how hosts, clients and servers fit together.
Two recent changes matter for anyone placing MCP in an architecture:
- Governance. MCP was donated to the Agentic AI Foundation (AAIF), a Linux Foundation body, in December 2025.
- The 2026-07-28 specification is stateless. There is no initialize handshake and no session ID. Protocol version and capabilities travel with each request, and servers can offer optional discovery. Sampling, roots and logging are deprecated. We cover the details in MCP goes stateless: the 2026-07-28 spec explained.
A2A: agent to agent
A2A (Agent2Agent) standardises how independent agents find each other and work together. Google announced it in April 2025. It became a Linux Foundation project in June 2025, and the project now says it has joined the Agentic AI Foundation, so MCP and A2A sit under the same neutral home. The project documents a v1.0 specification.
The core ideas are an Agent Card (a JSON document describing an agent's skills, endpoint and auth requirements), tasks with a trackable lifecycle, and messages and artifacts for exchanging content. Our A2A protocol deep-dive walks through the task lifecycle and security model.
The key judgement is that A2A is for crossing boundaries: between vendors, teams or organisations. If one team builds every agent in one framework, handing work between them in-process is simpler.
AG-UI: agent to user interface
AG-UI (Agent-User Interaction Protocol) is an open, event-based protocol for connecting an agent backend to a user-facing application. It grew out of CopilotKit's work with LangChain and CrewAI. It is MIT-licensed, developed under the ag-ui-protocol GitHub organisation with a community working group, and integrates with major agent frameworks. As far as we could verify, it is not hosted by a foundation.
Instead of returning one final answer, the agent emits a stream of typed events over HTTP (commonly server-sent events) or WebSockets. The documented categories include:
- Lifecycle: run started, finished or errored; step started or finished.
- Text messages: start, content chunks, end, so tokens stream into the chat.
- Tool calls: start, arguments, end and result, so the UI can show "looking up your policyβ¦" or render a confirmation card.
- State management: full snapshots and incremental deltas (JSON Patch), so agent and UI share state such as a draft form or a cart.
- Activity, sub-agent, reasoning and custom events.
The part that matters for enterprises is interrupts. A run can finish with an "interrupt" outcome, and the frontend resumes it once the human responds. That gives you a standard way to build approval steps ("Approve this refund?"). See human-in-the-loop AI for when to put a human in the loop.
Two related efforts are easy to confuse with AG-UI. MCP Apps lets an MCP server ship interactive UI that a host renders inline. A2UI is a generative-UI specification: it describes what to render, while AG-UI is the runtime channel that carries the interaction.
Agent payments and commerce protocols
This is the youngest layer and the fastest-moving one. The common problem: when an agent clicks "buy", how do the merchant, the payment provider and the card network know that a real user authorised this purchase, and who is liable if the agent gets it wrong? Four efforts are worth knowing. For the business side, read the companion article agentic commerce explained.
AP2 (Agent Payments Protocol)
Google developed AP2 as an open protocol (Apache 2.0) for agents to start payments in a way that can be verified. Its central idea is the mandate: a signed, verifiable digital credential that records what the user authorised. Purchase and payment authorisation are captured separately, leaving a tamper-evident record of consent. Version 0.2 added "human not present" payments, where an agent completes a purchase later based on instructions the user approved in advance. In April 2026 Google donated AP2 to the FIDO Alliance, which now leads its standardisation. AP2 is designed as an extension of A2A and works with MCP for tooling. Mandate names and structure have changed between versions, so read the current spec.
Agentic Commerce Protocol (ACP)
ACP was developed jointly by OpenAI and Stripe and is open source under Apache 2.0. It defines how a buyer's AI agent and a seller complete a checkout programmatically. The seller exposes an agent-ready checkout and remains the merchant of record. Its delegated payment specification lets payment credentials pass to the seller's payment provider without exposing the underlying card details to the agent. Stripe's Shared Payment Token was the first compatible implementation, and ChatGPT the first agent platform using ACP. It can be implemented over REST or MCP.
UCP (Universal Commerce Protocol)
UCP is an Apache-2.0 standard launched by Google in early 2026 and co-developed with retailers, commerce platforms and payment companies. It covers the whole shopping journey: discovery, checkout and post-purchase support. It supports REST and JSON-RPC transports, works with A2A and MCP, and uses AP2 for payment mandates. The project marks its shopping specification as production-ready, while other verticals are still drafts.
x402
x402 takes a lower-level approach. It revives HTTP's dormant 402 Payment Required status code: a server answers an unpaid request with a 402 and machine-readable price details, the client pays (typically in stablecoins) and retries. Coinbase created it, and it is now governed by the x402 Foundation under the Linux Foundation.
In short, ACP and UCP mostly cover the checkout conversation between an agent and a merchant, AP2 covers proof of authorisation, and x402 covers machine-to-machine micropayments. The boundaries overlap and may shift.
Identity and authorization: the layer under everything
None of these protocols replaces identity. MCP's HTTP transport builds its authorization on OAuth 2.1. A2A agents declare their auth schemes (OAuth 2.0, OpenID Connect, API keys, mutual TLS) in their Agent Cards. Commerce protocols rely on tokenised credentials and signed mandates. In every case you still have to answer the same questions: whose authority is the agent using, with what scope, for how long, and where is that recorded?
Delegation, workload identity, short-lived credentials and audit are covered in AI agent identity and access management. Agent-specific identity standards are still forming, so build on proven OAuth and OIDC patterns now.
MCP vs A2A vs AG-UI vs payments protocols
| Protocol | Connects | Steward | Core abstraction | Maturity (late 2026) |
|---|---|---|---|---|
| MCP | Agent β tools and data | Agentic AI Foundation (Linux Foundation); originated at Anthropic | Tools, resources, prompts over JSON-RPC | Most widely implemented; stateless 2026-07-28 revision |
| A2A | Agent β agent | Agentic AI Foundation (Linux Foundation); originated at Google | Agent Card, tasks, messages, artifacts | v1.0 spec; adoption mostly at cross-team or cross-vendor boundaries |
| AG-UI | Agent β user interface | Open-source community (ag-ui-protocol); originated at CopilotKit | Typed event stream, shared state, interrupts | Active, framework integrations growing; no foundation governance |
| AP2 | Agent β payment ecosystem | FIDO Alliance; originated at Google | Verifiable mandates (signed user authorisation) | Early (v0.x); formal standardisation under way |
| ACP | Agent β merchant checkout | OpenAI and Stripe | Checkout session, delegated payment | Live in at least one major agent platform; still evolving |
| UCP | Agent β commerce lifecycle | Google with industry co-developers | Commerce capabilities; uses AP2 for payments | Shopping spec production-ready; other verticals in draft |
| x402 | Client β paid HTTP resource | x402 Foundation (Linux Foundation); originated at Coinbase | HTTP 402 challenge, pay, retry | In production use; stablecoin-centric |
If you want to build these layers rather than just read about them, the AI, GenAI and Agentic AI course covers agents, tool calling, MCP servers and multi-agent orchestration with hands-on labs.
How the protocols combine in one enterprise architecture
Consider an illustrative example: a retail bank builds an assistant for small-business customers that handles supplier payments and account queries.
- Frontend (AG-UI). The agent streams text and tool progress to the bank's web app and keeps a shared "payment draft" in sync through state deltas. Before releasing a payment it raises an interrupt, and the UI shows an approval card with step-up authentication.
- Tools (MCP). The agent reaches core banking read APIs, the beneficiary registry and the fraud-scoring service through internal MCP servers. Each server enforces the customer's delegated OAuth scope.
- Other agents (A2A). Invoice verification belongs to a separate trade-finance team that runs its own agent on a different framework. The assistant finds it through an Agent Card in an internal registry and hands it a task. It gets back a structured artifact, never the other team's prompts or data stores.
- Commerce (AP2 / ACP / UCP). If the bank later lets its agent pay merchants on a customer's behalf, it would carry signed proof of the customer's authorisation (the AP2 mandate model) or go through a merchant's agent-ready checkout (ACP or UCP), instead of letting the agent fill in card forms.
- Underneath. Every hop is logged with the user, the agent identity, the protocol call and the outcome, and the traces go into the bank's observability stack. See enterprise AI architecture for the surrounding components (gateway, guardrails, evaluation).
Notice what the protocols did not do. Approval rules, fraud thresholds and data residency are still design decisions, and that is where the engineering effort goes. Taking a design like this into production at a customer site is the work Forward Deployed Engineers do.
Maturity and adoption caveats
- Specs are moving. MCP's 2026 revision removed sessions; A2A and AP2 field names have changed between versions. Pin SDK versions, read changelogs, and put a thin adapter between your business logic and the protocol library.
- Payments is the least settled layer. Several overlapping protocols exist, backed by different coalitions, and their stewards are still changing. Avoid deep lock-in. Wrap the commerce integration behind your own interface so you can switch protocols later.
- Support varies by implementation. "Supports MCP" or "supports AG-UI" may mean partial coverage of the spec. Test the exact features you rely on.
- Protocols widen the attack surface. Tool descriptions, Agent Cards and returned artifacts are untrusted input. Our guides on AI guardrails and enterprise AI security cover the controls.
- Foundation governance helps, but it doesn't certify anything. Neutral stewardship lowers abandonment risk; it says nothing about whether a particular server or agent is safe.
How to choose, and what to learn first
Choose by the boundary you need to cross, not by hype:
- My agent needs to reach our systems β MCP (or a plain API if only one app will ever call it).
- My agent must delegate to an agent owned by another team or company β A2A.
- I need streaming, shared state and approvals in a custom frontend β AG-UI.
- My agent must pay or check out β follow whichever commerce protocol your payment provider and merchants support, and keep the integration behind your own interface.
A sensible learning order, whether you work in a GCC in Hyderabad or Bengaluru, a services firm or a product company:
- Function calling and OAuth basics, which every protocol here builds on.
- MCP. Build one server end to end, with auth.
- AG-UI or an equivalent streaming pattern, as soon as you build a user-facing agent with approvals.
- A2A, once you work across team or vendor boundaries.
- Commerce protocols, only if your domain is retail, payments or fintech. Learn the concepts (mandates, delegated tokens) and expect specifics to change.
Interviewers increasingly ask candidates to place these protocols correctly in a design. Practise with the agentic AI interview questions guide.
Frequently asked questions
What are AI agent protocols?
AI agent protocols are open standards that define how an AI agent communicates with its surroundings: MCP for tools and data, A2A for other agents, AG-UI for user interfaces, and protocols such as AP2, ACP, UCP and x402 for payments and commerce. They replace one-off integrations with a shared contract.
What is the difference between MCP, A2A and AG-UI?
They cover different connections. MCP connects an agent to tools and data, A2A connects an agent to other independent agents, and AG-UI connects an agent to the frontend a human uses, streaming events, state and approval requests. One application can use all three.
Who governs MCP and A2A?
Both are now projects of the Agentic AI Foundation, a Linux Foundation body. MCP originated at Anthropic and was donated in December 2025. A2A originated at Google, became a Linux Foundation project in June 2025 and has since joined the Agentic AI Foundation.
Is AG-UI part of MCP or A2A?
No. AG-UI is a separate open-source, MIT-licensed protocol that grew out of CopilotKit's work with agent frameworks. It complements MCP and A2A by handling the agent-to-user layer, with typed events, shared state and human-in-the-loop interrupts.
What is an agent payments protocol?
An agent payments protocol defines how an AI agent can buy something on a user's behalf in a way merchants and payment providers can verify. Examples include AP2, now under the FIDO Alliance, the Agentic Commerce Protocol from OpenAI and Stripe, Google's Universal Commerce Protocol, and x402 for HTTP-native payments.
Is AP2 the same as the Agentic Commerce Protocol?
No. AP2 focuses on verifiable proof of what the user authorised, using signed mandates, and is designed as an extension of A2A. ACP focuses on a programmatic checkout between an agent and a merchant, with delegated payment credentials. They address overlapping but different parts of the purchase.
Which agent protocol should I learn first?
Learn MCP first, after function calling and OAuth basics, because it has the most implementations and appears in most enterprise agent projects. Add AG-UI when you build user-facing agents, A2A when you cross team or vendor boundaries, and commerce protocols only if your domain needs them.
Are agent protocols production ready?
Partly. MCP and A2A have published specifications and neutral governance, but both have changed significantly as they matured. AG-UI is active but community-governed. Payments protocols are the least settled. Pin versions, test the exact features you use, and keep protocol code behind your own interfaces.
Want to go from protocol diagrams to agents that actually run against enterprise systems? Cloudsoft's Agentic AI training in Hyderabad covers MCP servers, multi-agent workflows, evaluation and deployment, in the classroom in Ameerpet or live online. Call +91 96660 19191 to book a free demo.
