Agent-to-Agent (A2A) Protocol: Interoperable Multi-Agent Systems

Modern AI systems rarely live in a single runtime. They span products, vendors, and frameworks, and they need a common way to collaborate without leaking internal logic. The Agent2Agent (A2A) Protocol is an open standard initiated by Google and hosted under the Linux Foundation to make that collaboration predictable, secure, and observable across stacks.

What is the A2A Protocol

A2A is an open protocol that standardizes how agents discover each other, exchange messages, and manage long-running tasks. The official A2A project describes it as a way for opaque agentic applications to interoperate without sharing internal memory, proprietary tools, or implementation details. It defines a shared language and common interaction patterns so agents can collaborate across ecosystems.

Key points from the official A2A materials and spec:

• Standardized communication uses JSON-RPC 2.0 over HTTP(S), with bindings for GRPC and HTTP+JSON as well.
• Agent discovery happens through an Agent Card, a structured manifest that advertises interfaces, capabilities, and security requirements.
• Task management is first-class, with explicit task state transitions and artifacts.
• Security and authentication are built in through OpenAPI-style security schemes and OAuth 2.0 metadata support.
• Observability is supported via metadata fields on messages, tasks, and events.

Sources: A2A project README and specification (https://github.com/a2aproject/A2A, https://a2a-protocol.org/latest/specification/), JSON-RPC 2.0 spec (https://www.jsonrpc.org/specification), OAuth 2.0 (https://www.rfc-editor.org/rfc/rfc6749), OAuth Authorization Server Metadata (https://www.rfc-editor.org/rfc/rfc8414).

Why it Matters

Multi-agent systems fail when they lack a shared contract. Teams resort to ad hoc APIs, brittle adapters, and per-vendor routing logic. A2A matters because it creates a standard layer that lets you compose agents like services, while retaining privacy and governance boundaries.

"Interoperability is not optional once your system crosses organizational boundaries."

Practical benefits:

• Interoperability: a client can talk to any A2A-compliant agent as long as it can parse the Agent Card and speak the chosen interface.
• Security: strong authentication choices are described at the protocol level (API keys, OAuth 2.0, OIDC, mTLS), making policy enforcement consistent.
• Observability: metadata fields allow trace IDs, request IDs, and audit tags to flow end to end.
• Governance: the project is open source under the Linux Foundation and Apache 2.0, giving teams transparent stewardship and contributor guidance.

Architecture / How it Works

A2A centers on a few core objects and interfaces described in the official proto specification. Think of it as a transport-agnostic contract that can be bound to JSON-RPC, GRPC, or HTTP+JSON.

Core objects (from the A2A spec):

Interfaces and transport options:

• JSON-RPC 2.0 over HTTP(S) for standard request/response and notifications.
• GRPC for high-throughput or strongly typed workflows.
• HTTP+JSON bindings for REST-like access to core methods (e.g., message send, task list).

Security model at a glance:

• Agent Cards can include security schemes modeled after the OpenAPI 3.2 Security Scheme object.
• OAuth 2.0 flows and metadata endpoints are referenced directly, enabling dynamic configuration.
• mTLS and API-key schemes are first-class options for regulated environments.

This architecture lets agents stay opaque while still being discoverable and interoperable. An agent exposes its capabilities, but not its chain-of-thought, internal memory, or tool stack.

Step-by-Step Example

Below is a practical, vendor-neutral flow aligned with the A2A spec and HTTP+JSON bindings.

Step 1: Discover the Agent Card

The Agent Card describes how to contact the agent and what it can do.

{
  "name": "Claims Triage Agent",
  "description": "Routes and summarizes insurance claims.",
  "supported_interfaces": [
    {
      "url": "https://api.example.com/a2a/v1",
      "protocol_binding": "HTTP+JSON",
      "protocol_version": "0.3"
    }
  ],
  "provider": {
    "url": "https://example.com",
    "organization": "Example Insurance"
  },
  "version": "1.2.0",
  "capabilities": {
    "streaming": true,
    "push_notifications": true,
    "extended_agent_card": true
  },
  "default_input_modes": ["text/plain", "application/json"],
  "default_output_modes": ["text/plain", "application/json"],
  "skills": [
    {
      "id": "claim-triage",
      "name": "Claim Triage",
      "description": "Classify claims and propose next actions.",
      "tags": ["claims", "triage", "routing"],
      "examples": ["Classify claim ID 12345 for urgency"]
    }
  ]
}

Step 2: Send a message to start a task

Use the HTTP+JSON binding for the SendMessage method.

POST /message:send HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer YOUR_TOKEN

{
  "message": {
    "message_id": "msg-001",
    "role": "ROLE_USER",
    "parts": [
      {
        "text": "Classify claim 12345 and summarize key risks.",
        "media_type": "text/plain"
      }
    ]
  },
  "configuration": {
    "accepted_output_modes": ["application/json"],
    "blocking": false
  },
  "metadata": {
    "trace_id": "7f2b2e7f0a1c4d87",
    "request_id": "req-9b5f"
  }
}

Step 3: Track task state

The response can include a Task with a TaskState such as SUBMITTED or WORKING. Later, you can query GET /tasks/{id} to retrieve the latest status and artifacts.

Step 4: Subscribe or receive push notifications

If the Agent Card advertises push notifications or streaming, use GET /tasks/{id}:subscribe or configure a push notification target for real-time updates.

Step 5: Consume artifacts

Artifacts can include text, files, or structured JSON. Each artifact contains parts that carry content and a media_type to support multiple modalities.

This flow stays interoperable because it uses the same Task and Message structures regardless of the agent framework behind the endpoint.

Best Practices

• Prefer Agent Card driven discovery, and treat the card as the single source of truth for security, skills, and interface selection.
• Align on JSON-RPC 2.0 semantics even when using HTTP+JSON bindings to keep request and response envelopes consistent across transports.
• Use OAuth 2.0 or OIDC where user context is needed, and point clients to RFC 8414 metadata endpoints for dynamic configuration.
• Propagate trace IDs and audit metadata in Message.metadata and Task.metadata to enable end-to-end observability.
• Define governance rules for skill naming, versioning, and deprecation so downstream agents are not surprised by breaking changes.

Tip: Treat A2A as a contract. Version your Agent Card, publish changelogs, and test compatibility with a sample client before shipping updates.

Common Mistakes

• Hard-coding endpoints and skipping Agent Card discovery, which breaks interoperability when interfaces change.
• Ignoring task lifecycle states like INPUT_REQUIRED or AUTH_REQUIRED, leading to stalled workflows.
• Mixing transport bindings in the same integration without clear routing rules.
• Omitting security schemes in the Agent Card, which forces clients to guess authentication.
• Dropping metadata on the floor, making it impossible to trace multi-agent flows.

Real-World Use Cases

• Customer support: route tickets among specialized agents for triage, summarization, and resolution.
• Healthcare workflows: coordinate scheduling, insurance verification, and clinical note drafting.
• Finance ops: validate invoices, detect anomalies, and request human approvals in a governed pipeline.
• Software delivery: connect code review, security scanning, and deployment agents under a shared task context.
• Research copilots: have a sourcing agent provide citations while a synthesis agent composes a report.

Conclusion

A2A gives multi-agent systems a shared, open protocol that prioritizes interoperability, security, observability, and governance. By combining Agent Card discovery, structured tasks, and standards like JSON-RPC 2.0 and OAuth 2.0 metadata, teams can compose agent ecosystems that scale across vendors and deployments.

If you are designing multi-agent systems, start by reading the official A2A specification and docs, and model your security and observability around the fields already defined in the protocol. That alignment is what turns a collection of agents into a reliable, interoperable platform.