Enterprise automation has traditionally been built around workflows.

A process engine calls an API, moves data between systems, waits for an approval and continues along a path that developers designed in advance.

AI agents introduce a different operating model.

A support agent may understand a customer problem but require another agent to investigate an invoice. A procurement agent may need a compliance agent to evaluate supplier documents. An operations agent may need a security agent to approve a remediation plan before an execution agent changes production infrastructure.

These agents may be:

Developed by different teams
Written in different programming languages
Built with different agent frameworks
Hosted by different cloud providers
Operated by different companies
Connected to different tools and data sources

Without a shared protocol, every relationship requires custom integration.

One agent needs to understand another agent’s proprietary endpoint, authentication method, task format, status model, output structure and error behaviour. As the number of agents increases, point-to-point connections become another form of integration sprawl.

The Agent2Agent Protocol, commonly called A2A, addresses this problem.

A2A provides an open interaction model through which independent agents can:

Advertise their capabilities
Discover other agents
Exchange messages
Delegate tasks
Report task status
Request additional input or authorisation
Stream incremental results
Return structured outputs
Coordinate long-running work

A2A does not turn every agent into one shared intelligence.

It creates a standard boundary through which agents can collaborate while keeping their internal models, memory, tools and proprietary logic private.

Multiple enterprise AI agents collaborating through a secure A2A orchestration hub connected to business systems. — A2A gives independently developed agents a common communication and task-coordination layer without requiring them to expose their internal implementation.

Quick answer: What does A2A mean for enterprise automation?

A2A is an open protocol for communication and collaboration between independent AI agents.

It allows one agent to discover another agent’s capabilities, send it a message or task, follow the task’s progress and receive structured results—even when the agents use different models, frameworks, languages or infrastructure.

A practical A2A interaction looks like this:

A client agent discovers a remote agent through its Agent Card.
The client checks the remote agent’s skills, supported interfaces and authentication requirements.
The client sends a message describing the requested work.
The remote agent accepts, rejects or requests more information.
A task is created for work that requires state or multiple steps.
The remote agent reports progress through task-status updates.
It may request user input, credentials or approval.
It returns one or more artifacts as the task output.
The client agent uses the result or delegates the next part of the workflow.

The core distinction is:

MCP helps an agent use tools and data. A2A helps independent agents work with other agents.

Key takeaways

A2A standardises agent communication, not internal agent reasoning.
Agents can remain opaque: they do not have to expose their model, private memory, prompts, tools or proprietary implementation.
An Agent Card acts as a machine-readable business card describing an agent’s identity, endpoint, skills, interfaces and security requirements.
The A2A Task is the primary unit for stateful or long-running work.
Messages are used for communication, clarification and instructions; task outputs should normally be returned as Artifacts.
A2A supports synchronous responses, streaming updates and asynchronous push notifications.
A2A and MCP are complementary. An A2A remote agent may internally use MCP to reach APIs, files, databases and other tools.
Authentication uses existing enterprise mechanisms such as OAuth 2.0, OpenID Connect, bearer tokens, API keys and mutual TLS.
A2A does not automatically establish that a remote agent is trustworthy, competent or authorised for a particular business decision.
Every agent must independently enforce permissions before accessing data or performing an action.
Inter-agent communication increases the risk of privilege propagation, prompt injection, memory contamination and cascading failure.
Human approval remains essential for financial, destructive, external, legally significant or production-impacting actions.
The strongest first use cases involve a coordinator agent delegating bounded tasks to a small number of specialised agents.
A deterministic workflow remains better when the process is predictable and every branch must be tightly controlled.

What is an Agent-to-Agent system?

An Agent-to-Agent system is a distributed software architecture in which two or more autonomous or semi-autonomous agents communicate, delegate work and coordinate outcomes.

Each agent may have its own:

Model
Instructions
Memory
Domain knowledge
Tools
Permissions
Policies
Execution environment
Operator
Lifecycle

For example, an enterprise may have:

A customer-support agent
A billing agent
A fraud agent
A compliance agent
A scheduling agent
A document-analysis agent

A customer-support agent should not need to reproduce every capability itself.

It may ask the billing agent to investigate a charge, the compliance agent to determine which disclosure rules apply and the scheduling agent to arrange a call.

The agents collaborate while preserving separate ownership and responsibilities.

A2A systems versus multi-agent systems

The terms are related but not identical.

A multi-agent system can be implemented entirely inside one application using one framework and proprietary communication.

