A2A Protocol in Agentic AI: How AI Agents Discover, Delegate, and Collaborate

Nagesh Singh Chauhan

55 minutes ago

15 min read

The next evolution of AI is not simply about building a more capable agent. It is about building systems in which multiple specialized agents can collaborate across frameworks, applications, and organizational boundaries.

Introduction

Imagine a procurement agent that needs to evaluate a supplier. It delegates financial analysis to a finance agent, compliance verification to a legal agent, and delivery-risk assessment to a supply-chain agent. Each agent may use a different LLM, framework, database, and internal workflow.

How do they communicate? How does one agent discover another agent's capabilities?

How does it delegate a long-running task, receive intermediate updates, and obtain a structured result without accessing the other agent's internal implementation?

This is the problem addressed by the Agent2Agent (A2A) protocol.

The central idea is simple: agents should be able to collaborate through a standardized communication protocol instead of requiring every agent pair to implement a custom integration.

This article examines A2A from a systems-engineering perspective: its architecture, communication model, protocol objects, task lifecycle, relationship with MCP, practical implementation patterns, limitations, and security requirements.

Why do we need A2A?

The problem with isolated agents

An AI agent typically combines a model, instructions, context, tools, memory, and an execution loop. A team might build a research agent using one framework, a finance agent using another, and a compliance agent as a proprietary enterprise service.

Individually, these agents can be effective. The challenge emerges when they must work together.

Without a shared protocol, developers often have to build custom integrations for:

Discovering available agents and understanding their capabilities.
Translating requests into each agent's proprietary input format.
Passing intermediate results and contextual information.
Tracking tasks that take minutes or hours to complete.
Handling clarification requests, failures, cancellation, and retries.
Authenticating callers and controlling access to delegated operations.

The integration burden grows as the number of systems increases.

The integration-complexity intuition

Suppose every agent needs a custom integration with every other agent.

For n agents, a fully connected network has:

where E is the number of unique pairwise connections.

Pairwise integration growth

The number of possible unique pairwise connections grows quadratically as agents are added.

This is an illustration of potential integration relationships, not a measured performance benchmark. Real architectures may use hubs, registries, shared gateways, or other topologies to reduce the number of direct connections.

A2A helps by standardizing the communication contract between participating agents. Instead of implementing a new wire protocol for each pair, a developer can reuse a compatible A2A client and server implementation.

It does not eliminate all integration work: authentication policies, business semantics, data contracts, trust, and orchestration still need to be designed.

What exactly is the A2A protocol?

A2A is an open protocol for communication and collaboration between independent AI agent applications. It defines a shared interaction model so an agent can request work from another agent without requiring access to that agent's internal prompts, memory, tools, model, or execution logic.

Think of A2A as a communication contract between autonomous services.

A remote agent can be implemented using a different:

LLM or model provider.
Agent framework, such as LangGraph, CrewAI, Semantic Kernel, or a custom runtime.
Programming language.
Memory architecture and internal toolset.
Deployment model or organizational infrastructure.

If both sides implement compatible A2A interfaces, they can exchange requests, task updates, and results through a common protocol.

A2A is not an agent framework

This distinction matters.

Technology layer	Responsibility
LLM	Generates predictions, reasoning steps, or responses
Agent runtime	Executes the agent's internal control loop
Agent framework	Provides abstractions for state, tools, planning, and orchestration
MCP	Standardizes access to tools, resources, and prompts
A2A	Standardizes communication and task collaboration between agents
Infrastructure	Provides networking, identity, deployment, storage, and observability

A2A does not tell an agent how to reason, which model to use, or which planning algorithm to follow. It standardizes how compatible agent systems interact.

A2A architecture: how the components fit together

Consider an enterprise AI application with a central orchestrator and four specialist agents.

This architecture separates two concerns:

Coordination: Which agent should perform which task, in what order, and how should the outputs be combined?
Communication: How should an agent discover another agent, submit a request, track progress, and retrieve results?

A2A addresses the second concern. The orchestration strategy can be implemented by an agent framework, a workflow engine, custom application code, or a combination of these.

The main protocol participants

A2A client: Sends requests to a remote agent. An agent can act as a client when delegating work.
A2A server: Exposes an agent through an A2A-compatible interface and manages the requested task.
Agent Card: Describes the agent's identity, supported interfaces, capabilities, skills, and authentication requirements.
Message: Carries a communication turn and its content.
Task: Represents a unit of work whose status can evolve over time.
Artifact: Represents output produced by an agent, such as a report, file, or structured result.

