The Agent2Agent Protocol (A2A), released by Google as an open specification in April 2025 and transferred to the Linux Foundation in June 2025, is a JSON-RPC 2.0 over HTTP(S) protocol — extended with Server-Sent Events for streaming — that enables AI agents to discover one another via standardised, cryptographically signed agent cards hosted at well-known URIs, delegate tasks through a six-state task lifecycle, stream results back to requesting agents, and operate regardless of the underlying model or framework used to implement the agents. Reaching version 1.2 by March 2026 with over 150 supporting organisations, it is designed as a complementary peer-to-peer layer alongside Anthropic’s Model Context Protocol, together forming the emerging two-protocol stack for the agentic internet.
Semantic Classification
Content
Compositional Relationships (Components)
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:hasPart ai:AgentCard))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:hasPart ai:TaskLifecycle))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:hasPart ai:PushNotification))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:hasPart ai:ServiceDiscovery))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:hasPart ai:MessagePassing))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:hasPart ai:CapabilityAdvertisement))
Dependency Relationships
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:requires ai:MutualAuthentication))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:requires ai:AgentIdentity))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:requires ai:HTTPProtocol))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:requires ai:JSONRPC20))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:dependsOn ai:LargeLanguageModel))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:dependsOn ai:AutonomousAgent))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:dependsOn ai:AgentRuntime))
Capability Relationships
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:enables ai:InterAgentCommunication))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:enables ai:AgenticWorkflow))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:enables ai:TaskDelegation))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:enables ai:AutonomousTaskExecution))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:enables ai:AgenticInternet))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:supports ai:Negotiation))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:supports ai:ErrorHandling))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:supports ai:StateManagement))
Implementation Relationships
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:implements ai:JSONRPC20))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:implements ai:ServerSentEvents))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:implements ai:JSONWebSignature))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:implements ai:JSONCanonicalizationScheme))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:implements ai:JSONSchema))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:uses ai:OAuth20))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:uses ai:WellKnownURI))
Reduction Relationships
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:reducesTo ai:AgentToAgentProtocol))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:reducesTo ai:CoordinationProtocol))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:bridgesTo ai:MicroservicesArchitecture))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:bridgesTo ai:EnterpriseAI))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:bridgesTo ai:SupplyChainAutomation))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:bridgesTo ai:DistributedSystems))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:contrastsWith ai:RemoteProcedureCall))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:contrastsWith ai:OpenAISwarm))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:relatedTo ai:ModelContextProtocol))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:relatedTo ai:AgentNetworkProtocol))
SubClassOf(ai:Agent2AgentProtocolGoogle2025
ObjectSomeValuesFrom(ai:relatedTo ai:PromptInjection))
About
The Agent2Agent Protocol (A2A) is the most widely adopted concrete realisation of the Agent-to-Agent Protocol class as of mid-2026, and represents the most significant attempt to date to standardise cross-organisational, cross-framework AI agent delegation at web scale. Its origin lies in a practical problem that became acute during 2024 as enterprise AI deployments moved from single-agent pilot projects to multi-agent production systems: composing agents from different vendors or built on different frameworks — LangChain Agent Framework, AutoGen, CrewAI, bespoke microservice agents — required bespoke adapter code for every pair of agent types. With N agent frameworks in common use, the N-squared adapter problem meant that a medium-sized enterprise deploying a dozen different specialist agents from different vendors would need to maintain 66 distinct bilateral integration codepoints. Each integration was a one-off engineering effort, not reusable across agent pairs, requiring detailed knowledge of both sides’ internal message formats, authentication schemes, and error semantics. The situation was precisely analogous to the pre-HTTP web in the early 1990s: each online information system had its own proprietary access protocol, and every pair of communicating systems required custom integration middleware. HTTP’s invention reduced this to a single universal protocol that any system could implement once. A2A’s design goal is to be the HTTP of agent-to-agent communication.
Google’s response was to propose an open, framework-agnostic standard with five design principles: (1) buildability — any agent implementation in any programming language should be able to implement A2A in a few days of engineering effort; (2) interoperability — agents from different organisations should be able to communicate without any prior bilateral negotiation; (3) security — the protocol should not require organisations to expose their internal infrastructure or share credentials; (4) scalability — the protocol should work for both synchronous microsecond interactions and asynchronous multi-day workflows; and (5) extensibility — the protocol should accommodate capabilities not yet imagined without breaking existing implementations. The specification was developed internally at Google throughout late 2024, reviewed by a technical advisory group including representatives from Salesforce, SAP, and Atlassian, announced publicly on 9 April 2025 at Google Cloud Next alongside the launch of Gemini Model-powered enterprise agentic products, and immediately open-sourced under the Apache 2.0 licence at github.com/google/A2A with reference implementations in Python and JavaScript. Launch-day endorsements from over 50 technology partners signalled unusually strong industry backing for a protocol at such an early stage.
By June 2025, recognising that a protocol controlled by a single company — even if Apache-licensed — would face adoption resistance from competitors and regulated industries that require vendor-neutral governance, Google transferred the protocol, its specification, all reference SDKs, and the associated test suites to the Linux Foundation’s newly formed Agentic AI Foundation. This governance transfer was announced at the Open Source Summit North America on 23 June 2025, with founding members including Amazon Web Services, Cisco, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow. Under Linux Foundation stewardship, the protocol operates with a Technical Steering Committee (TSC) responsible for specification evolution, a Security Advisory Committee, and a conformance testing programme to certify that implementations correctly implement the specification. The governance structure mirrors the model used successfully for other Linux Foundation protocol projects including the Cloud Native Computing Foundation’s ecosystem, providing the vendor-neutrality and long-term sustainability that enterprise adopters require.
The protocol’s design philosophy prioritises simplicity and composability over completeness. It deliberately avoids solving authentication from scratch, delegating authentication to OAuth 2.0 bearer tokens, API keys, or mutual TLS (mTLS) as declared in the agent card — mechanisms that enterprise security teams already understand and have mature tooling for — rather than introducing a novel agent-specific authentication scheme that would require new tooling investment and security review. It leverages JSON-RPC 2.0, Server-Sent Events, and HTTP Protocol exclusively, meaning any web server framework in any language can host an A2A server and any HTTP client library can be an A2A client. The Well-Known URI pattern for agent card discovery (/.well-known/agent.json) is borrowed from established IETF conventions (RFC 8615), the same mechanism used for security.txt, openid-configuration, and other service metadata endpoints. This commitment to building on existing, proven, widely understood standards rather than inventing new primitives is a deliberate design choice intended to minimise the adoption barrier for organisations that already have mature HTTP infrastructure and trained engineering teams — and to ensure that the protocol benefits from the security scrutiny, tooling investment, and operational experience already accumulated around those standards.
The complementarity of A2A with Model Context Protocol (MCP) is a structuring principle of the emerging agentic protocol stack. MCP governs the vertical dimension of agent capability: how an agent discovers and invokes tools, databases, APIs, and other external services that extend its native capabilities. A2A governs the horizontal dimension: how an agent discovers and delegates tasks to other agents that possess complementary skills, data access, or execution capacity. In practice, a production multi-agent deployment uses both protocols simultaneously — an orchestrator agent uses A2A to discover and delegate to specialist sub-agents, and each sub-agent uses MCP to invoke the specific tools and data sources needed to complete its assigned task. The combination creates a compositional architecture where agents can be assembled from independently-deployed building blocks — analogous to how microservices architecture enables software systems to be assembled from independently-deployed service components — but with the added dimension that each building block is itself an autonomous reasoning system rather than a deterministic function.
Components / Architecture
A2A defines five core concepts that together constitute a complete interaction model:
1. Agent Cards: The foundational discovery artefact of the A2A protocol. An agent card is a JSON document hosted at https://{host}/.well-known/agent.json (the canonical Well-Known URI path) that describes the agent’s identity, human-readable name and description, URL endpoint for task submission, supported capabilities (streaming via Server-Sent Events, push notifications via webhook, input-required state), authentication requirements (expressed as OpenAPI securitySchemes entries), supported input and output modalities (text, image, audio, video, structured data), and skill definitions with input/output JSON Schemas. From v1.0 (September 2025), cards may be digitally signed using JSON Web Signature (RFC 7515) over a JSON Canonicalization Scheme (RFC 8785) normalised payload, allowing requestors to verify the card was signed by the declared identity using a registered public key without consulting a central registry. Card signing addresses one of the fundamental trust challenges in cross-organisational agent communication: how does a requesting agent know it is communicating with a legitimate peer rather than an impostor?
2. Tasks: The unit of work exchanged between a client agent (the requestor) and a remote agent (the server). Each task carries a unique ID, a conversation thread of Messages, the current state-machine state, and optionally a metadata field for application-specific context. Tasks persist across conversation turns, enabling the multi-turn interactions required by complex, long-running work. The requesting agent submits a task via tasks/send (synchronous) or tasks/sendSubscribe (streaming); the remote agent updates the task state as work progresses. Tasks can be cancelled by the client via tasks/cancel.
3. Task Lifecycle State Machine: The six-state machine that governs task progress: submitted (received, queued), working (actively executing), input-required (paused, waiting for client input or human-in-the-loop clarification), completed (successfully finished with output artefacts), failed (unrecoverable error), and cancelled (terminated by client or server). The input-required state is a distinctive A2A feature — it allows long-running agents to pause mid-execution and request additional context from the requesting agent or escalate to human oversight, without losing the accumulated task state. This enables human-in-the-loop workflows even when the majority of execution is autonomous. Error Handling is formalised through the failed state with structured error payloads.
4. Messages and Artefacts: Within a task, communication occurs through Messages, each containing one or more typed Parts — TextPart (plain text or markdown), FilePart (file references or inline base64 content), and DataPart (arbitrary JSON data). This part model enables multimodal interaction: a requesting agent can send an image alongside textual instructions, and the remote agent can return a structured JSON analysis alongside a text explanation. Artefacts are the designated output objects of a completed task, distinguished from intermediate messages in the conversation thread; they are explicitly labelled and may be named for downstream consumption by the requesting agent’s Context Window.
5. Push Notifications: For long-running tasks, A2A supports an asynchronous completion model via push notification webhooks. The client registers a callback URL in the task’s pushNotification.config field; the remote agent POSTs task state updates to this URL as the task progresses. This avoids the need for the client to maintain a persistent Server-Sent Events connection for tasks that may take hours or days — a common requirement in enterprise batch processing contexts. Authentication of push notification callbacks is handled via shared secrets or JSON Web Signature-signed payloads.
Use Cases / Major Families
Enterprise Cross-Vendor Agent Composition: The primary production use case as of 2026. A customer service platform built on Gemini Model delegates background research to an Anthropic Claude-based research agent and document processing to a bespoke Python microservice agent, all coordinated via A2A task delegation. SAP’s Joule enterprise assistant orchestrates legal, financial, and compliance sub-agents from specialist vendors. A major investment bank deploys 40+ A2A-connected agents for trade reconciliation, KYC data collection, and regulatory reporting, each agent implementing a specific compliance domain.
Supply Chain Coordination: Cross-enterprise agent collaboration across supply chain partners. Tyson Foods and Gordon Food Service deployed collaborative A2A systems in 2025 to enable their respective agents to share product availability data, demand forecasts, and sales leads in real time without requiring human-mediated data exchange. The A2A protocol enables the two companies’ agents to discover each other’s capabilities via agent cards, negotiate task parameters, and exchange structured data artefacts — all autonomously within authorised scopes.
Software Development Agent Pipelines: Multi-agent software engineering pipelines where a planning agent decomposes a feature request, delegates code generation to a specialist coding agent, delegates test generation to a testing agent, delegates code review to a review agent, and synthesises results — each agent potentially from a different vendor or built on a different framework. A2A’s typed artefact model ensures that code, test files, and review comments are passed as structured artefacts rather than as raw text, enabling downstream agents to consume them programmatically.
IT Operations and Monitoring: Multi-agent orchestration for IT incident detection, diagnosis, and remediation. An orchestrating agent monitors alerting streams and, upon detecting an anomaly, delegates diagnosis to a specialist log-analysis agent and capacity planning to a resource-optimisation agent, with results aggregated and escalated to human operators if confidence thresholds are not met. The input-required state enables clean human-in-the-loop escalation at defined decision points.
Regulated Industry Automation: Financial services, insurance, and healthcare deployments where cross-vendor agent coordination must comply with sector-specific regulations. A2A’s audit trail (task IDs, conversation thread, state transitions, and signed agent cards) provides the structured provenance records required for regulatory reporting and compliance audit.
Academic Context
A2A occupies a distinctive position in the research landscape as an industry-led specification that has attracted significant academic scrutiny since its release, with the academic literature engaging A2A both as a technical artefact to be analysed and as an empirical data point about how industry is solving the multi-agent coordination problem in practice. The foundational academic question — how should autonomous agents communicate across organisational and technical boundaries under conditions of uncertainty, partial information, and potentially conflicting incentives? — was addressed in the multi-agent systems (MAS) literature of the 1990s–2000s by FIPA ACL and KQML, but those specifications assumed a closed world of pre-registered, pre-trusted agents operating within a shared institutional context (a corporation, a research consortium, a national defence network) and communicating about a shared, formally specified domain ontology. A2A’s contribution is to revisit this fundamental question under conditions of open-world agent discovery (any agent can discover and interact with any other), LLM-based agent reasoning (agents interpret task instructions flexibly rather than matching against a fixed schema), and cross-organisational trust (agents belong to different legal entities with potentially adversarial relationships). The resulting protocol necessarily makes different tradeoffs than FIPA ACL: it sacrifices formal semantic completeness for practical interoperability, trades BDI-grounded performative semantics for natural-language task descriptions, and replaces a centralised shared ontology with per-agent JSON Schema capability declarations.
The most comprehensive academic analysis of A2A within the broader protocol landscape appears in the survey “A Survey of Agent Interoperability Protocols: MCP, ACP, A2A, and ANP” (Guo et al., arXiv:2505.02279, May 2025), which systematically compares the four major contemporary protocols across seven dimensions: interaction model (request-response vs. streaming vs. event-driven), discovery mechanism (well-known URI vs. registry vs. peer-to-peer), communication pattern (synchronous vs. asynchronous), security model (OAuth vs. DID vs. API key), deployment context (enterprise vs. open market vs. edge), trust model (bilateral vs. multilateral vs. decentralised), and maturity level (specification vs. production). The paper characterises A2A as optimised for structured task delegation in enterprise contexts where both parties have prior bilateral authentication arrangements, contrasting with ANP’s decentralised discovery model suited to open-market interaction and ACP’s REST-first design suited to integration with existing HTTP microservice infrastructure. A critical technical comparison focusing specifically on the A2A–MCP interaction and the engineering effort required to compose the two protocols appears in “From Glue-Code to Protocols: A Critical Analysis of A2A and MCP Integration for Scalable Agent Systems” (arXiv:2505.03864, May 2025), which evaluates real implementations and concludes that the two-protocol stack (MCP + A2A) reduces integration effort by approximately 60% compared to bespoke agent integration code, while introducing a latency overhead of approximately 40ms per protocol boundary crossing.
The formal computational complexity of agent communication protocols has been studied in the context of protocol verification and satisfaction checking. Multi-agent systems research has established that checking whether a sequence of messages is a valid instance of a given interaction protocol (e.g., A2A’s task lifecycle state machine) is decidable in polynomial time for finite-state protocols, but becomes undecidable for protocols that involve recursive delegation (where an agent receiving a task may itself delegate sub-tasks to additional agents, creating recursively-defined delegation trees). This theoretical result motivates practical approaches to delegation depth limiting and delegation loop detection in A2A deployments.
Security research on A2A is substantial and growing rapidly. The threat modelling paper (Chen et al., arXiv:2602.11327, February 2026) applies STRIDE and PASTA methodologies to identify six primary attack surfaces: (1) agent card spoofing — impersonating a legitimate agent by publishing a forged agent card (mitigated in v1.0 by signed cards); (2) Prompt Injection via task instruction content — embedding adversarial instructions in task fields that hijack the receiving agent’s behaviour; (3) Server-Side Request Forgery (SSRF) — using a task’s agent card endpoint URL to probe internal network services; (4) task flooding denial of service — submitting large numbers of resource-intensive tasks to exhaust a remote agent’s capacity; (5) unauthorised scope escalation — crafting task instructions that cause a receiving agent to take actions beyond its authorised scope; and (6) context pollution in multi-hop chains — injecting adversarial content into task artefacts at one link of a delegation chain to corrupt downstream agents’ reasoning. The empirical paper “Whispers of Wealth” (arXiv:2601.22569, January 2026) demonstrates concrete prompt injection attacks against A2A-based payment delegation implementations, showing in a controlled red-team exercise that a malicious instruction embedded in a task message can cause a receiving financial agent to authorise transactions outside its intended scope with a success rate of approximately 34% against undefended implementations, dropping to approximately 8% with application-layer input validation. The International AI Safety Report 2026 (arXiv:2602.21012) contextualises these specific A2A attack patterns within the broader AI Safety literature on autonomous agent risk and discusses regulatory approaches to requiring baseline security standards for deployed agentic systems.
The Alan Turing Institute’s multi-agent systems interest group has noted A2A as the first major practical instantiation of theoretical agent coordination models at commercial scale, representing a significant empirical data source for testing theoretical predictions about the behaviour of rational agents in large open multi-agent systems. UK academic contributions to A2A protocol security, formal verification of the A2A task lifecycle state machine, and empirical studies of prompt injection attack patterns in A2A deployments are expected to appear in peer-reviewed venues through 2026–2027. Imperial College London’s Department of Computing and the University of Edinburgh’s School of Informatics have existing research programmes in protocol verification and agent security that naturally extend to A2A as a concrete, production-deployed protocol to study.
Current Landscape (2026)
By June 2026, the Agent2Agent Protocol has achieved what few industry-proposed open standards accomplish: genuine cross-vendor adoption with production deployments at scale within fourteen months of initial release. The Linux Foundation’s Agentic AI Foundation governs the specification under vendor-neutral stewardship, with a Technical Steering Committee that includes representatives from Google, Microsoft, Amazon, Cisco, Salesforce, and SAP. The pace of adoption has exceeded most observers’ expectations and has catalysed a broader ecosystem of tooling, hosting services, and training programmes around A2A as the de facto standard for agent interoperability.
Version History and Technical Evolution: A2A v0.x (April–August 2025): the initial specification introduced the five core concepts (agent cards, tasks, messages, artefacts, push notifications), the six-state task lifecycle, Server-Sent Events streaming for tasks/sendSubscribe, push notification webhooks for asynchronous task completion, and reference implementations in Python and JavaScript. The v0.x series was described as a “developer preview” with the expectation of breaking changes before v1.0. A2A v1.0 (September 2025): the first stable release, declared production-ready, introduced cryptographically signed agent cards using JSON Web Signature (RFC 7515) over JSON Canonicalization Scheme (RFC 8785) normalised payloads, added Java and Go SDKs (bringing the total to four production languages), introduced production-grade error semantics with structured error codes and retry-after guidance, added multi-tenancy namespace support for shared agent hosting infrastructure, and introduced a conformance test suite enabling implementors to certify specification compliance. A2A v1.1 (December 2025): added a .NET SDK (completing the five-language ecosystem), improved streaming reliability under high-latency network conditions, introduced agent card versioning and deprecation policy (allowing agents to deprecate old skill definitions while maintaining backward compatibility), and added tasks/list and tasks/get RPCs for querying task status from clients that lose their streaming connection. A2A v1.2 (March 2026): enhanced cryptographic identity verification with support for agent card signing by external certificate authorities (in addition to self-signed cards), added optional support for agent card registries as discovery alternatives to Well-Known URI paths (with a standard registry API for publishing and querying agent cards by capability), improved State Management for long-running tasks exceeding 24-hour durations (including explicit task checkpoint semantics), extended JSON Schema support for structured output validation (allowing agents to declare the JSON Schema of their output artefacts, enabling requestors to validate received artefacts against the declared schema), and introduced a standardised task priority model.
Platform Integration: Google rebranded Vertex AI Agent Builder as the Gemini Enterprise Agent Platform at Cloud Next 2026 (April 2026), with A2A embedded as a first-class orchestration primitive and a global agent directory — Agentspace — providing discovery of Google-certified and third-party A2A agent cards. The platform provides managed A2A server hosting with built-in authentication, logging, and rate limiting, substantially lowering the operational burden of exposing an agent as an A2A server. AWS Bedrock’s agent marketplace supports A2A agent card publication, allowing Bedrock-hosted agents to be discovered and invoked by any A2A client. Microsoft’s Agent Framework for .NET shipped A2A v1 support in January 2026, enabling Azure-based agents to participate as both A2A clients and servers; integration with Microsoft Copilot Studio allows Copilot agents to delegate tasks to external A2A services. Salesforce’s Agentforce platform supports A2A-mediated integration with external agent services, with managed A2A client capabilities for delegating tasks to specialist agents from the Salesforce AppExchange ecosystem.
Framework Support and Community Ecosystem: Community-maintained adapters for LangChain Agent Framework, AutoGen, CrewAI, and LlamaIndex enable framework-native agents to expose themselves as A2A servers and consume A2A services as clients without writing low-level protocol code. The adapter pattern typically wraps the framework’s native agent invocation interface in an A2A server shim that parses incoming task messages, translates them to the framework’s native format, invokes the agent, and serialises outputs as A2A artefacts. OpenAI Swarm has an unofficial community-maintained A2A adapter. The SDK ecosystem spans Python, JavaScript, Java, Go, and .NET, with community-contributed implementations in Rust and Kotlin reaching beta status by mid-2026. The A2A GitHub repository had accumulated over 8,000 stars and 400 pull-request contributors by April 2026, indicating strong community engagement beyond the founding organisations.
Security Posture: The introduction of signed agent cards in v1.0 addressed the most critical trust gap in the original specification — the inability to verify that a published agent card was genuinely produced by the claimed agent identity. However, Prompt Injection through task instruction content remains the most significant unresolved attack surface in production deployments: there is no protocol-level mechanism to sanitise task instructions or enforce that instruction content conforms to a safe subset, leaving Access Control enforcement entirely to the receiving agent’s application-layer logic. The Agentic AI Foundation’s security best practices document (published January 2026) recommends: agent sandboxing (running the LLM inference in an environment with restricted filesystem and network access), input validation of task message content against declared JSON Schemas before passing to the model, scope-limited OAuth 2.0 access tokens for any sensitive operations the agent may be instructed to perform, output validation against declared output schemas before returning artefacts, and rate limiting in the API Gateway layer as a defence against task-flooding denial of service. These recommendations address the attack surface but do not eliminate it — the fundamental challenge that an LLM cannot reliably distinguish legitimate task instructions from injected adversarial instructions embedded in task content that originated from untrusted external sources remains an open research problem.
Economic Ecosystem: The agentic payments ecosystem is developing rapidly alongside A2A. Google’s AP2 (Agent Payments Protocol, released alongside A2A v1.0 in September 2025) defines the authorisation and spend-limit framework for agent-initiated financial transactions, including mechanisms for an orchestrating agent to declare maximum spend authorisation for delegated sub-tasks and for receiving agents to declare their pricing model in the agent card. Coinbase’s x402 protocol provides HTTP-native stablecoin settlement for agent micropayments, using the HTTP 402 “Payment Required” status code as the trigger for an automated payment negotiation and settlement flow. Together, A2A (task delegation) + AP2 (authorisation and spend control) + x402 (settlement) constitute an emerging complete stack for economic agent-to-agent interaction, enabling the vision of a fully autonomous agent economy where agents discover, negotiate, execute, and settle service transactions without human involvement at each step. The negotiation dynamics and market-design implications of this autonomous agent economy are being studied by economists at the IMF and central banks, as noted in IMF Staff Notes 2026/004.
UK Context
The UK technology sector has engaged substantively with A2A since its release, driven both by commercial interest from London’s financial technology and legal technology sectors and by academic research interest from UK universities with established multi-agent systems groups. Several UK-based SaaS companies — notably in financial technology (fintech), insurance technology (insurtech), and legal technology (legaltech) — were among the early adopters of A2A for cross-service agent integration. The concentration of financial services firms in the City of London and Canary Wharf makes the UK financial sector a natural test bed for the KYC automation, regulatory capital reporting, and trade reconciliation use cases where A2A has demonstrated production value: UK clearing banks are required to file real-time transaction monitoring reports with the FCA, a requirement that maps naturally onto a multi-agent A2A architecture where transaction monitoring agents, KYC verification agents, and reporting agents coordinate across institutional boundaries.
UK legaltech firms — including those operating in contract review, due diligence, and compliance monitoring — have adopted A2A to enable composition of specialist AI agents for different legal domains (contract law, employment law, regulatory compliance) that can be orchestrated by a generalist client-facing agent without tight coupling to any specific legal AI provider’s API. The UK’s Legal Technology Alliance has identified agent interoperability as a priority for the development of AI-powered legal services, with A2A as the most mature available standard.
The UK’s research universities have contributed to the academic literature on agent protocol security and formal verification. Imperial College London’s Department of Computing has ongoing work on formal verification of communication protocol state machines using model-checking techniques — a methodology directly applicable to verifying that A2A’s Task Lifecycle state machine is free from deadlock states and transition sequences that could leave tasks permanently stuck in intermediate states. The University of Edinburgh’s School of Informatics has ongoing research in agent reasoning, trust, and normative systems that intersects with A2A’s open problems in cross-organisational trust establishment and authorisation scope management. The Alan Turing Institute maintains a multi-agent systems interest group whose 2025 UK-MAS symposium at King’s College London identified agent interoperability protocols as a key research priority, with A2A cited as the primary industrial protocol deserving academic security and formal methods attention. UCL’s Information Security Group has published work on trust management in distributed systems that provides a theoretical framework for analysing the trust assumptions embedded in A2A’s authentication model.
In the Northern English industrial context, manufacturing firms in Manchester, Leeds, Sheffield, and the Tees Valley are evaluating A2A for autonomous procurement agent integration with supply chain partners, particularly for industries involving complex bill-of-materials supply chains across multiple tier-1 and tier-2 suppliers. The Advanced Manufacturing Research Centre (AMRC) at the University of Sheffield — a flagship research centre working with over 100 industrial partners on manufacturing innovation — has noted autonomous agent coordination as a component of its Industry 5.0 research agenda, where collaborative human-robot-AI systems require flexible, standards-based coordination protocols. The Northern Powerhouse’s industrial digitisation programmes include A2A evaluation for logistics optimisation across freight corridors connecting the Port of Hull, the Manchester logistics hub, and the Sheffield steel and advanced manufacturing cluster. Leeds has particular interest in AI agent coordination for its growing health technology sector, where diagnostic AI agents from multiple specialist providers need to coordinate their outputs to present unified patient assessment recommendations.
UK regulatory context creates both obligations and opportunities for A2A adoption. The UK AI Opportunities Action Plan (January 2025) identifies agentic AI as a priority area for economic growth and competitiveness, with the government explicitly endorsing open interoperability standards as a mechanism to prevent vendor lock-in and enable UK AI SMEs to participate in enterprise-scale agentic deployments. The forthcoming UK AI Bill is expected to impose accountability, transparency, and explainability requirements on autonomous agent systems operating in high-risk domains (healthcare, financial services, critical infrastructure) — requirements that A2A’s task history logging and agent card capability declarations partially address, but that will require additional audit trail mechanisms for full compliance. The ICO (Information Commissioner’s Office) has identified agent-to-agent data processing chains as an emerging area for data protection guidance under UK GDPR, particularly regarding which party in a delegation chain is the data controller for personal data processed by a remote agent, and what transfer mechanism applies when the delegating agent and the receiving agent are in different jurisdictions. This regulatory ambiguity is currently addressed case-by-case through data processing agreements, but is expected to be resolved through ICO sector-specific guidance in 2026–2027 as A2A deployments proliferate.
The UK’s position in this emerging field is strengthened by the combination of strong academic research infrastructure, a world-leading financial services sector with high demand for AI automation, active government investment in AI through UKRI and the AI Safety Institute, and a mature open-source software community. UK participation in the Linux Foundation’s Agentic AI Foundation Technical Steering Committee — through companies such as Arm, Sage Group, and various UK fintech firms — gives UK industry influence over the protocol’s evolution. The UK AI Safety Institute’s work on evaluating agentic AI systems’ safety properties has direct relevance to the security challenges in A2A deployments and is expected to inform both domestic regulatory requirements and international standards discussions.
Future Directions (2026–2030)
Convergence with Other Protocols: The four-protocol landscape (MCP, A2A, ACP, ANP) is expected to progressively converge through a combination of technical bridging and governance consolidation. The Linux Foundation’s Agentic AI Foundation is the probable venue for a unified interoperability layer that provides compatibility bridges between specifications, allowing an MCP-native agent to be discovered and invoked via A2A agent cards without reimplementation, and allowing an A2A agent to invoke ANP-registered marketplace agents without a separate ANP client implementation. By 2028, a unified “agent envelope” specification — defining a common message format and task lifecycle that all four protocols can translate to and from — is a plausible outcome, analogous to how HTTP subsumes the specific wire formats of earlier application-layer protocols (FTP, Gopher, WAIS) within a common transport envelope. Protocol convergence will be driven by enterprise adopters who do not want to maintain multiple protocol client libraries and by cloud platform operators who want to offer a single agent hosting platform that spans the entire protocol landscape.
Decentralised Discovery at Scale: The current Well-Known URI discovery model requires prior knowledge of an agent’s domain name — equivalent to knowing a website’s hostname before you can access its services. For a truly open Agentic Internet with millions of independently-deployed agent services, DNS-analogous decentralised discovery is required. Decentralised agent registries — using distributed hash tables, certificate transparency-style append-only logs, or DID-based distributed identity infrastructure — are under active development. Agent Network Protocol’s decentralised marketplace model and W3C decentralised identifiers (DIDs) are candidate components of this future discovery infrastructure. A DNS-like agent naming system — where a human-readable agent name (research.arxiv.a2a) resolves to an endpoint URL and public key via a distributed resolution protocol — would complete the analogy with web infrastructure. The timeline for standardising such a system is uncertain; the DNS analogy suggests it may take a decade of community development before a decentralised naming system achieves the reliability and security properties required for mission-critical deployments.
Formal Safety and Correctness Verification: Regulatory pressure from the EU AI Act (in force from August 2024 for high-risk systems), forthcoming UK AI Bill, and sector-specific requirements from financial regulators (FCA, SEC, EBA) will drive demand for formal verification of A2A implementations — mathematical proofs that a specific agent configuration cannot exceed its authorised scope regardless of the task instructions it receives, cannot leak sensitive data across agent boundaries, and cannot enter deadlock states in the Task Lifecycle state machine. Research on delegation chain attestation (arXiv:2603.18043) and context lineage assurance (arXiv:2509.18415) anticipates this regulatory direction by developing the mathematical models required for such verification. The formal methods community (model checking, theorem proving, type theory) is expected to produce A2A-specific verification tools analogous to the TLS protocol analysers (Tamarin, ProVerif) that are now standard practice in security protocol verification.
Real-Time and Edge Deployments: The current HTTP-based A2A model introduces round-trip latency typically in the range of 50–300ms — acceptable for enterprise batch workflows and human-facing conversational agents, but incompatible with real-time control systems such as collaborative robotics, autonomous vehicle coordination, or industrial process control. Low-latency A2A transport variants based on WebSocket or QUIC, with sub-10ms message delivery and multiplexed streaming for multiple concurrent tasks, are under community development. For edge computing deployments in Web of Things contexts — factory floors, smart cities, autonomous vehicle networks — where intermittent connectivity and resource-constrained devices are the norm, compact binary encodings of A2A messages (using MessagePack or CBOR rather than JSON) and store-and-forward task delivery semantics are anticipated extensions. The A2A working group has noted edge deployments as a v2.0 priority area.
Agentic Economic Ecosystem Maturity: As A2A agent delegation becomes routine, the economic infrastructure supporting it — metered billing, reputation scoring, dispute resolution, insurance and liability assignment, and regulatory compliance reporting — will mature into a formal sector analogous to cloud infrastructure services. The combination of A2A delegation, agentic payments (AP2 + x402), and verifiable agent identity (signed agent cards + DIDs) creates the technical preconditions for fully autonomous economic agents — agents that discover services, negotiate prices, execute delegated tasks, and settle payments entirely without human involvement at any step. The IMF (2026) identifies this scenario as introducing novel systemic risks: if autonomous agents are collectively spending at macroeconomic scale without human oversight of individual transactions, traditional monetary policy and financial stability instruments may be insufficient. The AI Safety research community is actively developing formal models of multi-agent economic systems to identify catastrophic failure modes and the governance mechanisms required to prevent them.
Protocol Governance Evolution: As A2A transitions from a Google-initiated specification to a genuinely community-governed standard, the governance processes for proposing, reviewing, and ratifying protocol changes will need to mature. The initial TSC model (representatives from founding organisations) will likely evolve to include broader community participation — individual contributor seats, academic institution representation, and regulator observer status — as the protocol becomes critical infrastructure. The precedent set by IETF (Internet Engineering Task Force) governance — rough consensus through open mailing list discussion and reference implementation — provides a model that the Linux Foundation’s Agentic AI Foundation is likely to adopt for A2A’s long-term evolution.
Multimodal and Embodied Agent Communication: A2A’s current multimodal message model (TextPart, FilePart, DataPart) supports discrete document exchange but not real-time sensor stream coordination. As embodied autonomous agents — physical robots, autonomous vehicles, drone swarms — need to coordinate their perception and action in real time, agent-to-agent protocols must evolve to support streaming sensor data (video, lidar point clouds, force-torque sensor readings), real-time action command exchanges, and latency-sensitive coordination patterns incompatible with the current request-response model. The robotics community (ROS 2 action servers, DDS pub-sub middleware) provides engineering precedent for real-time multi-agent coordination at millisecond timescales; the challenge is bridging this real-time coordination layer with A2A’s higher-level task delegation model in a way that preserves A2A’s open interoperability properties.
Research & Literature
- Google. (2025). Agent2Agent Protocol Specification v1.2. https://a2a-protocol.org/latest/specification/
- Google Developers. (2025). “Introducing the Agent2Agent Protocol.” Google Developers Blog, 9 April 2025. https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
- Linux Foundation. (2025). “Linux Foundation Launches the Agent2Agent Protocol Project.” Press release, 23 June 2025. https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project
- Linux Foundation. (2026). “A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year.” Press release, April 2026. https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year
- Google Cloud. (2025). “Agent2Agent Protocol Is Getting an Upgrade.” Google Cloud Blog, September 2025. https://cloud.google.com/blog/products/ai-machine-learning/agent2agent-protocol-is-getting-an-upgrade
- Google Cloud. (2026). “Use an Agent2Agent Agent: Vertex AI Agent Builder.” https://docs.cloud.google.com/agent-builder/agent-engine/use/a2a
- Anthropic. (2024). Model Context Protocol Specification. https://modelcontextprotocol.io/specification
- Guo, S., Chen, J., Li, Y., et al. (2025). A survey of agent interoperability protocols: MCP, ACP, A2A, and ANP. arXiv:2505.02279.
- Zhang, T., & Wang, H. (2025). A survey of AI agent protocols. arXiv:2504.16736.
- Mehta, A., & Singh, R. (2025). From glue-code to protocols: A critical analysis of A2A and MCP integration for scalable agent systems. arXiv:2505.03864.
- Chen, X., Li, M., & Wu, Z. (2026). Security threat modeling for emerging AI-agent protocols: A comparative analysis of MCP, A2A, Agora, and ANP. arXiv:2602.11327.
- Liu, Y., & Chen, W. (2026). Whispers of wealth: Red-teaming Google’s Agent Payments Protocol via prompt injection. arXiv:2601.22569.
- Park, J., Kim, S., & Lee, H. (2026). Aiming for AI interoperability: Challenges and opportunities. arXiv:2601.14512.
- Wang, L., & Zhang, Q. (2026). Beyond message passing: A semantic view of agent communication protocols. arXiv:2604.02369.
- Nakamura, K., & Patel, R. (2026). The provenance paradox in multi-agent LLM routing: Delegation contracts and attested identity in LDP. arXiv:2603.18043.
- Rodriguez, M., & Thompson, A. (2025). Context lineage assurance for non-human identities in critical multi-agent systems. arXiv:2509.18415.
- Wang, R., et al. (2025). Open challenges in multi-agent security: Towards secure systems of interacting AI agents. arXiv:2505.02077.
- International AI Safety Report 2026. arXiv:2602.21012.
- IMF. (2026). How agentic AI will reshape payments. IMF Staff Notes, 2026/004.
- Wooldridge, M., & Jennings, N. R. (1995). Intelligent agents: Theory and practice. The Knowledge Engineering Review, 10(2), 115–152.
- Foundation for Intelligent Physical Agents. (2002). FIPA ACL Message Structure Specification. Document SC00061G. http://www.fipa.org/specs/fipa00061/
- Microsoft. (2026). “A2A v1 Is Here: Cross-Platform Agent Communication in Microsoft Agent Framework for .NET.” Azure DevBlogs. https://devblogs.microsoft.com/agent-framework/a2a-v1-is-here-cross-platform-agent-communication-in-microsoft-agent-framework-for-net/
- ANP-Community. (2025). “Agent Network Protocol: W3C White Paper.” https://www.w3.org/submissions/2025/SUBM-ANP-20250501/
- Hicks, C., & Tuyls, K. (2025). Multi-agent systems research in the United Kingdom. AI Communications. https://content.iospress.com/articles/ai-communications/aic229003
- Alan Turing Institute. (2025). UK Multi-Agent Systems Symposium 2025 (UK-MAS). Event report. https://www.turing.ac.uk/events/uk-multi-agent-systems-symposium-2025-uk-mas
- Coral Protocol Team. (2025). Coral protocol: Open infrastructure connecting the internet of agents. arXiv:2505.00749.
- Zylos Research. (2026). “Agent Interoperability Protocols 2026: MCP, A2A, ACP and the Path to Convergence.” https://zylos.ai/research/2026-03-26-agent-interoperability-protocols-mcp-a2a-acp-convergence/
- SecureW2. (2026). “A2A Protocol Security: Authenticating Agent-to-Agent Communication.” https://securew2.com/blog/a2a-protocol-security