What Google Cloud Next 2025 Got Right About A2A

What Google Cloud Next 2025 Got Right About Agent Interoperability

Google Cloud Next 2025 put a real constraint at the center of the agent conversation: specialized agents are not very useful as an ecosystem if each one can communicate only inside its creator's stack.

Venture Step E065 recognized that constraint early. The episode also moved quickly from an open coordination protocol to a scalable agent economy. A year later, the interoperability thesis has held up better than the economic forecast. A2A gained neutral governance and a 1.0 specification, but safe delegation still depends on identity, authority, semantics, observability, and recovery that no message protocol supplies by itself.

The launch made the walled-garden problem concrete

Dalton recorded E065 after watching the Google Cloud Next keynote and its agent demonstrations. He framed the problem through specialized systems: a customer-service agent, a shopping agent, a shipping process, and an approval path might each work within a silo, yet fail when a user needs one coherent outcome.

The episode's strongest observation was that agent capability and agent coordination are separate problems. A model can reason well and a tool can perform a task, but a cross-company workflow still needs a way to discover another system, ask for work, follow its state, and receive a result.

Google's April 9, 2025 announcement described A2A as an open protocol for collaboration across vendors and frameworks. It introduced Agent Cards, messages, tasks, artifacts, long-running state, and support or contributions from more than 50 named technology and service partners.

That was a launch record, not proof that every partner had a production deployment. The distinction matters when revisiting the episode.

The demo showed orchestration, not one magical agent

The customer scenario that caught Dalton's attention combined product advice, visual context, a shopping-cart correction, installation scheduling, and a manager approval for a discount.

What made the scenario interesting was not a single answer. It was the handoff among capabilities while the customer stayed in one conversation. A human entered at the point where the system's authority ran out, and the workflow continued after the decision.

That remains a useful product pattern:

flowchart LR
    U["Customer request"] --> F["Front-door agent"]
    F --> S["Specialist capability"]
    S --> P["Proposed action"]
    P --> H{"Policy or human approval"}
    H -->|"Approved within limit"| X["External action"]
    H -->|"Changed or rejected"| F
    X --> R["Verified result for customer"]

The polished experience can hide difficult questions. Which agent saw the customer's image? Who could modify the cart? What did the manager approve? Did the downstream agent receive a broad account token? What happens if scheduling succeeds after the customer cancels?

Those questions are not objections to interoperability. They are the work that begins after the demo.

E065 correctly separated A2A from MCP

The episode introduced Anthropic's Model Context Protocol as a standard route to external tools and current information, then described A2A as communication among agents.

That distinction remains broadly correct. The current A2A specification describes MCP as complementary. A client agent can ask a remote agent to complete a task through A2A. The remote agent can use MCP servers to reach tools, APIs, and data during that work.

The current stable contracts make the separation clearer. A2A 1.0 centers Agent Cards, messages, tracked tasks, task state, and artifacts. MCP's November 25, 2025 stable specification centers a host application, clients, servers, tools, resources, prompts, and related capabilities.

Neither should be selected from a slogan. [[A2A vs. MCP - Which Relationship Does Each Standardize]] maps the decision to the architecture boundary.

A2A moved beyond Google's launch home

The episode described Google as the proposer of an open protocol. Two months after the launch, the Linux Foundation announced A2A as a foundation project, identifying Google as the original creator and the foundation as the project's new neutral home.

Today, the current specification identifies A2A 1.0.0 as the latest released version. It defines multiple protocol bindings, explicit version handling, richer task states, Agent Card security schemes, optional card signatures, authenticated extended cards, and in-task authorization behavior.

Neutral governance and a released specification are meaningful infrastructure. They improve the conditions for multiple implementers to build against a shared contract.

They do not establish universal adoption or reliable production interoperability. Those claims require conformance results, active deployments, workload evidence, and outcome measurement.

The durable insight was specialization with opacity

E065 argued that one agent would not be best at every task. That remains a sensible reason for delegation, but specialization alone is not enough.

The stronger architectural reason is independent ownership. A remote agent may belong to another company, protect a proprietary implementation, operate under a separate security policy, or own a regulated responsibility. The caller needs a useful contract without gaining access to the remote agent's private memory, prompts, tools, or source code.

A2A's task and artifact model is designed for that boundary. It lets the remote system own how the outcome is produced while exposing enough state for coordination.

Opacity also creates risk. The caller has less visibility into how the remote agent selected tools, interpreted instructions, or handled data. Verification and policy become more important, not less.

The protocol does not eliminate the trust layer

An Agent Card can advertise a skill. It cannot prove the provider is approved or the skill performs well. Authentication can establish a client identity. It cannot determine whether the client should purchase, disclose, delete, or send on a user's behalf.

A completed task can return an artifact. It cannot prove the artifact is semantically correct or that an external side effect matches the user's intent.

The production trust layer still needs provider admission, card verification, version control, least authority, data minimization, tenant isolation, artifact validation, time and cost limits, idempotency, cancellation, compensation, logging, and incident response.

[[How to Verify an Agent Card Before Capability Discovery]] covers admission. [[How to Secure Cross-Agent Delegation]] covers the authority boundary.

The agent-economy forecast remains a separate problem

Near the end of E065, Dalton imagined agents hiring people, renting robots, paying other agents, and coordinating physical work.

A coordination protocol is one ingredient in that future. Economic action also needs identities that can be held accountable, delegated spending authority, price and tax rules, settlement, fraud controls, disputes, refunds, contracts, regulatory compliance, and responsibility when an agent's action causes harm.

A2A does not define that economic system. The episode was right to see transactions as another missing layer. It was too early to treat that layer as the last step.

What E065 looks like after A2A 1.0

The episode's central thesis survived: open coordination across independent agent systems is a real infrastructure need, and it is different from connecting an AI application to tools.

The revised conclusion is narrower. A2A can standardize how agents describe capabilities and exchange tasks, state, and artifacts. It can reduce custom coordination code. It cannot make an untrusted agent trustworthy, an ambiguous result correct, or an excessive delegation safe.

That is not a weakness in the protocol. It is a clearer boundary for builders.

Listen to E065 on Spotify or watch the episode recording on YouTube. The recording preserves Dalton's April 2025 reaction. [[How the A2A Protocol Works]] provides the current version-pinned explanation.

This article preserves April 29, 2025 as the original publication date and was reviewed on July 28, 2026. It was developed with AI assistance and checked against the raw transcript, Google's launch announcement, the Linux Foundation governance announcement, and the A2A 1.0 specification. Dalton Anderson is responsible for the final editorial judgment.