- Type
- Open agent interoperability protocol
- Introduced by
- Google (April 2025)
- Governance
- Linux Foundation (donated June 2025)
- Transport
- JSON-RPC 2.0, gRPC, HTTP+JSON
- Key concept
- AgentCard capability discovery
- Related
- Model Context Protocol, Multi-agent systems
- Type
- Open agent interoperability protocol
- Introduced by
- Google (April 2025)
- Governance
- Linux Foundation (donated June 2025)
- Transport
- JSON-RPC 2.0, gRPC, HTTP+JSON
- Key concept
- AgentCard capability discovery
- Related
- Model Context Protocol, Multi-agent systems
The Agent2Agent Protocol (A2A) is an open communication standard that allows autonomous AI agents to discover, authenticate, and collaborate with one another regardless of the framework, vendor, or platform on which each agent was built. It was introduced by Google in April 2025 and donated to the Linux Foundation in June 2025, where it is maintained as a vendor-neutral project with backing from more than 150 organisations. A2A addresses a practical gap in enterprise AI: while a single agent can call tools and models, coordinating several specialised agents built by different teams requires a shared language for delegation, status updates, and result exchange.
Design goals
A2A treats each agent as an opaque service. One agent does not need to know the internal reasoning, prompts, or model weights of another; it only needs a standard way to describe what it can do and to hand off work. This "opaque agent" philosophy distinguishes A2A from tighter integrations that assume a shared codebase. The protocol is designed to complement, rather than replace, the Model Context Protocol (MCP), which standardises how a single agent connects to tools and data. In a common pattern, MCP governs the vertical connection between an agent and its resources, while A2A governs the horizontal connection between peer agents.
How it works
An A2A server publishes an AgentCard, a machine-readable document that declares the agent's identity, skills, supported input and output formats, and authentication requirements. A client agent retrieves the AgentCard, selects a suitable partner, and initiates a task. Communication uses JSON-RPC 2.0 by default, with optional gRPC and HTTP+JSON bindings for different performance and tooling needs.
Interactions are organised around a task lifecycle. A client submits a task with an instruction and any required context; the remote agent moves the task through states such as submitted, working, input-required, and completed. Because some agent tasks run for minutes or longer, A2A supports streaming updates through server-sent events and asynchronous push notifications, so a long-running task does not require the client to hold an open connection. Results are returned as structured artifacts, which may include text, files, or richer data payloads.
The following table summarises the two protocols most often deployed together.
| Aspect | Model Context Protocol (MCP) | Agent2Agent (A2A) | | --- | --- | --- | | Primary axis | Agent to tools and data | Agent to agent | | Unit of interaction | Tool call | Delegated task | | Discovery | Tool/resource listing | AgentCard | | Typical role | Give one agent capabilities | Coordinate many agents |
Adoption and ecosystem
Following its launch, A2A gained support from major cloud providers and enterprise software vendors, and the move to Linux Foundation stewardship was intended to reassure adopters that no single company controls the specification. Educational material, reference servers, and software development kits in several languages have accelerated experimentation. The protocol is frequently discussed alongside emerging questions of agent identity, trust, and security, since allowing agents to delegate work across organisational boundaries introduces new authentication and auditing requirements that the specification continues to refine.
As Malaysian enterprises move from experimental chatbots toward production agent systems, interoperability standards such as A2A become relevant to how banks, telcos, and government agencies stitch together AI services from multiple vendors. Institutions like Maybank, CIMB, and Public Bank increasingly run AI initiatives that span internal teams and external technology partners, and a shared delegation protocol reduces the integration cost of connecting, for example, a customer-service agent to a separate fraud-checking agent.
The Malaysia Digital Economy Corporation (MDEC) and the National AI Office, established under the MyDigital agenda, have emphasised standards-based, interoperable digital infrastructure as a way to avoid vendor lock-in across the public sector. Open protocols governed by neutral bodies such as the Linux Foundation align with this preference and lower the barrier for local system integrators to build multi-vendor solutions.
For Malaysian technology firms and the wider MRANTI and Cyberjaya ecosystem, A2A offers a way to expose home-grown agents, including those built on local large language models such as MaLLaM and ILMU, to a global ecosystem of interoperable agents. This could allow a Malaysian language or compliance agent to be composed into larger international workflows.
Security and governance considerations remain important. Cross-agent delegation touches on data-protection obligations under Malaysia's Personal Data Protection Act (PDPA) and on cybersecurity guidance from the National Cyber Security Agency (NACSA), particularly where agents exchange personal or financial data across organisational boundaries. Adoption in regulated sectors is therefore expected to pair the protocol with strict authentication and audit logging.