--- type: Article name: "A2A, explained: how one agent proves what it's asking another to do." id: "https://selfe.ai/insights/protocols-and-agent-checkout/a2a-explained-how-one-agent-proves-what-its-asking-another-to-do" url: "https://selfe.ai/insights/protocols-and-agent-checkout/a2a-explained-how-one-agent-proves-what-its-asking-another-to-do" publisher: "did:web:selfe.ai" description: "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." datePublished: "2026-09-15T10:32:57.331Z" author: The Selfe team --- # 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. ## In short - A2A is how one agent hands a task to another with enough structure to be trusted. - It covers what's being asked and by whom, not whether the task should be approved or paid for. - It's not a fifth job alongside identity, authorisation, connection and checkout; it's what identity and connection look like when a task passes between two agents. - A business's system can end up talking to agents it's never seen before; A2A is what makes that safe to act on. Most descriptions of A2A focus on two AI systems "talking to each other", which undersells what's actually being solved: getting a task description precise enough that acting on it doesn't require blind trust. ## 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. ## Act on this - [Check whether an agent can buy from you](https://selfe.ai/agentic-commerce/buyability-check) — the free readiness scan. - [Discover venues](https://selfe.ai/api/registry/discover) — `POST`, semantic browse across the registry. - [Match a bookable answer](https://selfe.ai/api/registry/match) — `POST` with dates and party size. - [Verify Selfe's identity](https://selfe.ai/.well-known/did.json) — `did:web:selfe.ai`. - [Agent card](https://selfe.ai/.well-known/agent-card.json) — how to connect over A2A or MCP.