An A2A system uses a standard protocol boundary so independently implemented agents can communicate.

Architecture	Description
Single agent	One agent reasons and uses tools
Framework-native multi-agent system	Several agents communicate inside the same framework
Proprietary remote agents	Independent agents communicate through custom APIs
A2A system	Independent agents communicate using a shared open protocol

A2A is most valuable when agents cross framework, team, cloud, vendor or organisational boundaries.

Why APIs alone are not enough

An ordinary API exposes predefined data or operations.

For example:

GET /customers/{id}
POST /refunds
GET /supplier-certificates

An agent represents a higher-level, stateful capability.

A compliance agent may:

Interpret an ambiguous request
Select several evidence sources
Ask for missing documentation
Apply jurisdiction-specific rules
Coordinate human review
Produce a structured assessment

Exposing that agent as a collection of low-level endpoints can hide the fact that it performs long-running, conversational and adaptive work.

A2A adds concepts that ordinary API designs do not consistently standardise:

Agent capability discovery
Agent skills
Multi-turn communication
Task lifecycle
Input-required states
Authorisation-required states
Incremental artifacts
Streaming progress
Agent-to-agent delegation
Negotiation of supported content types

The underlying systems still use APIs.

A2A provides the interaction model around the higher-level agent capability.

What A2A standardises

A2A focuses on the communication boundary between a client agent and a remote agent.

It standardises:

Discovery metadata
Supported agent skills
Protocol interfaces
Messages
Tasks
Task status
Output artifacts
Streaming events
Push notifications
Version negotiation
Authentication declarations
Error behaviour
Extensions

It deliberately does not require the agents to share:

Internal prompts
Chain of thought
Model weights
Private memory
Internal tools
Planning algorithms
Proprietary business logic

This opacity allows an organisation to expose the outcome-oriented capability of an agent without publishing its complete implementation.

The core roles in an A2A interaction

User

The user, system or business event initiates a goal.

Examples include:

Resolve this customer issue.
Evaluate these supplier bids.
Investigate this failed deployment.
Prepare a regulatory evidence package.
Schedule interviews for the shortlisted applicants.

A2A client

The A2A client represents the component communicating with a remote agent.

It may be:

A coordinator agent
Another specialist agent
An enterprise application
An orchestration platform
A user-facing assistant

The client discovers the remote agent, sends requests and processes task updates or results.

A2A server or remote agent

The A2A server exposes an agent through one or more protocol interfaces.

It:

Publishes its capabilities
Authenticates clients
Authorises requests
Receives messages
Creates and manages tasks
Produces artifacts
Reports progress

A2A client and server describe protocol roles. An agent can act as a client in one interaction and a server in another.

A2A enterprise architecture

A production A2A platform needs more than a collection of agents connected by arrows.

Layered enterprise architecture for A2A communication, governance, memory, tools and human oversight. — A2A provides the communication layer, while enterprise identity, policy, tools, state, approval and observability remain separate architectural responsibilities.

1. Business and experience layer

This receives:

User requests
Business events
Scheduled triggers
Workflow tasks
Application requests
Partner requests

It identifies the outcome that the system should achieve.

2. Coordinator or routing layer

The coordinator determines:

Whether another agent is needed
Which agent has the relevant capability
Which task should be delegated
Which information should be shared
Whether several agents can work in parallel
How results should be combined

The coordinator should not automatically have permission to perform everything that its specialist agents can do.

3. Specialist-agent layer

Specialist agents may cover:

Finance
Compliance
Support
Data analysis
Operations
Security
Procurement
Human resources
Software development

Each should expose a bounded domain capability rather than a vague universal service.

4. A2A communication layer

This handles:

Agent Cards
Messages
Tasks
Artifacts
Status updates
Streaming
Push notifications
Version negotiation
Protocol extensions

5. Identity, trust and policy layer

This determines:

Which agent is calling
Which organisation operates it
Which user it represents
Which skill it may invoke
Which tenant owns the task
Which data it may receive
Which actions are permitted

6. Context and state layer

This may contain:

Task state
Conversation context
Shared references
Correlation identifiers
Approved summaries
Artifacts
Workflow checkpoints

Agents should exchange the minimum context required for the delegated task.

7. Tool and enterprise-system layer

Specialist agents may use:

APIs
MCP servers
Databases
CRM
ERP
Ticketing systems
Document stores
SaaS platforms
Workflow engines
Code-execution environments

8. Oversight and operations layer

This includes:

