IM Engineer Study Notes
← Back to list
AI & Data
#A2A#멀티에이전트#Agent Card#상호운용#MCP
Last updated · 2026-10-26

A2A (Agent2Agent) Protocol

1. Overview

Definition: A2A (Agent2Agent) is an open, application-layer protocol that standardizes how autonomous AI agents built on different vendors and frameworks discover one another and delegate and collaborate on work without exposing their internal implementations. It is an "interoperability standard for agents" that operates on top of agent-metadata-based discovery (Agent Card) and a common object model of Task, Message, and Artifact.

As generative AI evolves beyond simple question-answering into a multi-agent regime where multiple specialized agents cooperate to carry out complex tasks, the biggest challenge has shifted from a model's reasoning ability to how to safely connect heterogeneous agents. In enterprise reality, a CRM-analysis agent is built on vendor A's framework (LangGraph), a scheduling agent on vendor B's solution, and an internal-approval agent in-house, so vendors, runtimes, and languages are all different. Making them collaborate required a dedicated adapter for each pair of agents, which reproduced the N×N point-to-point integration hell once suffered in system integration, now in the agent world.

A2A solves this by establishing a common convention for inter-agent communication. When an agent publishes a standard business card (Agent Card) describing itself, other agents read it to grasp "what it can do" and delegate work via standard messages. Its core philosophy is Opacity: a remote agent that receives delegated work does not reveal its internal reasoning, prompts, or the tools it uses, and exchanges only task status and deliverables. This enables collaboration while protecting intellectual property, forming the foundation of a Web of Agents in which agents consume each other like interchangeable "services."

A2A was released in April 2025 by Google together with some 50 partners, and in June 2025 it was donated to the Linux Foundation, moving to neutral, vendor-independent governance. Its background is clear. Just as web services were once standardized with SOAP/REST and microservices with gRPC, there is a sense of urgency that the agent ecosystem, too, will fragment into silos without an interoperability standard. A2A's characteristics are, first, reuse of existing web standards (HTTP, JSON-RPC 2.0, SSE, OpenAPI authentication schemes) to lower adoption barriers; second, designing enterprise-grade security and authentication as first-class elements; third, native support for long-running and asynchronous tasks (tasks taking several days can still be tracked); and fourth, modality neutrality spanning text, image, audio, and structured data.

2. Overall Structure and Core Concepts of A2A

A2A operates through the interaction between a Client Agent that requests work and a Remote Agent (A2A Server) that performs the request. A single agent can be a client in one situation and a server in another. The overall flow has a lifecycle of "① discovery → ② negotiation → ③ task execution and tracking → ④ result receipt."

graph TB
    subgraph User["User / Orchestrator"]
        O["Client Agent<br/>(Client Agent)"]
    end
    subgraph RemoteA["Remote Agent A (A2A Server)"]
        CardA["Agent Card<br/>(.well-known published)"]
        LogicA["Internal reasoning/tools<br/>(opaque/private)"]
    end
    subgraph RemoteB["Remote Agent B (A2A Server)"]
        CardB["Agent Card"]
        LogicB["Internal logic"]
    end
    O -->|"1.Discovery: fetch Agent Card"| CardA
    O -->|"2.Delegation: create Task"| LogicA
    LogicA -->|"3.Status/result: Task/Artifact"| O
    O -.->|"parallel delegation"| CardB
    O -.-> LogicB
    LogicA -->|"sub-delegation"| CardB

A. Agent Card — The Agent Card is a JSON-format metadata document published by an A2A server, typically posted at the /.well-known/agent-card.json path. It contains capability information such as the agent's name, version, and description; service endpoint URL; list of available skills; supported input/output modalities; required authentication methods (OAuth 2.0, API Key, etc.); and whether streaming and push are supported.

The skills declared in the card are items that structure an agent's performable capabilities together with a natural-language description, and they serve as the basis on which a client (or an orchestrator LLM) performs semantic routing of "which agent to send this request to." In other words, the Agent Card is both a machine-readable API specification and a semantic directory that helps an LLM reason about and choose a suitable collaborator.

The essence of the Agent Card is that it is not a mere introduction but the starting point of interoperability. Just as a person decides whether to enter a restaurant by looking at its sign and menu, a client agent reads the card to judge dynamically at runtime "whether this agent can handle my task and what authentication it requires." This moves into the agent world the role once played by service directories (UDDI) and OpenAPI specifications, enabling loose coupling and dynamic discovery without pre-hardcoded integration. For instance, if a travel-booking orchestrator merely registers the card of a new airline agent, it can admit that agent as a collaboration candidate without any code change.

B. Task — A Task is the basic unit of work that A2A tracks; it has a unique ID and follows an explicit state machine such as submitted → working → input-required → completed/failed/canceled. A single Task retains its lifetime across multiple message exchanges, so everything from a lookup that finishes in seconds to a review/approval that takes several days can be handled with the same model.

Elevating the Task to a stateful first-class object was a core design decision of A2A. This is because, whereas a traditional REST call ends with request-response, agent collaboration is inherently long-running and asynchronous. A delegation of "analyze a competitor's financial statements and write a report" may take several hours, and may require additional information (input-required) partway through or need to report progress. The Task state machine standardizes such suspension, resumption, and tracking, letting the client receive status changes via SSE (Server-Sent Events) streaming or Push Notification instead of polling.

