Three Agents and a Hoodie: A2A Across the Purchase Lifecycle

Agentic commerce is still early. OpenAI and Stripe put the first real stake in the ground in September 2025 with the Agentic Commerce Protocol — an open standard for an agent running checkout against a merchant it does not own.¹ Google and Shopify followed at NRF in January 2026 with the Universal Commerce Protocol, co-developed with Etsy, Wayfair, Target and Walmart and endorsed by a couple of dozen payment networks.² Plenty of people will tell you the agentic channel is here to stay and will move serious money over the next few years.

Look closer, though, and nearly all of that movement is American. Adoption in Europe is thinner, and I’d expect that to change over the year rather than the quarter. There’s also an ordering problem nobody gets to skip: the human-to-agent journey has to work before agent-to-agent commerce means very much. A shopper has to be willing to hand an agent a card before two agents have anything to settle between them.

But this is AI, and it moves fast. On 17 August the Agent2Agent protocol joined the Agentic AI Foundation, the Linux Foundation body that already houses MCP.³⁴ Two protocols that spent 2025 being described as rivals now sit under the same roof, which is roughly the outcome anyone who had actually read both specs expected.

Which brings me to the part the explainers skip. Almost every agent demo you have seen is one agent with several tools. That shape is easy to build and it teaches you nothing about the actual problem, which is what happens when the parties on either end of a call do not belong to the same organisation and cannot see each other’s data. A merchant’s checkout system, a carrier’s tracking system, and a claims desk are three different parties even inside one company. Between companies it isn’t close.

So this post walks through what an agent-to-agent commerce flow could look like on A2A: three agents that genuinely cannot see each other’s data, handling one purchase from basket to claim, and what the protocol had to do to get them there.

Part 1: Agentic commerce, a primer

Strip the marketing off and agentic commerce is one change: the buyer stops being a human with a browser. What replaces the browsing is a mapping problem — turning a user’s intent into an order intent, and an order intent into a payment intent.

Take “I want to buy red sneakers.” In the human-to-agent shape we have today, the agent maps that to an order intent and comes back with a ranked list to choose from. That is ChatGPT and Gemini right now. The shopper picks the pair they like and, in principle, finishes checkout in the chat.

In practice they mostly don’t. What we have seen so far is that people are happy to do discovery in a chat and then leave — they would rather be handed off to the merchant’s own site to pay. The payment-intent step gets sidestepped, and not for want of plumbing: ACP ships a delegated payment spec, and Google’s AP2 exists for precisely this, modelling a purchase as three signed mandates — intent, cart, payment — which is the same chain written in cryptography.⁵ The capability is further along than the behaviour.

Replace that human with an agent and three things move at once.

Intent gets specified earlier and more completely. A shopper browses; an agent arrives with constraints. “Under 1,200 SEK, delivered before Friday, returnable.” That’s closer to a procurement request than a shopping session, and it rewards merchants who can answer questions rather than merchants who can rank products.

Trust has to become explicit. When a human clicks pay, consent is the click. When an agent transacts, “the buyer agreed to this” becomes something you have to represent, sign, and later prove. This is the whole reason protocols like AP2 and ACP exist, and it’s a different problem from “let agents talk to each other.”

The post-purchase tail becomes the hard part. This is the bit that gets skipped. Buying is one request. Everything after — where is it, it arrived broken, I want my money back — is a long-running conversation across multiple systems, and it’s where most of the operational cost of retail actually lives. A demo that stops at “order placed” has demoed the easy 10%.

And that tail is where agent-to-agent stops being a nice idea and becomes the only shape that works. “Where is my parcel, and can I have my money back?” cannot be answered by one agent with tools, because no single party holds the answer: the merchant knows what was paid, the carrier knows what happened to the box, and the claims desk knows the policy. Three systems, three owners, often three companies.

Note also what is missing here compared to checkout. When a chat can’t close a purchase, there is an escape hatch — hand the shopper to the merchant’s website. There is no equivalent for the tail. The entire value of an agent handling a damaged delivery is that the buyer does not have to go and chase three companies themselves. Take away the coordination and there is nothing left worth automating.