These concepts form the core of A2A's interoperability model.

Agent discovery: how does one agent find another?

Before delegating work, an agent needs to know which remote agents exist and what they can do. A2A supports capability discovery through an Agent Card, a machine-readable description of a remote agent.

A common discovery location is:

https://agent.example.com/.well-known/agent-card.json

Use the exact endpoint documented by the target deployment. Agent Card URL conventions and interface details can vary across protocol versions and deployments.

An Agent Card can describe information such as:

Agent name and description.
Supported skills and their identifiers.
Service endpoint and supported protocol interfaces.
Input/output modalities.
Streaming or notification capabilities.
Authentication schemes and security requirements.

The important idea is that the caller can inspect a published capability contract before making a request. Discovery does not itself guarantee that an agent is trustworthy, available, or authorized to perform a particular operation.

Example: a simplified Agent Card

The following is an illustrative metadata example, not a complete, version-validated Agent Card:

{
  "name": "Supplier Risk Agent",
  "description": "Evaluates supplier financial and operational risk",
  "supportedInterfaces": [
    {
      "url": "https://risk.example.com/a2a",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "capabilities": {
    "streaming": true
  },
  "skills": [
    {
      "id": "supplier-risk-assessment",
      "name": "Supplier Risk Assessment",
      "description": "Produces a supplier risk report"
    }
  ]
}

The exact schema, required fields, interface bindings, and version identifiers must match the version of the official specification and SDK being used. Do not copy this illustrative object directly into production.

Discovery workflow

In a small deployment, Agent Cards can be configured directly. In a larger enterprise, a registry or service catalog can help discover agents dynamically.

A production discovery layer should also consider endpoint allowlists, card authenticity, caching, version compatibility, availability, and trust policies.

The A2A communication model

A2A is more than a standardized way to send a text prompt to another LLM. Its interaction model supports immediate exchanges as well as stateful, long-running work.

Three concepts are particularly important: messages, tasks, and artifacts.

These are distinct concepts. A message is not necessarily a task, and a task does not have to produce a downloadable file. A task may return a textual or structured result, while some interactions can be handled as stateless messages.

How they work together

Suppose a finance agent is asked to evaluate a supplier.

The orchestrator sends a message describing the requested assessment.
The finance agent determines whether it can answer immediately or needs to create a task.
If it creates a task, the task has an identifier and a status.
The agent may use its own tools, retrieve records, and perform calculations.
It returns a result, potentially as one or more artifacts.
The orchestrator consumes the result and decides what to do next.

The orchestrator does not need to know how the finance agent calculated its internal risk score. It needs an agreed interface, sufficient input context, and a well-defined output contract.

The task lifecycle: from request to completion

Long-running work is one of A2A's most important capabilities.

A simple request-response API is often sufficient for a calculator or a database lookup. It becomes less convenient when a remote agent needs to inspect thousands of records, request human approval, or run a complex analysis that takes several minutes.

A2A provides a task model for tracking such interactions.

Task state machine

The exact state names and permitted transitions should be taken from the selected protocol version. In A2A 1.0, task outcomes include terminal states such as completed, failed, canceled, and rejected, as well as interrupted states such as input-required and auth-required.

How does the client receive updates?

There are several communication patterns, with support depending on the agent's declared capabilities and implementation.

Pattern	How it works	Suitable for
Immediate response	The agent returns a message or task response directly	Short, bounded operations
Streaming	The client receives incremental events while the task runs	Live progress, incremental outputs
Polling	The client periodically queries the task's status	Simpler asynchronous integrations
Push notifications	The agent notifies a configured endpoint about relevant task updates	Long-running tasks when the client may not be connected

The key architectural decision is not simply which transport is fastest. It is how the application should behave when an agent is busy, disconnected, awaiting human input, or temporarily unavailable.

Example: an asynchronous supplier assessment

This is a conceptual sequence diagram. Exact message methods, payloads, and status-event structures depend on the selected A2A version.

Context, task IDs, and continuity

Three identifiers or concepts must not be confused:

Task ID: Identifies a particular unit of work.
Context ID: Groups related interactions so an agent can maintain continuity across tasks and messages.
Message ID: Identifies a particular communication message.

A context can contain several tasks. For example, a supplier assessment might begin with a risk report, then create a separate follow-up task to explain a particular finding.

This separation helps with traceability, follow-up interactions, and parallel execution. In A2A 1.0, a terminal task does not simply restart; a refinement is represented as a new task within the relevant context.

What actually travels over the wire?

A2A's application-level model is expressed through structured protocol objects and request/response operations.

For a developer, the important question is: what does the transport layer carry, and what must the receiving agent understand?

At a conceptual level, an A2A interaction includes:

A request that identifies an operation and its parameters.
A message with a role and content parts.
Optional context or task references for continuity.
A response containing either a message or task information.
Status updates and result artifacts when supported by the interaction.

In the A2A 1.0 documentation, core operations use named methods such as SendMessage, SendStreamingMessage, GetTask, and CancelTask. Earlier versions used different method names, so these should not be mixed across SDK versions.

Example: a conceptual task request

The following JSON illustrates the shape of a request, not a copy-paste-ready request for a particular SDK or server.

{
  "jsonrpc": "2.0",
  "id": "request-104",
  "method": "SendMessage",
  "params": {
    "message": {
      "messageId": "message-104",
      "role": "user",
      "parts": [
        {
          "text": "Assess the financial risk of supplier SUP-204."
        }
      ]
    }
  }
}

A production client must use the exact request envelope, field names, message structure, interface binding, and authentication requirements defined by its target A2A version.

Why structured data matters

Suppose an agent returns:

The supplier is medium risk.

That is easy for a person to read but may not be sufficient for a downstream procurement workflow.

A more useful result contract might contain:

{
  "supplier_id": "SUP-204",
  "risk_level": "medium",
  "risk_score": 62,
  "currency": "INR",
  "findings": [
    "Declining operating margin",
    "Elevated receivables"
  ],
  "assessment_timestamp": "2026-10-22T12:00:00Z"
}

This is an illustrative business payload, not a mandatory A2A schema.

The distinction is important: A2A transports the interaction; your application defines the business meaning of the result. If downstream systems need reliable decisions, agree on schemas, validation rules, provenance, timestamps, and confidence semantics rather than relying on free-form prose alone.

A2A versus MCP: the most important distinction in agentic AI

One of the most common misconceptions is that A2A and MCP compete to solve the same problem.

They operate at different boundaries.

MCP connects an agent to capabilities. A2A connects an agent to another agent.

The official A2A documentation explicitly describes these protocols as complementary. An agent can delegate a task over A2A and use MCP internally to access databases, APIs, and other tools needed to complete it.

Technical comparison

Dimension	A2A	MCP
Primary purpose	Inter-agent communication	Agent-to-tool and resource integration
Remote participant	Another agent application	A tool/resource server
Core abstraction	Messages, tasks, results, contexts	Tools, resources, prompts
Typical operation	Delegate a risk assessment	Query a database or call an API
Long-running work	Explicit task lifecycle	Tool-call lifecycle and protocol-supported progress mechanisms
Discovery	Agent Cards and other discovery mechanisms	Server capability and primitive discovery
Internal reasoning access	Not required	Not the protocol's purpose
Best fit	Collaboration across independent agents	Access to external capabilities

A realistic combined workflow

Consider a legal agent reviewing a supplier contract.

The procurement agent delegates the contract review to a legal agent using A2A.
The legal agent receives the request and establishes a task if stateful work is needed.
The legal agent uses MCP to retrieve approved contract templates and relevant policy documents.
It uses internal reasoning and validation logic to assess the contract.
It returns findings and, if applicable, a structured report to the procurement agent through A2A.
The procurement agent combines the legal findings with results from other specialist agents.

The legal agent remains an independent system. It does not need to expose its internal tool implementations to the procurement agent.

That is the architectural advantage: the two protocols solve different interoperability problems and can be used together.

A2A versus direct API calls and function calling

A2A is also not a universal replacement for REST APIs, RPC, or LLM function calling.

Approach	Best suited to	Trade-off
Direct API / REST	Predictable operations with explicit business contracts	Each integration must define its own application semantics
LLM function calling	Selecting and invoking available functions within an application	A function call alone does not define a cross-agent collaboration lifecycle
A2A	Communicating with independent agents and tracking delegated work	Requires compatible protocol implementations and operational governance
Workflow engine	Durable orchestration, dependencies, retries, and business process control	Does not by itself establish a universal agent-to-agent protocol

A2A can itself be implemented over familiar web infrastructure. The value is not that HTTP or JSON is new. The value is the standardized agent-oriented interaction model built on top of the transport.

An agent should not be introduced simply because a task exists. If a deterministic API can reliably perform the operation, a direct API call may be simpler, cheaper, and easier to test.

A practical enterprise use case: supplier risk assessment

Let's design a more complete A2A workflow.

A procurement team wants to onboard a new supplier. The system must check financial stability, legal compliance, operational reliability, and internal procurement policy.

High-level orchestration

This diagram shows a proposed application architecture. A2A supports the communication and task-tracking interactions; the orchestration engine implements the dependency logic, policy evaluation, and approval process.

How should the tasks be coordinated?

The orchestrator can launch independent assessments concurrently.

For independent tasks, a simplified latency model is:

By contrast, sequential execution is approximately:

These equations assume the tasks can genuinely execute independently. Shared dependencies, concurrency limits, retries, queueing, and human approvals can change the outcome.

What should the orchestrator do if one agent fails?

The system needs an explicit failure policy.

Finance agent times out: Check task status and retry only when appropriate.
Legal agent requires clarification: Request the missing contract or business information.
Logistics agent is unavailable: Use a defined fallback, defer the decision, or escalate.
Agents return contradictory findings: Preserve the evidence and invoke a reconciliation or human-review step.
One task fails after the others finish: Reuse valid completed results where safe instead of automatically repeating all work.

A2A provides communication and task-management primitives, but it does not automatically make a distributed workflow transactional or guarantee exactly-once execution. Those properties must be designed into the application.

How to implement A2A in a real system

A practical implementation should start with a small, well-defined remote agent rather than immediately building a large multi-agent network.

Step 1: Define a meaningful agent boundary

Choose a capability with a clear input, output, and owner.

For example:

Input: Supplier identifier, assessment scope, and permitted data.
Output: Risk classification, evidence, findings, and report.
Owner: Finance risk service.
Execution model: Short synchronous response or long-running task.
Authorization: Only approved procurement systems may request assessments.

An agent boundary is useful when the capability is independently deployable, has clear ownership, or requires specialized logic and access controls.

Step 2: Publish an Agent Card

Describe the agent's supported skills, endpoint, protocol interface, and authentication requirements. Ensure the card is version-compatible with the implementation and does not expose secrets or sensitive internal details.

Step 3: Implement the server and task executor

The A2A server is the protocol-facing component. The task executor connects incoming requests to the agent's internal runtime.

A typical architecture is:

Using an official SDK is generally preferable to manually implementing protocol serialization, task states, and event handling.

The official project publishes SDKs and examples for several languages, including Python, JavaScript, Java, C#/.NET, and Go.

Step 4: Implement the client

The calling agent needs to:

Discover or load the remote agent's metadata.
Validate its supported interface and capabilities.
Authenticate to the remote service.
Submit a correctly structured message.
Process the response and track any resulting task.
Handle streaming, polling, or notifications if supported.
Validate the returned result before using it in downstream decisions.

Step 5: Add operational controls

Before production, establish policies for:

Request timeouts and task deadlines.
Bounded retries and backoff.
Concurrency and rate limits.
Task cancellation and cleanup.
Duplicate requests and idempotency.
Result validation and provenance.
Tracing across delegated agents.
Version compatibility and contract testing.

Implementation checklist

Security: the part that determines whether A2A is enterprise-ready

Standardized communication does not automatically make an agent network secure.

An A2A server may have access to sensitive financial data, legal documents, employee records, procurement systems, or APIs that can execute real-world actions. A compromised or malicious agent can therefore create risks beyond an ordinary text-generation error.

The A2A specification addresses protocol-level concerns such as authentication, Agent Card security, and secure communication. The application still needs its own authorization, governance, and execution controls.

The security layers

Threats worth testing

Threat	Example	Mitigation
Malicious agent	A remote agent returns fabricated financial findings	Validate results against trusted evidence and apply independent policy checks
Prompt injection	A document instructs the agent to disclose unrelated sensitive data	Treat retrieved content as untrusted; enforce policy outside the model
Credential leakage	An agent forwards an access token to another agent	Use scoped credentials, secure secret storage, and explicit delegation rules
SSRF or endpoint abuse	A discovered Agent Card points to an internal administrative endpoint	Validate destinations, restrict egress, and enforce network controls
Replay or duplicate execution	A retry submits a payment instruction twice	Use idempotency controls, deduplication, and business-level transaction safeguards
Excessive delegation	An agent repeatedly delegates tasks without a useful stopping condition	Limit depth, fan-out, time, token consumption, and total cost

An important design principle is that trust must not be transitive by default. If agent A trusts agent B, that does not mean B should be allowed to invoke every capability of agent C using A's privileges.

Likewise, a completed A2A task is not equivalent to an approved business transaction. High-impact operations should require explicit policy checks and human approval where appropriate.

Performance and economics: when does A2A make sense?

A2A introduces network calls, serialization, authentication, remote execution, and potentially additional LLM inference. These costs need to be considered alongside the benefits of modularity and parallel execution.

A rough model for the cost of a delegated task is:

For a workflow with several agents, total cost also depends on retries, duplicated context, repeated reasoning, and the cost of reconciling conflicting outputs.

What to measure

Metric	Why it matters
End-to-end latency	Measures the actual user experience
Time to first update	Indicates responsiveness for long-running work
Task success rate	Measures whether delegated work reaches a valid outcome
Retry and failure rate	Reveals unreliable dependencies and poor error handling
Cost per successful workflow	Includes inference, tools, networking, and retries
Output validity	Measures conformance to expected schemas and business constraints
Human escalation rate	Indicates how often automation needs intervention
Unauthorized-action rate	Measures an essential safety and governance outcome

Do not measure success by counting agents or A2A calls. Measure whether the multi-agent design improves task completion, reliability, quality, or operating cost against a simpler baseline.

When should you use A2A?

A2A is an interoperability mechanism, not a reason to turn every function into an agent.

Limitations and open engineering challenges

A2A standardizes the communication boundary, but several difficult problems remain application responsibilities.

Semantic interoperability. Two agents may support the same protocol yet interpret "high risk" differently. Shared schemas, taxonomies, units, and domain definitions are still necessary.

Orchestration. A2A does not decide which agents to call, how to resolve dependencies, or how to combine conflicting results. Those decisions belong to the orchestration layer.

Distributed failure. Remote agents can fail independently. A task may time out, a result may arrive late, or one specialist may complete while another fails. Durable state, bounded retries, and recovery policies are essential.

Trust and accountability. A technically valid response may still be inaccurate, malicious, stale, or unauthorized. Identity and protocol compliance are not guarantees of correctness.

Version compatibility. Different deployments may support different A2A versions, interface bindings, or extensions. Clients and servers must explicitly manage compatibility.

Observability. A single user request may fan out into many remote tasks. Without correlation IDs, trace propagation, cost attribution, and task-level logs, debugging can become difficult.

Evaluation. Protocol conformance is not the same as agent quality. An agent can correctly implement A2A while returning poor financial analyses or invalid legal conclusions.

These are not reasons to avoid A2A. They are reasons to treat it as one component of a broader distributed-agent architecture.

What does a mature A2A ecosystem look like?

A mature architecture is likely to have more than a collection of agent endpoints. It will need a control plane and a runtime layer.

In this architecture, A2A is the communication contract between compatible agents. The registry, policy engine, orchestrator, and shared platform services are architectural components around it—not features that A2A alone automatically provides.

This separation enables organizations to evolve agents independently while retaining centralized control over access, operational reliability, and business outcomes.

The future of agentic AI: from isolated agents to interoperable systems

The significance of A2A goes beyond enabling two agents to exchange messages.

It creates a foundation for a world where an organization can expose specialized agent capabilities through a common interface, discover those capabilities, delegate work across system boundaries, and track the results.

Consider what this enables:

A financial institution can connect risk, fraud, compliance, and customer-service agents.
A software engineering platform can coordinate coding, testing, security review, and deployment agents.
A procurement platform can coordinate sourcing, tender analysis, legal review, and supplier-risk agents.
A travel platform can coordinate flight, hotel, itinerary, and booking agents.

The agents do not have to share the same framework or internal implementation. They need compatible protocol interfaces, agreed data semantics, and appropriate trust and authorization policies.

But there is an important distinction: interoperability does not automatically create intelligence. Better outcomes still depend on agent quality, task decomposition, evaluation, and reliable orchestration.

A2A makes collaboration easier to standardize. It does not eliminate the engineering required to make that collaboration useful.

Conclusion

The most useful way to understand A2A is to place it within the larger architecture of agentic AI.

LLMs provide model capabilities.
Agent runtimes execute individual agents.
MCP standardizes access to tools and resources.
A2A standardizes communication and collaboration between independent agents.
Orchestration and governance layers coordinate work, enforce business policies, and manage failures.

Together, these components make it possible to move from isolated AI assistants to distributed systems of specialized agents.

The long-term opportunity is not simply to build more agents. It is to make agents interoperable, composable, observable, secure, and dependable enough to participate in real business workflows.

That is where A2A becomes strategically important.