Human approval
Audit
Observability
Evaluation
Incident response
Rate limiting
Safety controls
Cost management

How agent discovery works

Before one agent can delegate work, it must know what the remote agent offers.

A2A standardises this through the Agent Card.

What is an Agent Card?

An Agent Card is a JSON document describing an A2A server.

It may include:

Agent name
Description
Provider
Version
Supported interfaces
Service endpoint
Authentication requirements
Capabilities
Skills
Supported input modes
Supported output modes
Examples
Extensions

A client uses this information to decide whether the agent is suitable.

A simplified example may look like:

{
  "name": "Supplier Compliance Agent",
  "description": "Evaluates supplier evidence against approved policies.",
  "version": "1.0.0",
  "skills": [
    {
      "id": "supplier-assessment",
      "name": "Supplier Assessment",
      "description": "Reviews supplier compliance evidence."
    }
  ],
  "supportedInterfaces": [
    {
      "url": "https://agents.example.com/compliance",
      "protocolBinding": "HTTP+JSON"
    }
  ]
}

Discovery through a well-known URL

A public or domain-discoverable agent can expose its card at:

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

Curated registries

Enterprises may use controlled registries where agents are:

Approved
Categorised
Searchable by skill
Assigned trust levels
Bound to owners
Subject to lifecycle controls

The current A2A specification standardises the Agent Card but does not prescribe one universal registry API.

Direct configuration

Private or tightly controlled systems may configure approved Agent Card URLs directly.

This is simpler but less dynamic.

Protecting sensitive capabilities

A public Agent Card should not expose:

Internal service addresses
Privileged skills
Security-sensitive workflows
Credentials
Confidential implementation details

A2A supports authenticated extended Agent Cards so additional capabilities can be disclosed only after the client is authenticated.

Agent Cards may also be digitally signed so clients can check their authenticity and integrity.

Messages, Tasks, Parts and Artifacts

These are the central A2A interaction objects.

Message

A Message is one communication unit between the client and the remote agent.

Messages can:

Start an interaction
Provide instructions
Ask for clarification
Supply additional information
Report progress
Request user input

Part

A Part contains one piece of message or artifact content.

It can represent content such as:

Text
Structured data
File references
Binary data
Media
Extension-defined content

This allows agents to exchange more than plain conversational text.

Task

A Task is the primary unit of stateful work.

It includes:

Task ID
Context ID
Current status
Artifacts
Message history
Metadata

Tasks are particularly useful when work:

Takes several steps
Requires progress updates
Needs additional input
Produces incremental results
May be paused or resumed
Requires later retrieval

Artifact

An Artifact represents an output produced by a task.

Examples include:

A report
A spreadsheet
A compliance assessment
A remediation plan
A generated document
Structured data
An image
A code patch

A2A distinguishes communication from output:

Messages coordinate the work. Artifacts contain the results.

The A2A task lifecycle

A task can move through states such as:

State	Meaning
Submitted	The task was received and acknowledged
Working	The remote agent is processing it
Input required	More information is needed
Authentication required	Credentials or human authorisation are required
Completed	The task finished successfully
Failed	The task ended with an error
Rejected	The agent declined to perform it
Canceled	The task was canceled

The interrupted states are especially important.

An agent should not invent missing information or bypass authorisation merely to continue.

It can explicitly tell the client:

I need the supplier certificate.
I need the user to authenticate.
I need a manager to approve this payment.
I cannot perform this task under the current policy.

How a complete A2A workflow operates

End-to-end A2A workflow from user request through specialist-agent collaboration, approval and execution. — A coordinator can delegate bounded work to specialised agents while policy and human approval govern consequential actions.

Step 1: A business goal is received

A user or system requests an outcome:

Investigate the delayed shipment, determine whether compensation is due and notify the customer.

Step 2: The coordinator creates a plan

The coordinator may determine that it needs:

A logistics agent
A customer-policy agent
A finance agent
A communication agent

Step 3: Relevant agents are discovered

The coordinator examines approved Agent Cards and selects agents with suitable skills and security requirements.

Step 4: The first task is delegated

The logistics agent receives:

Shipment identifier
Permitted purpose
Relevant customer context
Required output format
Deadline
Correlation ID

It should not receive unrelated customer or financial information.

Step 5: The logistics agent uses its tools

The remote agent may internally use:

Carrier APIs
ERP
Warehouse data
Tracking systems
MCP tools

It returns a structured artifact stating that the shipment was delayed by 48 hours.