Not to minimise the ordering problem: human-to-agent has to work before agent-to-agent becomes a big thing. But many of the building blocks are already here. I mapped the protocol landscape a while back — MCP for tools, A2A for agent coordination, AP2/ACP/x402 for the money, identity layers on top.⁶ The short version of that piece: no single protocol covers agentic commerce, and pretending otherwise gets you an architecture with a hole in it.

This post is about one layer of that stack — probably the more futuristic one — and about being honest where its edges are.

Part 2: What A2A actually unlocks for commerce

A2A is an open protocol for agents built by different people, in different frameworks, to discover each other and get work done together.⁷ It went 1.0 in March 2026, and 1.0 is what added cryptographically signed agent cards — JWS over a canonicalised card — so a client can verify the card really came from the domain it claims.⁸

The common framing is “MCP connects agents to tools, A2A connects agents to agents.” True, and not the useful part. The useful part is the shape of the interaction.

The card is a business document

An agent card is JSON at a well-known URL describing who the agent is, what it can do, how to reach it, and how to authenticate.⁷ Structurally it resembles an OpenAPI document. Functionally it’s closer to a capabilities statement — the thing a partner reads before deciding whether to integrate.

That distinction matters more than it sounds. A skill description isn’t documentation for a developer who will read it once. It’s the text another agent uses at runtime to decide whether you are the right counterparty. I found myself writing them the way you’d write a service description for a procurement portal, and that was the right instinct.

Signing the card, and the question it forces

v1.0 added JWS-signed cards, so I signed mine. Each agent serves a card with a signature over a JCS-canonicalised body, and the client verifies it before it sends anything. That ordering is the entire point: a card is a claim about who an agent is, and checking it after you have already placed an order is theatre.

Implementing it forced a question I had not thought hard enough about, and it’s the most useful thing I learned building this.

A JWS header can carry a jku — a URL saying where to find the key. It is very tempting to just fetch it. Don’t. A card that names its own key location proves nothing, because anyone who can serve you a card can serve you a matching key; you would be asking the forger to vouch for the forgery. My verifier ignores jku entirely and resolves keys from the origin the card was fetched from — the one thing in the exchange I had already decided to trust:

const verifier = verifyAgentCardSignature(async (kid) => {
// Deliberately NOT the signature's own jku. The only thing worth
// trusting is the origin you already chose to talk to.
const response = await fetch(new URL("/a2a/jwks", origin));
const { keys } = await response.json();
const match = keys.find((k) => k.kid === kid);
if (!match) throw new Error(`No key ${kid} published by ${origin}`);
return match;
});

Which surfaces the honest limit of card signing: it proves a card came from a domain. It does not tell you that domain deserves your money. That’s a different problem, and nobody has solved it — see the closing section.

I also had to decide what to do with an unsigned card. Refusing outright is the satisfying answer and the wrong one right now: it would leave the mesh unable to talk to any agent that hasn’t adopted v1.0 signing. So an invalid signature is refused, an absent one is recorded and allowed, and a real deployment makes that call per counterparty rather than globally.

Tasks are the actual feature

Here’s the thing I’d put in front of anyone evaluating A2A for commerce.

A tool call has two states: you called it, and it returned. Commerce is full of work that fits neither:

• An order total needs a human to approve it. The work isn’t done, isn’t failed, and isn’t running. It’s waiting on you.
• A parcel takes three days to arrive. The work is running, for three days, across an unbounded number of client disconnections.

A2A models both natively. input-required is a first-class task state — the agent stops and says what it needs. Long-running tasks stay in working and emit status updates as things happen, and a client can register a webhook instead of holding a stream open for the duration.⁷

Those two states are, I think, the entire commerce case for A2A. Everything else you could bodge with an HTTP API and a job queue. These are what you’d end up reinventing badly.

What it deliberately doesn’t do

