Blog · Analysis · May 2026

The Agent-to-Agent Protocol Becomes the Handshake

Agent-to-agent protocols make AI systems interoperable. They also create a new institutional handshake where discovery, delegation, identity, consent, and audit have to survive across agents.

From Tool Use to Agent Use

The first governance problem of AI agents was tool use. A model could call a calendar, query a database, send an email, edit code, search a drive, or operate a browser. That moved the trust boundary from the chat window into connectors, permissions, logs, and tool descriptions.

The next problem is agent use. One agent asks another agent to do work. A workplace assistant calls a procurement agent. A customer-support agent asks a billing agent for account state. A travel agent asks a payment agent to hold a fare. A hiring agent asks a sourcing agent to find candidates, then another agent to schedule interviews, then another to run a background-check workflow. A research agent asks a specialized data-analysis agent to produce an artifact, while a compliance agent watches the task state.

This is the shift that Agent2Agent, or A2A, tries to standardize. Google announced A2A on April 9, 2025 as an open protocol for agent interoperability, with more than 50 initial technology and services partners. In June 2025 the Linux Foundation announced the Agent2Agent project, describing A2A as an open protocol created by Google for secure agent-to-agent communication and collaboration. The current A2A specification describes an open standard for communication between independent, potentially opaque AI agent systems.

Interoperability is useful. Enterprises do not want every agent trapped inside one vendor's platform, one framework, or one workflow surface. They want agents that can discover each other, exchange task state, pass artifacts, stream progress, request authorization, and complete work across systems.

But interoperability is never only technical. A protocol that lets agents find and use one another also creates a new institutional handshake. The question is not only "Can these agents talk?" The question is "What authority travels when they talk?"

What A2A Standardizes

A2A is not a replacement for tool protocols such as Model Context Protocol. Google's announcement explicitly framed A2A as complementary to MCP: MCP connects agents to tools and context, while A2A connects agents to other agents. The distinction matters. A tool usually exposes a defined operation. An agent may interpret, plan, negotiate, ask for more information, produce artifacts, and delegate further.

The A2A specification centers on several objects: an A2A client, an A2A server or remote agent, an Agent Card, messages, tasks, parts, artifacts, streaming updates, push notifications, context identifiers, and extensions. The protocol supports JSON-RPC, gRPC, and HTTP/REST bindings. Its goals include capability discovery, modality negotiation, collaborative task management, secure information exchange, long-running tasks, and opaque execution without requiring agents to share internal memory, tools, or plans.

That last feature is both sensible and politically important. Agents should not have to reveal everything about their internals to collaborate. A payroll agent, legal agent, medical agent, or vendor agent may need to expose what it can do without exposing private data, proprietary prompts, internal policy logic, or full tool chains. A2A therefore imagines a world of cooperation among bounded systems.

The boundedness is the hard part. When an agent is treated as a remote actor, its output may carry institutional weight without giving the receiving user a complete view of how the answer was produced. The client agent may know the remote agent's declared skills, endpoint, authentication scheme, task status, and artifacts. It may not know the remote agent's training data, hidden prompt, retrieval sources, vendor incentives, internal confidence, or downstream dependencies.

That is not a reason to reject the protocol. It is the reason to govern it as infrastructure rather than treating it as a neutral message format.

The Agent Card as Passport

The Agent Card is the obvious governance object inside A2A.

The specification says A2A servers must make an Agent Card available. The card describes identity, capabilities, skills, interaction requirements, service endpoints, and authentication requirements. The protocol also defines a standardized discovery location at /.well-known/agent-card.json, and it allows Agent Cards to be digitally signed using JSON Web Signature so clients can verify that a card has not been tampered with and comes from the claimed provider.

That makes the Agent Card a kind of passport. It is not the agent itself. It is the document the agent presents at the border of another system: here is who I claim to be, here is what I can do, here is how to reach me, here is what credentials I require, here are my supported interfaces, and here is the version of the declaration you should rely on.

Passports are powerful because institutions believe them. They also require issuing authority, revocation, inspection, expiry, and fraud controls. The same is true here. A signed Agent Card helps with integrity, but it does not answer every trust question. A malicious provider can sign a malicious card. A legitimate provider can overstate a skill. A card can be stale. A public card can omit important limits. An extended card can expose privileged capability details after authentication. A client can cache a card after the agent's behavior or policy changes.

The governance lesson is simple: discovery metadata becomes operational authority. If a client agent chooses a remote agent based on a card, then the card has helped determine the user's practical world. It should be versioned, signed where appropriate, cached carefully, reviewed, and tied to logs of what the remote agent was asked to do.

Delegation Chains

A2A becomes most interesting when delegation forms a chain.

The specification defines in-task authorization. During a task, an agent may need authorization to perform an action, such as an OAuth access token for an API or human approval before a destructive operation. The protocol provides a TASK_STATE_AUTH_REQUIRED state so an agent can ask the client to resolve that authorization request. If the client is itself another A2A agent, it can further delegate the authorization request to its own client, forming a chain of tasks waiting for authorization.

That is exactly where institutional accountability can blur. The human may ask one assistant for a result. That assistant calls a remote agent. The remote agent calls another service or asks for credentials. Another agent may request human approval. By the time the work finishes, the final answer has passed through a chain of interpretations, permissions, identities, logs, and artifacts.

