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.
5 min read
The handoff a purchase usually involves
An agent that looks like it's handling a request entirely on its own is often coordinating with at least one other agent behind the scenes.
Someone asks a general-purpose assistant to sort out a weekend away. That assistant doesn't necessarily do the booking itself. It might hand "find and book a dog-friendly cottage near the coast, these dates, this budget" to a more specialised booking agent, or connect directly to a business's own agent interface. Either way, a task is crossing a boundary between two systems that have never dealt with each other before.
What A2A specifies
A2A's actual unit is the task: a structured object naming what's being asked, broken into defined fields rather than typed as a sentence, carrying a task ID, an identity reference for who it's acting on behalf of, and whatever parameters the job needs to be actioned. Alongside it, the receiving agent publishes an agent card: a short, standing declaration of exactly what it's capable of doing, so the sending agent isn't guessing whether the action it wants is even supported before it hands the work over.
Handing off "book this dog-friendly cottage, these dates, four guests" isn't a sentence dropped into a chat window between two models. It arrives as a task with the dates, guest count and destination as separate, checkable fields, tagged with who the booking is actually for, sent to an agent whose own agent card already confirms booking is one of the things it does.
Where A2A sits among the four jobs
A2A sits inside two of this hub's four jobs rather than adding a fifth. When a task passes between two agents rather than one agent talking to a business directly, the task description is what carries the identity and connection information those two jobs need, checkable by the receiving side the same way it would check a request that arrived some other route.
Why this matters to a business, not just agent builders
A business's system may end up talking to an agent it's never encountered before, acting on behalf of a person it also never sees directly. A2A is what lets that request arrive with enough structure and provenance for the business's system to reasonably act on it, rather than treating every unfamiliar agent request as equally untrustworthy or equally trustworthy by default.
A task precise enough to act on safely.
A2A isn't about two AI systems chatting. It's about one task being described precisely enough that acting on it is safe: what's being asked for, on whose behalf, and by which agent. Get that description wrong and the safest response from the receiving side is to do nothing, which is usually the point.
Nothing for a business to evaluate itself
Selfe's own agent interface already speaks A2A, so a business doesn't need to evaluate every unfamiliar agent's request itself. The task arrives already structured and identified by the time it reaches anything the business runs.
Is A2A a payment protocol?
No. It structures the task handoff. Payment authorisation is a separate job, covered by agent credentials and AP2.
Does a business need to implement A2A itself?
Not with Selfe. Incoming requests already arrive structured by the time they reach a business's own systems.
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.
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.
Agent credentials: the token that says "yes, actually let this agent buy."
Before an AI agent can act on anyone's behalf, something has to vouch for it. An agent credential is the short-lived, scoped proof a business checks before it trusts a request enough to act on it.