A2A does not authorise payments. It gives you a place to pause for authorisation — that’s what input-required is — but the mandate itself, the cryptographic evidence that a human agreed to spend this money, belongs to AP2 or ACP.⁶ Anyone selling you A2A as an agentic-payments story is selling you a socket and calling it electricity.

It also doesn’t tell you how to select a skill. Cards describe skills; requests carry a natural-language message. There is no method field. For an agent talking to a human’s agent that’s the right call — it keeps agents opaque, which is the design principle. For a merchant’s checkout agent calling a merchant’s shipping agent forty times a second, routing through an LLM to work out that you meant quote_shipping is absurd. Every mesh I’ve seen fills this in privately. Mine does too — a metadata key for machine callers, keyword classification for prose. I’d rather it were standardised.

And that gap is bigger than it first looks, because selecting the skill is only half the job. I had routing working and thought I was done. Then I sent the checkout agent a sentence a real buyer’s agent would send:

I would like to buy two Umai Kanji hoodies, ship them to London please.

It routed to place_order correctly, and then offered me one Nebula Purple hoodie, delivered to Stockholm, in Swedish kronor, ready to confirm. Wrong product, wrong quantity, wrong country, wrong currency — presented as a total to approve. Nothing had failed. The router worked; there was simply no parameter extraction behind it, so every unparsed field fell through to a default that happened to be sitting in the code.

That is the worst failure mode a commerce agent has. A crash is loud. A confidently wrong purchase confirmation is not, and the buyer’s agent has no way to tell the difference — the reply is well-formed, correctly typed, and about the wrong hoodie.

The fix isn’t clever, it’s just a decision: read what the sentence says, and ask about what it doesn’t.

const missing = [
...(items.length === 0 ? ["product"] : []),
...(!country ? ["destination"] : []),
];
// Defaulting here would mean handing back a confirmable total
// for a product nobody named.
if (missing.length > 0) throw new NeedsMoreInfo(askFor(missing), pending);

NeedsMoreInfo becomes an input-required carrying what was understood so far, so the follow-up resumes the original request rather than starting over — a bare “Tokyo” still lands on the place_order that asked the question, instead of falling through to the default skill with no keywords to match on.

Which is the second thing input-required turned out to be for. I reached for it as the payment-confirmation gate. It’s also how an agent says I don’t know enough yet without failing, and that turns a one-shot request into a conversation — the same state, doing two quite different jobs.

Part 3: The build — three agents and a hoodie

I have a demo store called Hoodtopia: Next.js, MedusaJS for real commerce primitives, Kustom for checkout, built originally for a LangChain Stockholm meetup.⁹ It already had a working shipping integration, real per-market carriers, and real order flow. Perfect substrate — the agents wrap something that was already load-bearing rather than a mock.

I added three agents.

That third row is the whole design. The claims agent has to decide whether to refund someone, and it can’t read the order table or the carrier feed. It has to ask.

The shape

graph TD
  S["Shopper agent<br/>(buyer side)"]
  C["Checkout agent"]
  H["Shipping agent"]
  D["Claims agent"]

  S -->|place_order| C
  S -->|track_shipment| H
  S -->|open_claim| D

  C ==>|quote_shipping<br/>book_shipment| H
  D ==>|order_status<br/>issue_replacement| C
  D ==>|shipment_evidence| H

The thick edges are the ones that matter. Those are agents acting as clients of other agents — the same SendMessage call an outside buyer’s agent would make, over the same HTTP, with no privileged back door.

The checkout agent can’t do its job alone

It cannot quote a total, because a total includes delivery and it doesn’t own rate cards. So mid-task, it opens an A2A call of its own:

// It is a server to the buyer and a client to shipping, at the same time,
// over the same protocol. That symmetry is what makes this a mesh.
this.working(task, bus, "Asking the shipping agent for delivery options…");

const shippingResult = await callAgent({
from: "checkout",
to: "shipping",
skill: "quote_shipping",
contextId: task.contextId,
data: {
  country,
  orderAmountMinor: cart.subtotalMinor,
  address: { postalCode: address.postalCode, city: address.city, country },
},
});

