A Plain-English Guide to the Protocols Powering the Agentic Web

If you've come across acronyms like MCP, ACP, or AP2 and weren't sure what they actually do, this page is for you. None of these are competing for the same job - each one solves a different, specific problem in letting an AI agent act on a website. Think of them less like rival products and more like different layers of a stack, each handling one piece of a bigger task.

The foundation layer: how an agent talks to anything at all

MCP (Model Context Protocol)

The problem it solves: before an agent can do anything useful with a website or tool, it needs a standard way to ask "what can I do here, and how?" Before this existed, every connection between an AI system and an outside tool had to be built by hand, one integration at a time. Why it matters: MCP became the shared language for exactly that handshake - letting an AI system discover and use outside tools and data sources without a custom integration for each one. It's become one of the most widely adopted pieces of agent infrastructure, and is now stewarded by an open, multi-company foundation rather than any single business.

A2A (Agent2Agent)

The problem it solves: sometimes the thing on the other end of a request isn't a website at all - it's another AI agent, perhaps representing a different company entirely. A2A gives agents a standard way to talk to each other, coordinating on a task without either side needing to know how the other was built internally. Why it matters: as more businesses run their own specialized agents, A2A is what lets a personal assistant agent and a business's own agent actually negotiate and hand off work between each other.

The commerce layer: how an agent actually shops and books

UCP (Universal Commerce Protocol)

The problem it solves: discovering what a business sells, building a cart, and completing checkout all used to require a custom integration for every business and every AI platform. UCP standardizes that entire journey, from browsing a catalog through to finishing a purchase. Why it matters: it's backed by some of the largest names in retail and search, and it's expanding beyond general shopping into specific industries - hotel bookings and food delivery among the first.

ACP (Agentic Commerce Protocol)

The problem it solves: similar territory to UCP, with a particular focus on letting a conversational AI assistant initiate and complete a purchase on a person's behalf, especially within a chat-style interface. Why it matters: it shows how quickly this space is still evolving - its own backer shifted strategy partway through 2026, moving away from completing purchases directly inside the conversation and toward handing that final step to the business's own app instead. Good evidence that nothing here is fully settled yet.

The trust and payment layer: proving a transaction is legitimate

AP2 (Agent Payments Protocol)

The problem it solves: if an agent is about to spend a person's money, how does the business (or the bank) know the agent really was authorized to do that, for that amount, by that actual person? AP2 creates a verifiable, tamper-evident record of consent for exactly this. Why it matters: payment networks and major financial institutions have backed this approach, and it's now overseen by an industry-wide standards body rather than one company - a sign that the financial industry sees this as foundational, not optional.

x402 and MPP (settlement protocols)

The problem it solves: once an agent is cleared to pay, the money still has to actually move - sometimes instantly, sometimes in very small amounts, sometimes between two systems with no existing payment relationship. These protocols handle that final mechanical step, including newer approaches built around digital currencies for fast, low-friction machine-to-machine payments. Why it matters: this is the plumbing layer most people will never see directly, but it's what makes "the agent paid for it automatically" actually possible underneath.

The browser and discovery layer: how a website tells agents what it offers

WebMCP

The problem it solves: lets a webpage describe its own capabilities directly to an agent browsing it - "here's the search function," "here's how to add something to a cart" - without the agent having to guess from the visual layout the way a person would. Why it matters: it brings the same idea behind MCP down to the level of an individual web page, rather than requiring a whole separate server.

NLWeb

The problem it solves: gives a website a standard way to expose a conversational, ask-a-question style interface that an agent can query directly, grounded in the same structured data search engines have used for years. Why it matters: it's a relatively low-effort way for a website to become agent-legible without building anything from scratch.

Self-declared discovery files (like llms.txt and AGENTS.md)

The problem it solves: before an agent can use any of the protocols above, it needs to know they exist at all. These are simple, plain-text files a website can publish at a predictable location, describing what it offers and how an agent should approach it. Why it matters: they're cheap to create, increasingly common, and act as a signpost pointing toward the more substantial integrations underneath - though, like any self-description, they reflect what a business says about itself, not independent confirmation that it's accurate.

The platform-specific layer

Things like the ChatGPT Apps platform

The problem it solves: rather than a universal, cross-platform standard, some integrations are built specifically for one AI assistant's own ecosystem - useful and real, but only inside that particular platform. Why it matters: these are worth knowing about specifically because they're easy to mistake for a universal capability when they're not. A business integrated with one assistant's app platform hasn't necessarily built anything an agent from a different provider can use.

The catch-all: real, but custom

Proprietary interfaces

The problem it solves: plenty of well-established businesses built a working API long before any of the standards above existed, and haven't necessarily rebuilt it to match a newer shared protocol. Why it matters: "doesn't use a named standard" is not the same as "doesn't work." A custom, well-documented, properly maintained interface can be entirely legitimate and usable - it just requires checking on its own terms rather than assuming it follows a pattern shared with anyone else.

The honest summary

No business needs all of these. Most need none of them perfectly and a couple of them partially. What actually matters for getting something done isn't "does this business support the most protocols" - it's whether something real and working exists for the specific task at hand, and whether what's been claimed about it holds up.