The plumbing behind every agent purchase.
Every purchase an AI agent completes, whatever it's buying, passes through the same four jobs: proving who the agent is, proving what it's allowed to spend, connecting to the business's own systems, and completing a transaction the business can settle. The protocols in this hub each do one of those jobs. None of them does all four.
8 min read
An agent turning "find me a room for Friday" into a booked room isn't one step
Four separate jobs happen between an agent deciding to buy and a business treating the sale as real, and they rarely get named clearly enough to tell apart.
Ask an AI agent to book a hotel room and the request looks instant from the outside. Underneath, four separate things have to happen before a booking exists: establishing that this particular agent is who it claims to be, confirming it's allowed to spend up to whatever the room costs on this person's behalf, connecting it to the hotel's live availability and rates rather than a stale cached listing, and completing the transaction in a way the hotel's own booking system recognises as final rather than a promise made in a chat window.
Each of those four jobs has a name, in the way this part of the industry currently talks about it: identity and payment authorisation, connection, and checkout. Treat any one of them as the whole problem and the other three quietly become someone else's problem, usually the business's, usually discovered at the worst moment.
Four jobs, four protocols, and the confusion is mixing them up
MCP (Model Context Protocol) is the connection layer: it gives an agent a standard way to call into a business's systems and read live data or trigger a defined action, the way it would check room availability or pull a menu. It says nothing about who's allowed to do that or what they're allowed to spend.
A2A (Agent2Agent) is how one agent hands a task to another agent precisely enough to be trusted, the way a general-purpose assistant might delegate "book this exact room, these exact dates" to a specialised booking agent. It describes the task. It doesn't authorise payment for it.
Agent credentials and AP2 (Agent Payments Protocol) are the identity and authorisation layer: a credential proves this agent is who it says it is, and a payment mandate proves a real person approved this specific spend, up to this specific limit. Neither one connects to anything or completes anything.
UCP (the checkout protocol this hub keeps coming back to) is the last step: it's what completes the transaction, once the other three have already checked out, so the business gets a confirmed order rather than an agent's unverified promise.
None of the four is agentic commerce on its own
This is worth stating directly because it's the mistake that costs a business the most time: getting MCP working correctly isn't "being agent-ready." It's one of four things agent-ready requires, alongside proof of identity, proof of spending authority, and a checkout step that closes cleanly. A business that wires up connection and stops there has built an agent that can look, not one that can buy: the same gap "Being found is not the same as being bought from" covers at the level of the whole idea, and this hub's own sibling on agent-ready transactions covers from the readiness side rather than the protocol side.
Where this shows up for a business
None of this has to be built from scratch. Selfe issues the credentials, checks the mandates and completes the checkout handoff for every business it represents, so the four jobs above happen automatically rather than needing four separate integrations. The rest of this hub goes through each one in more detail.
Do I need to support every one of these protocols myself?
Not directly. A business using Selfe gets all four handled as part of its structured, agent-readable identity rather than having to implement each specification separately.
Is this the same as accepting card payments online?
No. These protocols establish who's asking and whether they're authorised; the actual money movement still runs on existing payment rails underneath.
MCP, explained: what it actually connects, and what it doesn't.
Model Context Protocol gives an AI agent a standard way to call into a business's own systems: read live data, run a search, trigger a defined action. It has nothing to do with payment or identity. That's a separate job, done by separate protocols.
A2A, explained: how one agent proves what it's asking another to do.
A shopping AI agent rarely finishes the whole job itself. It hands specific tasks to other, more specialised agents along the way. Agent2Agent protocol is how one agent describes a task to another clearly enough that the second agent can trust it and act on it.
AP2 and agent payments: how an agent proves it's allowed to spend on someone's behalf.
A credential proves an AI agent is who it says it is. AP2 (Agent Payments Protocol) proves something narrower and more specific: that a real person authorised this exact spend, up to this exact limit, and a business can verify that before it charges anything.
UCP and the checkout handoff: what changes when a purchase completes inside the conversation.
Every other protocol in this hub gets a purchase ready. UCP is the one that completes it: the point where a business hands back a confirmed order without sending the customer off to finish the job on a website.