Then it stops. It does not place the order:

bus.publish(
AgentEvent.statusUpdate(
  statusUpdate({
    taskId: task.id,
    contextId: task.contextId,
    state: TaskState.TASK_STATE_INPUT_REQUIRED,
    message: this.say(
      task,
      `${summary} to ${quote.address.city}, delivered by ${quote.shipping.name}. ` +
      `Total ${formatMinor(quote.totalMinor, quote.currency)}. Confirm to place the order.`,
      quote,               // the quote rides along as a data part
    ),
  })
)
);

The quote travels in the input-required status message itself, so the follow-up turn can pick it up with no server-side session state. The task is the state. That felt like the protocol working with me rather than against me.

This pause is the seam. In production it’s where a payment mandate gets presented and signed. A2A gives you the pause and stays out of the authorisation — which is correct, and worth being explicit about rather than glossing.

The shipping agent was mostly already written

This is my favourite part, and it’s the least impressive-sounding.

buildShippingOptions() already existed in Hoodtopia. It serves the Kustom Shipping Assistant callback in the live storefront: real per-market carriers, VAT in basis points, free-shipping thresholds, pickup lockers with coordinates. createShipment() already existed too, minting tracking ids in each carrier’s real format — PostNord’s 13-digit, Royal Mail’s XX…GB, UPS’s 1Z….

The agent is a protocol skin over both. That is how agents actually arrive in a commerce stack: not as a rewrite, but as a new interface onto systems that already work.

The genuinely new part is tracking, because tracking is long-running:

// Poll faster than the parcel moves so no scan is missed, and wait well past
// the nominal delivery time before concluding it is stuck — a tight budget
// would report a healthy parcel as lost.
for (let tick = 0; tick < maxPolls; tick++) {
const stage = stageAt(shipment);
if (stage !== lastStage) {
  lastStage = stage;
  if (stage === "delivered") {
    bus.publish(AgentEvent.artifactUpdate({ /* proof-of-delivery */ }));
    this.complete(task, bus, `Delivered. ${shipment.deliveredTo}.`, proof);
    return;
  }
  this.working(task, bus, STAGE_LABELS[stage]);  // still working. for days.
}
await new Promise((r) => setTimeout(r, pollMs));
}

One detail I’d defend: the parcel’s stage is a pure function of (shipment, now), not a timer. A client that resubscribes hours later sees the correct state, because the state was never in the loop — it was always derivable. A long-running task has to guarantee that, and a timer quietly doesn’t.

The claims agent is the one that needs the protocol

Someone says their hoodie arrived soaked. To decide, you need to know what they paid and when (checkout), and whether the carrier ever delivered anything and to whom (shipping). The claims agent has neither. So:

const orderResult = await callAgent({
from: "disputes", to: "checkout", skill: "order_status",
contextId: task.contextId, data: { orderId: claim.orderId },
});

const shipmentResult = await callAgent({
from: "disputes", to: "shipping", skill: "shipment_evidence",
contextId: task.contextId, data: { orderId: claim.orderId },
});

const decision = adjudicate(type, facts);

Before any of that, it asks for a photo — input-required again — and the photo comes back as a file part, actual bytes on the wire, not a URL the agent would have to trust. Multi-modal messages are not a nice-to-have here; evidence you can’t verify the provenance of isn’t evidence.

The table earns its keep in a way I didn’t fully expect until I ran both scenarios. Same policy, same code path, different evidence:

• Delivered + photo + inside the window → replacement, and the claims agent calls back to checkout to actually create it.
• Never scanned past “In transit” → refund, treated as lost in transit.
• Buyer says it never arrived, but shipping holds proof of delivery → rejected, citing the scan.
• Damage claimed on a parcel with no recorded delivery → escalate to a human, because the two accounts don’t line up.

That last one matters. An agent that always produces an answer is worse than one that knows when the evidence is incoherent.

What it looks like running

Here’s the actual trace of one lifecycle — buy, follow the parcel to the door, claim damage — trimmed of the noise:

shopper  → checkout   place_order         Buy one Nebula Fade hoodie in L, to Stockholm.
checkout → shipping   quote_shipping      Delivery options for SE, basket 109900 SEK
shipping → checkout   quote_shipping      3 options to SE, from PostNord Standard (free over 1000 kr).
checkout → shopper    place_order         [input-required] Total SEK 1,099.00. Confirm to place the order.
shopper  → checkout                       Confirmed, place the order.
checkout → shipping   book_shipment       Book PostNord Standard for HT-10001
shipping → checkout   book_shipment       Booked. Tracking id 5C06D21A060ASE.
checkout → shopper                        [completed] Order HT-10001 placed — SEK 1,099.00.
shopper  → shipping   track_shipment      Track 5C06D21A060ASE until it arrives.
shipping → shopper    track_shipment      [working] Label created
shipping → shopper    track_shipment      [working] Picked up by carrier
shipping → shopper    track_shipment      [working] In transit
shipping → shopper    track_shipment      [working] Out for delivery
shipping → shopper    track_shipment      [artifact] proof-of-delivery
shipping → shopper    track_shipment      [completed] Delivered. Handed to recipient at the door.
shopper  → disputes   open_claim          My hoodie arrived soaked and the print is peeling off.
disputes → shopper    open_claim          [input-required] Send a photo of the damage.
shopper  → disputes                       Here is a photo of how it arrived.   ← file part
disputes → checkout   order_status        Order facts for HT-10001
checkout → disputes   order_status        HT-10001: SEK 1,099.00, shipped, placed 2026-08-30T…
disputes → shipping   shipment_evidence   Delivery evidence for HT-10001
shipping → disputes   shipment_evidence   Delivered via postnord (5C06D21A060ASE).
disputes → checkout   issue_replacement   Replacement approved under claim CLM-2001
checkout → shipping   book_shipment       Book replacement delivery for HT-10002
disputes → shopper                        [completed] CLM-2001: replacement.

Thirty-two events, one contextId, three agents, and a loop that closes: a claim ends by creating a new order, which books a new shipment, through the same protocol it started with.

Where I lost time

Build notes are worth more than architecture diagrams, so:

1. The v1.0 method names are not what you think. Every tutorial you’ll find says message/send. In v1.0 it’s SendMessage, SendStreamingMessage, GetTask — PascalCase, from the protobuf service definition. My first request came back -32601 Invalid method and I lost ten minutes to a name.

2. The types are protobuf-shaped, and it shows. Fields are present-but-nullable rather than optional; oneofs surface as { $case: "text", value: "…" }. The in-memory shape is not the wire shape — on the wire, that part is just { "text": "…" } and role is "ROLE_USER", not 1. My debug panel confidently showed the internal representation and labelled it “the wire” until I ran everything back through the SDK’s codecs. If you’re building an inspector, do that from the start.

3. .well-known and the Next.js App Router don’t mix. Next won’t route a path segment beginning with a dot. The card has to live at the spec’s well-known path, so it goes through a rewrite onto a normal route. Ten lines in next.config.ts, but non-obvious at 11pm.

4. One origin, three agents, one well-known path. The A2A discovery path is per-origin. Three agents behind one host means namespacing it — /a2a/checkout/.well-known/agent-card.json — which works fine for clients holding a card URL but breaks “guess the agent from the domain” discovery. It’s a real argument for one agent per host, and a real argument that multi-agent origins need a convention.

5. Serving the signed card is a separate act from having one. I wired the signer into the request handler, watched the tests pass, and then curled the endpoint to find an unsigned card. The route was serving the card object off the runtime; the signature is applied by getAgentCard(). Every client had been told to expect a signed card and the server was publishing a bare one. Read through the accessor, not around it.

6. Pin your state, not your code. Task state lives in memory, so I pinned it to globalThis to survive Next’s hot reload — otherwise a task parked in input-required vanishes the moment you edit a file mid-demo. I pinned the whole runtime, which also pinned the executor, and then spent twenty minutes watching an agent I had definitely just fixed keep serving its old implementation. Pin the stores. Rebuild the handlers.