Step 6: Another specialist evaluates policy

The customer-policy agent determines:

Which service commitment applied
Whether compensation is permitted
Maximum authorised amount
Whether approval is required

Step 7: Finance prepares the transaction

The finance agent prepares, but does not yet execute, a proposed account credit.

Step 8: Human approval is requested

Because the action affects customer funds, the task moves to an authorisation-required state.

A reviewer sees:

Customer
Order
Delay evidence
Policy basis
Proposed credit
Systems affected

Step 9: The approved action is executed

The finance agent applies the credit using a narrowly scoped, time-limited permission.

Step 10: Communication is generated

The communication agent drafts or sends the approved customer message according to policy.

Step 11: The outcome is audited

The system records:

Agent identities
Tasks
Artifacts
Policy decisions
Approval
Tool calls
Final business outcome

Synchronous, streaming and asynchronous interactions

Not every agent task completes immediately.

Direct response

A remote agent may return a Message directly when the request is simple and no task state is needed.

Example:

Which formats do you support?

Standard task response

The agent can acknowledge a task and return the result after processing.

Streaming

A2A supports incremental updates for tasks such as:

Generating a long report
Processing a large dataset
Investigating an incident
Creating several output artifacts
Conducting a multi-step analysis

Streaming can deliver:

Task-state changes
Progress messages
Partial artifacts
Final artifacts

Push notifications

For tasks lasting minutes, hours or days, the client does not need to keep one connection open.

A remote agent can send updates to a registered webhook.

Webhook receivers must validate the source and process duplicate notifications idempotently.

A2A versus MCP

A2A and Model Context Protocol solve different integration problems.

Area	A2A	MCP
Primary relationship	Agent to agent	Agent or model to tool/resource
Main purpose	Collaboration and delegation	Tool and context access
Capability unit	Agent skill	Tool, resource or prompt
Stateful work	Task lifecycle	Usually host-managed
Discovery	Agent Card	MCP capability discovery
Long-running work	Tasks, streaming and push	Depends on server and host
Internal implementation	Agent remains opaque	Tool interface is exposed
Example	Ask compliance agent to assess a supplier	Use database tool to retrieve supplier evidence

A common enterprise architecture uses both:

Coordinator Agent
        ↓ A2A
Compliance Agent
        ↓ MCP
Policy documents + supplier database + verification API

A2A delegates a business task to another agent.

MCP helps that specialist agent use the resources required to complete it.

A2A versus ordinary microservices

A remote agent should not be used merely to wrap a deterministic function.

Use a conventional service when:

Inputs and outputs are fully defined
Behaviour is deterministic
The operation should be fast
No interpretation is required
No multi-turn interaction is needed

Use an agent when:

Requests may be ambiguous
The process requires judgement
Several tools may be selected dynamically
Missing information may need to be requested
The workflow changes based on intermediate results
The output requires interpretation or synthesis

A2A complements service architecture; it does not replace every API.

A2A versus workflow orchestration

Workflow engines provide:

Durable state
Timers
Retries
Scheduling
Compensation
Human tasks
Deterministic transitions
Operational guarantees

A2A provides an agent communication model.

For important enterprise processes, use a workflow engine as the durable outer control plane and allow agents to operate within bounded steps.

For example:

Workflow engine
    ↓
Coordinator agent
    ↓ A2A
Specialist agents
    ↓
Approval
    ↓
Workflow engine commits next state

Do not rely on natural-language conversation history as the only record of a critical business process.

Enterprise use cases

Enterprise departments using collaborating AI agents through a governed A2A automation platform. — Specialised agents can coordinate work across departments while central governance controls permissions, messaging and auditability.

1. Customer support

A support agent can collaborate with:

Billing agent
Order agent
Product-support agent
Logistics agent
Customer-policy agent

It can investigate a complete issue without gaining unrestricted access to every underlying system.

2. Procurement

A procurement agent may delegate:

Market analysis to a research agent
Supplier validation to a compliance agent
Cost comparison to a finance agent
Contract review to a legal agent
Supply risk analysis to a logistics agent

The final supplier decision should remain governed by deterministic rules and human authority.

3. Finance operations

Agents can coordinate:

Invoice matching
Expense review
Credit assessment
Payment preparation
Exception analysis
Financial reporting

Payments, write-offs and policy exceptions should normally require approval.

4. IT operations

A coordinator agent can ask:

Monitoring agent to identify the incident
Security agent to evaluate exposure
Configuration agent to identify recent changes
Remediation agent to prepare a fix
Communication agent to update stakeholders

Production changes can pause at a human approval gate.

5. Sales and CRM

A sales agent may coordinate:

Account research
Opportunity analysis
Pricing
Product configuration
Legal review
Meeting scheduling
Proposal preparation

Each domain agent can remain owned by the team responsible for that capability.

6. Human resources and recruitment

A recruitment agent may work with:

Candidate-screening agent
Scheduling agent
Assessment agent
Compliance agent
Offer-preparation agent
Onboarding agent

Candidate rejection, employment decisions and offers should retain appropriate human oversight.

7. Compliance

A compliance agent may collect evidence from:

Policy agent
Product-data agent
Supplier agent
Document-verification agent
Audit agent

It can produce an assessment artifact without receiving unrestricted authority to approve legal compliance.

8. Supply chain

Agent collaboration can support:

Supplier disruption analysis
Inventory optimisation
Logistics planning
Quality investigation
Carbon-data collection
Product-passport preparation
Recall coordination

Why enterprises may benefit from specialised agents

Clearer domain ownership

A finance agent can be governed by finance.

A compliance agent can be governed by compliance.

The coordinator consumes their capabilities without owning their internal policy or tools.

Framework independence

Teams can select different:

Models
Languages
Frameworks
Cloud platforms
Deployment approaches

The protocol standardises the interaction boundary.

Reduced duplication

Each application does not need to recreate:

Supplier assessment
Fraud analysis
Pricing analysis
Document validation
Scheduling

Those abilities can be exposed as reusable agent services.

Independent evolution

A specialist agent can improve its model, instructions and tools without requiring every client to understand its internal changes, provided its external contract remains compatible.

Organisational boundaries

A company may collaborate with:

Supplier agents
Logistics agents
Insurance agents
Regulatory agents
Technology-provider agents

without granting them direct access to internal memory or infrastructure.

What A2A does not solve

It does not guarantee agent quality

An agent can be protocol-compliant and still produce:

Incorrect conclusions
Poor reasoning
Incomplete results
Unsafe recommendations
Hallucinated evidence

It does not establish trust automatically

An Agent Card describes what an agent claims it can do.

The enterprise must still determine:

Who operates it
Whether the provider is approved
Which assurance process applies
Which data it may receive
How it has been tested
Which liabilities apply

It does not create a universal ontology

Two agents may use the word “customer,” “account” or “approved” differently.

Shared business semantics remain necessary.

It does not provide enterprise governance by itself

A2A defines communication mechanisms.

Organisations still need:

Agent inventory
Ownership
Risk classification
Access policy
Lifecycle management
Evaluation
Incident response
Cost controls

It does not eliminate integration

A specialist agent must still integrate correctly with:

Databases
APIs
Business rules
Identity systems
Workflows
Documents

It does not make autonomous execution safe

An agent should not be allowed to perform every action merely because another agent requested it.

Security risks in A2A systems

A multi-agent architecture creates new trust paths.

Agent impersonation

An attacker may publish a malicious Agent Card or imitate a trusted agent endpoint.

Controls include:

HTTPS
Certificate validation
Signed Agent Cards
Approved registries
Provider allowlists
Mutual TLS where appropriate

Excessive delegation

A coordinator may delegate work that it was not authorised to perform itself.

Delegation must not expand authority.

The remote agent should verify:

Caller identity
User identity where applicable
Tenant
Requested skill
Resource scope
Purpose
Required approval

Confused-deputy attacks

A remote agent may have powerful credentials and accidentally use them on behalf of an unauthorised caller.

Do not assume that a trusted agent is authorised for every action.

Prompt injection propagation

One agent may retrieve malicious content and pass it to another agent.

The second agent may interpret the content as an instruction rather than data.

Every agent should treat incoming messages, artifacts and retrieved content as untrusted.

Context poisoning

Incorrect information supplied by one agent may contaminate the task state or another agent’s memory.

Record provenance and distinguish:

User instruction
Agent hypothesis
Verified fact
Tool result
Policy decision
Human approval

Privilege chaining

Several low-risk actions may combine into a high-risk outcome.

For example:

Research agent finds employee
→ identity agent finds account
→ support agent resets email
→ access agent changes credentials

The complete chain must be evaluated, not only each call in isolation.

Cascading failure

One incorrect artifact can trigger several downstream decisions.

Use:

Validation
Checkpoints
Confidence thresholds
Independent verification
Human approval
Compensation

