Google introduces the Agent2Agent protocol

Google introduced Agent2Agent, an open protocol intended to help agents communicate, collaborate, and delegate work across frameworks. The announcement described interoperability patterns including capability discovery and task exchanges, while leaving authentication, authorization, trust policy, and risk acceptance to implementers and operators for each participating service.

By Hypler editorial team · Source: Google.

Original source date: 2025-04-09.

Hypler publication: 2026-10-06. Hypler updated: 2026-10-10.

Topics: A2A, interoperability, agents

Google logo

Generated editorial illustration. Agent2Agent task exchange illustrated as sealed messages crossing checkpoints between distinct workspaces. Credit: Hypler / AI-generated editorial illustration. Hypler editorial asset; not vendor or event photography

Generated illustration of isolated tool-execution fixtures and a controlled test gate; not deployed software. Credit: Hypler / AI-generated editorial illustration. Hypler editorial asset; not vendor or event photography

Engineering relevance

Agent-to-agent messaging expands the identity boundary. Require authenticated participants, explicit delegation policy, structured task state, and audit trails before connecting autonomous services there.

Announcement record

Why it matters

What the announcement established

Google's April 9, 2025 Agent2Agent announcement described an open protocol for agents to communicate, discover capabilities, and exchange tasks across frameworks. Interoperability solves a transport and representation problem; it does not answer whether one service should trust another's identity, accept its delegated authority, or reveal data to it. A task card can say that an agent is capable of an action without proving that the caller may ask for it in this transaction. This historical release description should not be read as a claim about a current protocol version, certification, production interoperability, or security posture for any particular implementation.

Delegation needs attenuation

A delegated grant must be narrower than the caller's grant, not a copied session token. Bind it to an audience, task ID, capability list, data classification, expiry, spend or action budget, and revocation handle. The receiving agent should authenticate the caller independently, validate the task schema, and decide whether local policy permits the request. Capability discovery should expose only public metadata until a trust relationship exists; otherwise an endpoint inventory becomes a map of sensitive operations. Hypler can treat A2A-style messages as transport envelopes around its own policy and receipt model rather than outsourcing its authorization semantics to a protocol.

Cross-service failure surfaces

Failures include replayed task messages, confused deputy actions, mismatched status vocabularies, duplicate callbacks, an agent reporting success before its child task completes, and a revoked delegation arriving after delivery. Do not infer completion from a text summary. Use signed, idempotent state transitions and explicitly model accepted, in_progress, blocked, failed, cancelled, and completed outcomes. Correlate every child task with its parent and preserve a reason for denial. If a remote agent cannot return evidence that local policy requires, its result can remain informational but must not trigger an execution path.

Hypothetical procurement handoff

Hypothetical: an internal planning agent asks an external catalog agent to compare approved integrations. The caller grants only a read-only search scope for a list of vendor categories, with a fifteen-minute expiry. The recipient verifies the caller signature, returns candidates plus source URLs, and cannot see budgets, internal notes, or procurement credentials. A malicious response tries to include a command to enable a connector; the local orchestrator treats that as content, not a task transition. A human analyst selects one candidate, and a separate local approval process starts any onboarding work. The end-to-end receipt identifies both agents, grants, task states, source evidence, and denial of the unapproved enable request.

Acceptance checks before connection

Test expired and revoked grants, wrong audience, replayed task IDs, schema downgrade, unknown capability claims, callback duplication, remote timeout, and a remote response with an embedded instruction. Assert that an external agent cannot escalate a read scope into a write scope or cause a local tool call through prose. Verify status mappings preserve failure and cancellation rather than coercing them into success. Exercise key rotation and audit-log retrieval. Require an operator-visible provenance chain from parent task to child evidence. Passing a protocol conformance test is necessary but insufficient; local authorization, data classification, and incident handling need their own evidence.

Hypler connection

Hypler evaluates inter-system delegation as a controlled exchange of bounded work, identity, status, and evidence. Compatible messages alone are insufficient; the implementation must preserve authorization boundaries, make child-task outcomes inspectable, and give operators a reliable way to deny, revoke, or recover a request.

Trust onboarding sequence

Onboard an external agent like a new service, not like a chat participant. Start with identity verification and read-only test tasks against synthetic data. Review its task schema, error model, callback behavior, retention claims, and incident contact before exposing a real capability. Add one capability at a time and test revocation after each grant. A remote service should not receive a production trust tier because it can parse a protocol card. The operating team needs a documented owner for policy, key rotation, telemetry, and offboarding. Test a deliberate protocol-version mismatch before trusting error handling, because ambiguity during upgrade is a common source of unsafe fallback behavior. This gradual sequence creates evidence about a relationship instead of assuming that interoperable messages imply compatible risk controls.