C. Message and Part — A Message is an individual turn exchanged between a client and an agent, and its content is carried in units of Parts. Parts are divided into TextPart (text), FilePart (files/binary), and DataPart (structured data such as JSON), so a single message can deliver a mixture of multiple modalities.

A Message also has a role distinction that separates user utterances from agent responses, and multiple Parts can be bundled into one message to deliver "explanatory text + attached file + structured parameters" at once. This is similar to a person sending an email with both a body and attachments.

The Part abstraction matters because it enables modality negotiation. Since some agents handle only text while others handle image and audio, the sender composes Parts to match the supported modalities declared in the receiving agent's Agent Card. This is a design that negotiates on a capability basis rather than hardcoding content formats, securing flexibility for collaboration among multimodal agents.

D. Artifact — An Artifact is the final deliverable produced by a Task (a report file, a generated image, structured data, etc.), managed separately from conversational messages. That is, by distinguishing the "in-progress conversation" (Message) from the "finalized result" (Artifact), the client clearly collects only the deliverables irrespective of intermediate chatter.

This separation has large practical implications for idempotency and reuse. The Artifacts of the same Task can be referenced, cached, and version-managed by identifier, making it easy to audit collaboration results or re-feed them as input to a subsequent agent. For example, if an analysis-report Artifact produced by a "market-research agent" is passed directly as input to a "slide-generation agent," only the finalized deliverable is delivered without re-parsing the intermediate conversation log, so the coupling of the agent pipeline is reduced. This is like applying data engineering's "immutable dataset" pattern to agent collaboration.

A2A's core objects are summarized in the table below. However, the table is merely a summary; why each object is separated is the essence explained in the paragraphs above.

Concept Role Characteristics Analogy
Agent Card Publishes agent capability/endpoint/auth Dynamic discovery, .well-known posting Business card/menu
Task Work-tracking unit (state machine) Long-running/async, suspend/resume Work order
Message/Part Individual turn and multimodal content Mix of text/file/data One conversational turn
Artifact Final deliverable Separated from messages, reusable Finished product/delivery

3. Communication Procedure and Transport Layer

A typical A2A collaboration follows the sequence below. In particular, the fact that discovery and delegation occur dynamically at runtime is the decisive difference from pre-wired integration.

sequenceDiagram
    participant C as Client Agent
    participant S as Remote Agent(A2A Server)
    C->>S: 1. GET /.well-known/agent-card.json (discovery)
    S-->>C: Agent Card (skills/auth/endpoint)
    C->>S: 2. Authentication (OAuth2/API Key)
    C->>S: 3. message/send (create Task, delegate work)
    S-->>C: Task(status=working, id)
    loop streaming progress
        S-->>C: 4. SSE: status-update (progress/partial result)
    end
    S-->>C: 5. input-required (request for more info)
    C->>S: 6. message/send (additional input)
    S-->>C: 7. Task(status=completed) + Artifact

A. Discovery — The client queries the Agent Card at a known URL or registry to grasp the counterpart's capabilities and authentication requirements. If the capabilities do not match, it looks for another agent. That discovery happens at runtime is decisive for scalability: when adding a new agent, one only registers its card without modifying the existing agents' code, so the O(N²) integration burden is reduced to O(N). In large organizations, it is a common pattern to maintain an internal agent catalog (registry) to centrally manage cards and apply access policies.

B. Authentication/Authorization — A2A does not invent its own authentication but reuses the standard authentication schemes used by OpenAPI (OAuth 2.0, OpenID Connect, API Key, mTLS, etc.). The fact that it layers naturally onto an enterprise's existing IAM/gateway infrastructure is a core incentive for enterprise adoption. Thanks to this design that does not reinvent the wheel, security teams can reuse their already-validated token issuance/verification systems as-is while issuing scoped tokens narrowed to agent collaboration alone.

C. Task Delegation and Tracking — The client creates a Task via message/send (or message/stream for streaming). Short tasks are returned as a synchronous response, long tasks report progress via SSE streaming, and ultra-long tasks—where the client may be offline—are notified of completion via Push Notification (webhook).

At the transport layer, the A2A v1.0 specification defines the data model normatively in Protocol Buffers and provides three bindings (JSON-RPC 2.0, gRPC, HTTP+JSON/REST). This is a transport-flexibility design that lets you choose gRPC for performance-critical internal networks and JSON-RPC/REST for general interoperability. Taking Protocol Buffers as the single source of truth, agents implemented in different languages use code generated from the same schema, so integration errors due to field mismatches are structurally reduced.

In a real application case, Google released A2A at its announcement together with some 50 companies such as Salesforce, SAP, ServiceNow, and PayPal, presenting collaboration scenarios among enterprise business agents (e.g., in a hiring process, a candidate-screening agent delegates work to scheduling and background-check agents). In this way, A2A aims to be the connective tissue of enterprise business automation rather than a specific model.

4. The Relationship Between A2A and MCP — Complementary, Not Competing

