Playbook
Tasteful Skills
“Tasteful Skills” argues that the best agent skills are not documentation or best-practice lists.
Back to Podcast Digest
Google Spent a Year Stitching MCP, A2A, AG-UI Together. I/O Today.
TL;DR
Three protocols are becoming the real agent stack: MCP, A2A, and AG-UI — Nate argues they map cleanly to the three core questions in agent systems: what tools an agent can use, which other agents it can work with, and how humans stay in control.
MCP won early because it fixes the most painful problem in 2024-style agents: getting beyond the chat box — instead of custom glue for GitHub, Slack, Drive, Postgres, Stripe, Linear, and Salesforce, builders now have a standard with 14,000+ MCP servers and support from tools like Claude Desktop, Codex, and Google.
MCP is not a safety layer, and treating tool access like a simple feature toggle is dangerous — Nate highlights Invariant Labs' research on tool poisoning attacks and says teams shipping MCP still need scopes, approval flows, audit trails, and clear rules for which tools agents can see in which context.
A2A matters when work crosses domains, but it adds real coordination costs — Google launched it with 50+ partners including Atlassian, Box, Cohere, MongoDB, PayPal, and Workday, centered on an 'agent card' that declares what an agent does, how to reach it, and what it can safely accept.
AG-UI is less about flashy front ends and more about solving the human trust problem in long-running agents — for agents that stream, pause, wait, call tools, and need approvals, Nate says the real issue is avoiding 'supervision debt' by giving users the right control points, not just a progress spinner or nicer chat UI.
The rest of the protocol pile—A2UI, AP2, and X42—is important but still contested or narrow — A2UI handles safe structured interface rendering, AP2 tackles cryptographically authorized agent purchases with 60+ collaborators like American Express, Mastercard, PayPal, and Coinbase, while X42 focuses on machine-to-machine HTTP-native payments, especially for agent resource purchases.
The Breakdown
The real story under Google I/O isn't demos—it's protocol plumbing
Nate opens by saying the interesting part of Google I/O isn't the flood of agent demos, but the infrastructure underneath them. He frames the mess clearly: six protocols in a year—MCP, A2A, AG-UI, A2UI, AP2, and X42—and says builders are staring at an acronym scrum that feels impossible to parse.
Three questions cut through the acronym chaos
His organizing lens is simple and useful: what can the agent use, who else can it work with, and how does the human stay in control? That lets him sort the pile into a likely core stack—MCP for tools and data, A2A for delegation, and AG-UI for human control—versus the more contested or domain-specific layers.
MCP gave agents reach, but not judgment
Nate explains why MCP took off so fast: before it, every connection to Slack, GitHub, Drive, Stripe, Salesforce, or an internal API was bespoke glue code. MCP standardizes tool discovery and invocation, which is why there are now more than 14,000 MCP servers and broad support across agent products—but he is emphatic that this does not make tool use safe.
The scary part: tool access is a security boundary
This is where the tone sharpens. He points to Invariant Labs' tool poisoning research, where malicious instructions can hide inside tool descriptions themselves, and warns that teams treating MCP like a harmless toggle are kidding themselves. His line is memorable: MCP gets the agent close to the work; it does not decide whether the agent should do the work.
A2A is Google's bet on cross-company agent delegation
Once an agent has tools, the next problem is that no single agent knows everything. Nate uses concrete examples—a procurement agent needing a supplier agent, a travel agent needing a hotel agent, a software agent needing a security reviewer—and says A2A turns this distributed reality into something agents can reason about through the 'agent card,' a kind of operating contract.
AG-UI is the underrated trust layer
He thinks most people misread AG-UI as a UI protocol when the bigger point is trust. Long-running, non-deterministic agents need streaming state, approvals, interruptions, and course correction, and Nate says a chatbot plus a few approval buttons is not enough; otherwise teams end up with what he calls 'supervision debt' for humans.
Why A2UI, AP2, and X42 are not the core stack—at least not yet
A2UI, in his view, is useful but narrower: it safely renders structured interfaces from trusted components instead of arbitrary HTML or JavaScript, which he calls 'a security disaster waiting to happen.' AP2 and X42 sit in payments, where the land grab is intense—AP2 is about proving the user authorized a purchase through signed mandates, while Coinbase-backed X42 is about HTTP-native machine payments for things like API calls, documents, or benchmark runs.
The builder takeaway: stop obsessing over models and specify the operating surface
Nate closes by urging teams to define the actual workflow first—support triage, procurement, renewal prep, sales analysis—and then map it to substrate questions: tools, delegated agents, approval points, structured UI, purchases, and autonomous payments. His challenge for Google I/O is blunt: can Google stitch MCP, A2A, A2UI, and AP2 into one buildable operating model, or will it just add more acronyms to the pile?
Share
Keep Reading
Two Ways to Follow
The Weekly Echo. The inbox-shaped summary of what mattered.
New editorials announced here.