Data leakage

Messages and artifacts may contain:

Personal data
Credentials
Documents
Commercial information
Source code
Internal policy

Share only the minimum context required.

Denial of service and cost amplification

Agents may:

Delegate recursively
Retry indefinitely
Generate excessive tasks
Exchange large artifacts
Create tool loops
Consume large model budgets

Enforce:

Hop limits
Task quotas
Timeouts
Budget limits
Maximum artifact sizes
Recursion controls

Rogue or compromised agents

An approved agent may become compromised or change behaviour.

Enterprises need:

Revocation
Version pinning
Continuous evaluation
Behaviour monitoring
Emergency isolation
Registry updates

Authentication and authorisation

A2A uses familiar enterprise security mechanisms.

Agent Cards can declare schemes such as:

API keys
HTTP bearer authentication
OAuth 2.0
OpenID Connect
Mutual TLS

The protocol itself does not place user identity directly inside every message payload.

Identity is normally established through the transport and authentication layer.

Every request must be authorised

The remote agent should authorise:

Task creation
Task retrieval
Task listing
Cancellation
Subscription
Artifact access
Skill invocation
Underlying business actions

In-task authorisation

A task may begin successfully but later require additional authority.

For example, an agent can investigate an account using read access but require separate authorisation before issuing a refund.

The task can enter an authentication-required state while the client obtains:

User approval
OAuth consent
Additional credentials
A privileged review decision

The task can then resume.

Multi-tenancy

A2A deployments must preserve tenant boundaries across:

Agent discovery
Tasks
Context IDs
Artifacts
Message history
Logs
Push notifications
Cached Agent Cards
Downstream tools

Never rely on a tenant identifier supplied by the model as the sole enforcement mechanism.

Tenant scope should come from authenticated identity and trusted routing context.

Human oversight

A2A can coordinate autonomous agents, but enterprise automation still requires clear human boundaries.

Require approval for:

Financial transfers
Refunds
Account suspension
External communications
Production deployments
Security-policy changes
Contract commitments
Hiring decisions
Regulatory submissions
Destructive operations
High-volume updates

Approval should be bound to the exact:

Action
Agent
Target
Amount
Arguments
Environment
Expiry
Task
Policy version

The system should revalidate the current state before execution after an approval delay.

Observability for multi-agent workflows

An A2A transaction can cross:

Several agents
Several organisations
Several models
Several tools
Several clouds
Several hours or days

Observability must follow the complete workflow.

Record:

User request ID
Parent workflow ID
Task ID
Context ID
Client-agent identity
Remote-agent identity
Agent Card version
Model version where available
Skill
Policy decisions
Messages
Artifact metadata
Tool calls
Approval
Errors
Latency
Cost
Final outcome

A2A guidance recommends distributed tracing, comprehensive task logging, operational metrics and auditing of important state changes.

OpenTelemetry can propagate trace context across the HTTP interactions, but the enterprise must preserve correlation when an agent creates new tasks or calls tools internally.

Agent registries and governance

An enterprise agent registry should contain more than Agent Cards.

Useful metadata includes:

Agent owner
Provider
Approved environments
Business domain
Skills
Data classification
Allowed tenants
Risk rating
Authentication scheme
Required scopes
Evaluation status
Model dependencies
Version
Support contact
Incident history
Approval requirements
Retirement date

Agent lifecycle

Govern:

Registration
Security review
Evaluation
Approval
Deployment
Monitoring
Version change
Suspension
Revocation
Retirement

A discoverable agent should not automatically become an approved agent.

Choosing an orchestration topology

Central coordinator

One coordinator delegates tasks to specialist agents.

Advantages:

Clear control
Easier auditing
Central policy enforcement
Simpler user experience

Risks:

Bottleneck
Single point of failure
Coordinator receives broad context
Excessive central authority

Hierarchical orchestration

A coordinator delegates to domain coordinators, which delegate to specialists.

Useful for large organisations.

The main risks are excessive delegation depth and unclear accountability.

Peer-to-peer mesh

Agents discover and contact one another directly.

This can increase flexibility but makes:

Policy enforcement
Cost control
Traceability
Loop prevention
Incident containment

more difficult.

Deterministic graph with A2A steps

A workflow engine controls the structure, while A2A agents perform selected tasks.

This is often the safest enterprise starting point.

When A2A is a strong fit

Consider A2A when:

Agents are built with different frameworks
Agents are owned by different teams
Agents run in different clouds
A capability must be reused by several assistants
Work crosses organisational boundaries
Tasks are stateful or long-running
Agents need clarification or additional authorisation
Outputs include structured artifacts
Vendor independence is important
The enterprise expects a growing agent ecosystem

When A2A may be unnecessary

A2A may add little value when:

One application contains all agents
The framework already provides sufficient internal orchestration
The process uses only one agent
A deterministic API solves the requirement
The operation is low-latency and stateless
Agents will never be reused externally
The organisation cannot govern distributed agent authority
A normal workflow is safer and simpler

Do not turn every internal model call into a networked agent service.

A practical implementation roadmap

Phase 1: Choose one cross-agent business outcome

Examples include:

Resolve a customer billing dispute
Assess a supplier
Investigate an IT incident
Prepare a compliance report
Coordinate recruitment scheduling

Phase 2: Separate agent responsibilities

Define which agent owns:

Planning
Domain analysis
Data retrieval
Policy evaluation
Execution
Communication

Avoid several agents with overlapping and ambiguous responsibilities.

Phase 3: Define the task contract

For every delegated task, specify:

Goal
Required input
Expected artifact
Completion criteria
Maximum duration
Allowed data
Required assurance
Approval boundaries
Failure behaviour

Phase 4: Publish restricted Agent Cards

Expose only the information required for discovery.

Use authenticated extended cards for sensitive capabilities.

Phase 5: Establish identity and authorisation

Define:

Agent identity
User delegation
Tenant
Scopes
Allowed skills
Data-access boundaries
Credential expiry
Revocation

Phase 6: Implement one client and one remote agent

Start with a bounded relationship rather than a broad agent mesh.

Phase 7: Add durable task handling

Support:

Task status
Persistence
Retry
Cancellation
Input required
Authentication required
Artifact storage
Idempotency

Phase 8: Add observability

Propagate:

Trace ID
Workflow ID
Task ID
Context ID
User and tenant scope
Agent identity

Phase 9: Add human approval

Begin by requiring approval for every state-changing operation.

Relax only those operations that prove safe through evaluation.

Phase 10: Threat-model the chain

Test:

Agent impersonation
Malicious Agent Cards
Prompt injection
Cross-tenant access
Excessive delegation
Recursive task loops
Artifact poisoning
Credential misuse
Cascading failure

Phase 11: Test interoperability

Use independently implemented agents where possible.

Test:

Discovery
Version negotiation
Authentication
Tasks
Messages
Artifacts
Streaming
Cancellation
Error handling
Push notifications

Phase 12: Measure outcomes

Track:

Task-completion rate
Correct-agent routing
Delegation count
Total workflow latency
Inter-agent failure rate
Artifact-validation failures
Human interventions
Permission denials
Cost per completed outcome
Business time saved

Common implementation mistakes

1. Creating an agent for every microservice

Agents should represent capabilities requiring interpretation or adaptive work—not every deterministic endpoint.

2. Exposing all agents to all callers

Use controlled registries, allowlists and capability-based access.

3. Trusting Agent Card descriptions blindly

Capability claims require provider verification and testing.

4. Passing complete conversation history

Share task-specific context, not every user message and private memory.

5. Allowing delegated authority to expand

A downstream agent must not receive more authority than the initiating user and client agent are permitted to delegate.

6. Using messages as the only durable state

Persist important task state and outputs structurally.

7. Ignoring artifact validation

An artifact is untrusted until its format, source and content are validated.

8. Using autonomous agents where a workflow is sufficient

Flexibility is not automatically better than predictability.

9. Missing global limits

Per-agent limits do not prevent the full agent network from exceeding cost, time or action limits.

10. No single accountable owner

A workflow involving ten agents still requires one accountable business and technical owner.

The emerging state of A2A

A2A was introduced by Google in April 2025 and was transferred to Linux Foundation governance in June 2025.

The protocol reached version 1.0 as its first stable, production-ready release. Its current specification includes:

A canonical protocol data model
Agent Card discovery
Messages, tasks and artifacts
Streaming and push updates
Version negotiation
Authentication declarations
JSON-RPC, gRPC and HTTP+JSON/REST bindings
Extensions and custom-binding guidance
Multi-tenant and enterprise-security guidance

By April 2026, the Linux Foundation reported support from more than 150 organisations and production use across areas including supply chain, finance, insurance and IT operations. [1][2]

These adoption figures indicate meaningful momentum.

They do not mean that every A2A implementation is automatically mature, interoperable or secure.