The most common misunderstanding in understanding A2A is framing it as a competitor to MCP (Model Context Protocol). In reality, the two are complements that standardize different layers. If MCP standardizes "how a single agent connects to its own tools and data" (vertical, agent-to-tool), then A2A standardizes "how different agents collaborate" (horizontal, agent-to-agent). As the industry's shorthand goes, "MCP for tools, A2A for agents."

graph TB
    subgraph AgentX["Agent X"]
        LX["Reasoning core"]
        LX -->|"MCP"| T1["Tool/DB/API"]
    end
    subgraph AgentY["Agent Y"]
        LY["Reasoning core"]
        LY -->|"MCP"| T2["Tool/File"]
    end
    LX <-->|"A2A (collaboration/delegation)"| LY

Their transparency models also contrast. Whereas an MCP tool call lets the caller see arguments and results transparently, A2A hides the remote agent's internals opaquely. This is a deliberate design to protect the collaborating counterpart's intellectual property and security boundary. Real production architectures use the two standards together. For example, one organization's "travel-expense settlement agent" connects via MCP to its own receipt-OCR tool and accounting DB, and at the same time delegates collaboration via A2A to external "flight-lookup agents" and "exchange-rate agents." The comparison below is organized around the fundamental reasons the differences arise.

Category A2A MCP
Standardization target Agent↔agent collaboration (horizontal) Agent↔tool/data connection (vertical)
Core objects Agent Card, Task, Artifact Tool, Resource, Prompt
Transparency Opaque (internals hidden) Transparent (arguments/results exposed)
Interaction Dynamic discovery, long tasks, delegation In-session tool calls
Leadership/governance Google→Linux Foundation Anthropic→open

5. Deep Dive — Standardization Trends and Security Challenges

A2A rapidly broadened its ecosystem within a year of release. In June 2025 it secured neutral governance through donation to the Linux Foundation, and in August 2025 IBM's ACP (Agent Communication Protocol) was merged into A2A, converging competing standards. In December 2025 the Linux Foundation launched the AAIF (Agentic AI Foundation) to gather agent standards, and A2A joined it as a hosted project. After v0.3.0 (mid-2025), the v1.0 stable specification was released around 2026, finalizing a Protocol Buffers–based data model and three bindings. However, the exact v1.0 announcement date differs across sources, so the precise version and date need to be confirmed against the official specification (a2a-protocol.org).

On the security side, it is being actively researched that A2A opens a new attack surface. First, there is the Agent Card trust problem: if a card's capabilities or identity are forged, a malicious agent can impersonate a legitimate collaborator, so signing/verification and a registry trust framework are required. Second, there is the confused deputy risk in which privileges propagate excessively along the delegation chain, so least-privilege and scoped tokens must be applied at each delegation step. Third, opacity itself is a double-edged sword, making it hard to monitor a malicious agent's behavior from the outside. Academic security analyses of A2A (such as A2ABreak) point to authentication/authorization bypass, task hijacking, and prompt-injection propagation as systematic threats. Therefore, in practical application, zero-trust principles, per-agent identity (SPIFFE-style workload identity), and end-to-end audit logging must be applied in parallel.

6. Considerations and Implications

From a professional-engineer perspective, adopting A2A is not a mere technology choice but a strategic task spanning agent architecture, governance, and security, and the following must be considered together.

  • Application strategy (phased adoption): Rather than erecting an enterprise-wide multi-agent system all at once, a realistic two-stage approach is to first standardize the tool layer with MCP internally, then apply A2A selectively only to collaboration that crosses organizational/vendor boundaries. An Agent Card registry and a card-signing framework should be set as prerequisites of governance.
  • Trade-off (opacity vs. observability): A2A's opacity gives IP protection and loose coupling, but makes debugging, auditing, and accountability tracking difficult. Observability must be supplemented with Task-ID-based distributed tracing (integrated with OpenTelemetry) and Artifact version management.
  • Security/regulation (locus of responsibility): The legal/contractual attribution of responsibility for a result arising when an autonomous agent delegates to an external agent is ambiguous. Limit the delegation scope with tokens/policies, and in regulated industries such as finance and healthcare, explicitly design human-in-the-loop checkpoints into the Task state machine.
  • Standard-maturity risk: A2A is still evolving rapidly (version changes, governance handover), so do not tightly couple to a specific version; place an adapter layer premised on version negotiation/backward compatibility to absorb migration costs.
  • Related technologies/outlook: A2A's value is maximized when combined with MCP (tools), orchestration frameworks such as LangGraph and AutoGen, and zero-trust/IAM. In the long run, it is expected to settle as the underlying protocol of an Agent Economy and Web of Agents in which agents are traded and discovered like services, and enterprises must proactively prepare a governance framework for agent identity, cards, and delegation policy from now on.

References

In one line: A2A is an open interoperability protocol that lets heterogeneous AI agents delegate and collaborate on work while hiding their internals, through Agent-Card-based dynamic discovery and a common Task·Message·Artifact model; it complements MCP as in "MCP for tools, A2A for agents," and successful adoption hinges on security/governance design such as card trust, delegation privileges, and observability.