Agent Frameworks & Harnesses 2026-09-20

ADK, A2A, and AP2 Are Converging Into One Agent Commerce Stack

Google's three agent protocols -- ADK for building the agent, A2A for agent-to-agent communication, AP2 for payment -- are no longer separate pieces to wire together yourself; a July codelab already builds an end-to-end ticket-booking agent on all three plus UCP for merchant communication.

For most of the last year, ADK (the agent runtime), A2A (the inter-agent communication protocol), and AP2 (the payments protocol) read like three separate Google initiatives that happened to share a vendor. That's changing: a July 2026 Google codelab walks through building an actual ADK agent that books movie tickets, using UCP for merchant communication and AP2 for secure payment -- a concrete, working example of the stack composed end to end rather than three docs pages describing compatible-in-theory pieces.

AP2's specific contribution is worth being precise about: it's not just "agents can now pay for things," it's typed mandates that provide non-repudiatable proof of intent and enforce configurable guardrails on every transaction. That's the actual hard problem in agent commerce -- not moving money, but proving afterward that the human actually authorized this specific agent to spend this specific amount on this specific thing, in a way that holds up if it's disputed. A payments protocol without that is a liability generator, not a feature.

A2A's role in the stack is the connective tissue: Google's own developer blog is now publishing guides specifically on building cross-language multi-agent teams with ADK and A2A together -- agents written in different languages, on different runtimes, discovering and coordinating through the protocol rather than through a shared codebase. That's the scenario A2A was designed for, and the fact that it's showing up in "how to actually build this" content rather than only announcement posts is a real adoption signal, not just protocol maturity.

The practical read: if you're building an agent that needs to transact (buy something, book something, pay for something on a user's behalf) on Google's stack, the pieces to evaluate now are ADK + A2A + AP2 + UCP together, not ADK alone with a payments integration bolted on separately. The codelab existing at all is the signal that this composition is now a supported, documented path rather than something you'd have to figure out yourself.

AP2's actual contribution is non-repudiatable proof of intent on every agent-initiated transaction, not payment processing itself -- that's the part worth evaluating carefully before letting an agent transact on a user's behalf, and the fact that ADK+A2A+AP2+UCP now has an official end-to-end worked example means the integration risk of composing them has dropped significantly.