Enterprises should still validate the:

Protocol version
SDK quality
Supported binding
Security model
Framework integration
Operational behaviour
Vendor implementation
Governance process

The future of enterprise automation

The first generation of automation connected applications.

The second connected APIs and workflows.

The next generation may connect outcome-oriented agents.

A future enterprise request could look like:

Assess the impact of the supplier disruption, identify affected customer commitments, prepare alternative sourcing options, calculate the financial implications and request approval for the preferred plan.

No single agent should need unrestricted access to:

Supply-chain systems
Customer contracts
Finance
Compliance
Procurement
Communications

A coordinator can delegate bounded work to separately governed domain agents.

Each specialist returns evidence and artifacts.

Deterministic policy controls what can happen next.

Humans approve consequential decisions.

This model can increase modularity and reuse, but only when agent collaboration is treated as distributed enterprise computing rather than an informal conversation among chatbots.

Conclusion

A2A provides a standard communication layer for a world in which enterprises operate many specialised AI agents.

It allows agents to:

Discover one another
Advertise skills
Delegate work
Exchange context
Manage long-running tasks
Request input or authorisation
Stream progress
Return structured results

Its main value is interoperability.

A support agent built by one team can work with a finance agent from another platform without either agent exposing its private implementation.

But protocol interoperability is only one layer of a trustworthy system.

Enterprises must still provide:

Identity
Authentication
Authorisation
Data minimisation
Policy enforcement
Human approval
Durable workflows
Artifact validation
Observability
Evaluation
Incident response
Lifecycle governance

The right question is not:

How many agents can we connect?

It is:

Which specialised responsibilities should be delegated across agent boundaries, and how can every delegation remain authorised, observable and accountable?

That is what will determine whether A2A becomes meaningful enterprise automation or simply a larger network of unpredictable systems.

Frequently Asked Questions

What is A2A?

A2A, or Agent2Agent Protocol, is an open standard that allows independent AI agents to discover, communicate and collaborate across different frameworks, vendors and platforms.

Who created the A2A protocol?

Google introduced A2A in April 2025. The project was subsequently transferred to Linux Foundation governance.

Is A2A production-ready?

A2A version 1.0 is described by the project as its first stable, production-ready protocol release. Individual products and integrations still require separate evaluation.

What is an Agent Card?

An Agent Card is a machine-readable JSON description of an agent’s identity, endpoint, skills, capabilities, supported interfaces and authentication requirements.

Where is an Agent Card published?

A public agent can publish its card at /.well-known/agent-card.json. Enterprises can also use registries or direct configuration.

What is an A2A Task?

A Task is the stateful unit of work in A2A. It records the current state, context, message history and output artifacts.

What is an A2A Artifact?

An Artifact is an output generated by a task, such as a report, document, structured dataset, image or code patch.

What is the difference between a Message and an Artifact?

Messages coordinate and discuss the task. Artifacts contain the task’s outputs.

Does A2A support long-running tasks?

Yes. It supports task states, streaming updates, resubscription and asynchronous webhook notifications.

What is the difference between A2A and MCP?

A2A enables independent agents to collaborate. MCP enables an agent or model to access tools, APIs, data sources and resources.

Can an A2A agent use MCP?

Yes. A remote A2A agent can internally use MCP servers to access the tools and information needed to complete its task.

Does A2A replace APIs?

No. A2A uses and complements existing APIs and enterprise services.

Does A2A require one AI model?

No. Agents can use different models, languages, frameworks and infrastructure.

Do A2A agents share memory?

Not necessarily. A2A is designed so agents can collaborate without exposing their private memory or internal implementation.

How is A2A secured?

A2A uses established enterprise mechanisms including HTTPS, OAuth 2.0, OpenID Connect, API keys, bearer tokens and mutual TLS.

Does A2A automatically make agents trustworthy?

No. Protocol compliance does not establish provider trust, agent competence, data quality or business authority.

Should A2A agents receive administrator access?

No. Each agent should receive narrowly scoped, short-lived permissions for the current task.

Can A2A support human approval?

Yes. A task can pause when authentication or authorisation is required, allowing the client to obtain human approval or credentials before continuing.

When should an enterprise use A2A?

Use it when independently developed or operated agents need to collaborate across framework, platform, team, cloud or organisational boundaries.

When is A2A unnecessary?

It may be unnecessary for one-agent systems, simple API operations, deterministic workflows or agents contained entirely within one framework.