The specification is aware of credential risk. It recommends out-of-band secure channels for credentials and warns that in-band credential exchange across chains can expose credentials to every agent participating in the chain. It also says implementations must enforce authorization checks and scope results to the caller's authorized access boundaries.

Those requirements are necessary. They do not remove the governance problem. Authorization is not only a token check. It is a social and institutional question: what did the user actually authorize, which agent had permission to ask for more authority, what was the remote agent allowed to infer, what data crossed the boundary, and which institution is responsible if the chain produces harm?

In ordinary enterprise systems, service-to-service calls are already hard to govern. A2A adds semantic actors. The receiving system is not merely processing an API request. It is interacting with another agent that may summarize intent, negotiate modalities, pass artifacts, ask for credentials, and continue work asynchronously. The audit trail has to preserve more than a request ID. It has to preserve delegation meaning.

Failure Modes

The first failure mode is agent impersonation. If discovery, signing, DNS, registry governance, or client verification is weak, an agent can present itself as a trusted specialist and receive tasks or data it should never see.

The second is capability overclaiming. An Agent Card says the remote agent can perform a skill, but the skill is brittle, biased, unsafe, unlicensed, stale, or narrower than the client assumes. The card becomes marketing copy disguised as machine-readable trust.

The third is delegation laundering. A human authorizes one agent to do a task. That agent delegates to another agent whose methods, data access, vendor incentives, or jurisdiction would have mattered to the human if shown plainly.

The fourth is authorization diffusion. A credential or approval travels through a chain until no single actor can clearly explain which agent used which authority for which action.

The fifth is artifact laundering. A remote agent returns a clean document, score, recommendation, route, or summary. The client agent treats the artifact as evidence without preserving enough source trail, task history, version, or uncertainty to challenge it later.

The sixth is observability collapse. Each agent logs its own slice of the workflow, but no institution can reconstruct the whole path after a failed hire, mistaken payment, bad medical triage, unauthorized disclosure, or corrupted record.

The seventh is vendor-neutral capture. An open protocol can reduce one form of lock-in while creating another: organizations become dependent on the registries, certification schemes, cloud endpoints, identity providers, observability layers, and governance bodies that decide which agents are reachable and trusted.

The Governance Standard

A serious agent-to-agent governance regime should treat every inter-agent call as delegated institutional action.

First, agent identity needs verification. Agent Cards should be signed where risk warrants it, retrieved over secure channels, tied to provider identity, checked for version changes, and revocable when compromised.

Second, capability claims need evidence. A skill declaration should link to scope limits, evaluation evidence, supported data types, human oversight requirements, safety constraints, known limitations, and the authority needed to perform the skill.

Third, delegation needs a visible chain. The user and the accountable organization should be able to see which agent called which agent, why, under what identity, with what task, with what data, and with what result.

Fourth, credentials should be bound and minimized. Credentials should be scoped to a task, agent, time window, and action class wherever possible. Broad reusable tokens should not drift across agent chains.

Fifth, authorization prompts should name the remote actor. A user should not only approve "continue." The prompt should show which agent is asking, what it will do, what data it will receive, what authority it needs, and whether it may delegate further.

Sixth, artifacts need provenance. Outputs from remote agents should carry task IDs, agent identity, version, timestamps, relevant inputs, source references where available, and limits on reuse.

Seventh, logs need cross-agent correlation. A chain of agents should produce traces that can be joined during incident review without turning every private user interaction into unnecessary surveillance.

Eighth, high-impact domains need admission rules. Hiring, credit, insurance, health, education, public benefits, legal work, public safety, and employment discipline should not accept arbitrary remote agents just because they speak the protocol.

Ninth, protocol governance should remain public enough to challenge. Standards bodies, open-source foundations, vendors, regulators, researchers, and affected communities should be able to inspect how the protocol evolves, especially around identity, authorization, logging, and human review.

The Spiralist Reading

The handshake is where one institution decides another may enter the room.

Agent-to-agent protocols make that handshake fast, machine-readable, and repeatable. That is their strength. A task that once required a human to copy information between systems can move through specialized agents. Work can be decomposed, routed, streamed, resumed, and assembled. The interface feels less like a tool belt and more like an office that knows whom to call.

But an office is not only a workflow. It is a structure of trust. Reception, identity, delegation, authorization, recordkeeping, supervision, and appeal are part of what makes work accountable. When agents call agents, those old institutional functions do not disappear. They become protocol fields, signatures, logs, cards, task states, approval prompts, and governance defaults.

The danger is that delegation becomes too smooth to see. A user asks for an outcome. The first agent nods. Other agents act behind the surface. A final artifact returns with the calm tone of completed work. The system has compressed an institutional chain into a single answer.

The useful discipline is to keep the handshake visible. Name the agent. Name the card. Name the task. Name the credential. Name the delegation. Name the artifact. Preserve enough trace to contest the result.

The future of AI institutions will not be built only from better models. It will be built from the protocols that decide which artificial actors may speak, act, remember, and ask for power on one another's behalf. The agent-to-agent handshake is one of those protocols. It should be treated as governance before it becomes plumbing.

Sources

Return to Blog