7. The protocol assumes an agent remembers its own tasks. Serverless doesn’t. Everything worked locally and then fell over on the first real deployment, in four disguises that looked like four unrelated bugs. The scripted lifecycle started in one request and streamed from another, so the platform killed the run the moment the first response was sent — a spinner over an empty timeline. Agent-to-agent hops were traced by whichever process ran the calling agent, which isn’t the process the browser is watching, so the interesting rows simply weren’t there. Each instance minted its own card-signing key, so a client fetching the card from one and the JWKS from another found no matching kid and refused to transact — my own security check, working exactly as designed, against me. And a follow-up answer to an input-required question landed on an instance that had never heard of the task, which surfaced to a shopper as a raw UUID and the word “failed”.

Three of those are mine to fix, and I did: run the lifecycle inside the streaming request; have each agent hand its trace slice back on the result’s metadata so the caller can assemble one timeline; and stop signing when the deployment can scale out and no stable key is configured, since an honestly unsigned card beats an unverifiable one. The fourth isn’t a bug so much as a requirement I hadn’t read carefully. A2A quite reasonably assumes an agent remembers its own tasks, and an in-memory task store on a platform that hands you a different process each request does not. That’s a deployment decision — shared storage, or one long-lived process — and it’s worth making before you promise anyone a demo.

Part 4: Closing remarks

I’ve spent time with ACP, UCP and MCP, but I’d been hesitant to dip my toes into A2A. I’m a firm believer in solving human-to-agent commerce first — the interactions that already have a person, a card and a complaints process attached. Agent-to-agent always felt like the next problem rather than this one.

What changed my mind was the task model. input-required and long-running working are the two states commerce actually needs, and the two a request/response API makes you build yourself, badly, every time. If your domain has work that pauses for a human or runs for days, that’s the argument. If it doesn’t, you may not need A2A at all, and that’s a fine conclusion. It also made the whole thing feel less futuristic than I’d assumed: given adoption, this is a protocol for problems people already have.

Obviously my example is a simplification. But if checkout providers and shipping providers all move to an agentic interface, they need some way to hand work over and to act on behalf of consumers and of each other. The same holds for any domain with more than one party in the loop. Which is why what’s still missing is worth being loud about — a demo that only flatters the protocol isn’t much use to anyone.

There is no dispute standard. My claims agent works because I own all three sides and wrote the policy. Cross-merchant, cross-carrier claims need agreed evidence formats, agreed liability rules, and agreed escalation paths. None of that exists. It’s the largest unclaimed space in agentic commerce and it’s not a protocol problem so much as an industry-agreement problem.

There’s no reputation layer. This one got sharper once I actually implemented signing. My client now verifies every card before it transacts and refuses anything that fails — and that buys precisely one fact: this card came from that domain. It says nothing about whether the domain honours refunds, ships what it sold, or exists next month. Identity without reputation gets you cryptographically verified counterparties you still have no basis to trust, which is a strange and slightly funny place to end up.

Skill selection isn’t specified. I used a metadata key. Someone else used a naming convention. A third person is routing everything through an LLM and paying for it. This will get standardised or it will fragment.

Cross-merchant discovery doesn’t exist. A buyer’s agent can talk to agents it already knows about. Finding merchants who can meet a constraint is a different problem, and right now the answer is a hardcoded list.

None of that is a criticism of A2A, which is scoped sensibly and does its job. It’s an observation that the stack around it is thinner than the enthusiasm suggests — which is exactly what I argued when I mapped the protocol layers,⁶ and I’d now say it more strongly having tried to build in the gaps.

The protocols are converging. A2A and MCP under one foundation is genuinely good news: it makes “which one wins” a non-question and moves the conversation to composition, which is where it should have been all along. The layer that decides whether agentic commerce works isn’t the transport. It’s whether we can agree on what happens when the hoodie shows up soaked.

Everything here is my own writing and my own opinion. It does not represent the views or work of any previous, current or future employer.