A2A

Defines the normative Layer 1 data model using Protocol Buffers (specification/a2a.proto) that declares protocol-agnostic structures including Task (stateful work units), Message (communication turns), AgentCard (agent metadata), Part (polymorphic content containers), Artifact (task outputs), and TaskState (lifecycle enums). This single source of truth ensures semantic consistency across all protocol bindings (JSON-RPC, gRPC, REST) and language-specific SDKs, eliminating data model drift between implementations.

Implements Layer 2-3 architecture that maps abstract RPC operations (SendMessage, SendStreamingMessage, GetTask, ListTasks, CancelTask, SubscribeToTask) to three concrete protocol bindings: JSON-RPC 2.0 over HTTP/SSE, gRPC over HTTP/2, and HTTP/REST with JSON. Each binding preserves the canonical data model semantics while adapting to protocol-specific transport mechanics, allowing agents to communicate regardless of their underlying protocol choice.

Implements an automated documentation build system (MkDocs-based) that generates human-readable specification, tutorials, and API reference from the canonical proto definition and markdown sources. The system maintains documentation versioning, generates schema artifacts for different protocol bindings, and produces specification PDFs for offline reference, ensuring documentation stays synchronized with the protocol specification.

Implements CI/CD workflows that synchronize proto definitions across the main A2A repository and language-specific SDK repositories (a2a-python, a2a-go, a2a-js, a2a-java, a2a-dotnet), automatically triggering SDK regeneration and testing when the specification changes. This ensures all SDKs stay in sync with the canonical specification without manual coordination.

Establishes a formal governance model with a Technical Steering Committee (TSC) that oversees protocol evolution, reviews proposals, and manages the contribution process. The governance structure (documented in docs/community.md) defines how protocol changes are proposed, reviewed, and approved, ensuring decisions are made transparently with input from the community and major stakeholders.

Defines AgentCard as a standardized metadata structure that agents publish to advertise their identity, capabilities, supported protocols, authentication requirements, and operational constraints. AgentCard enables dynamic agent discovery without requiring centralized registries — agents can advertise themselves via HTTP endpoints, DNS records, or service meshes, allowing other agents to discover and invoke capabilities at runtime.

Implements a complete task state machine (defined in TaskState enum) that tracks work from creation through completion or cancellation, with support for long-running operations via streaming responses and asynchronous notifications. Tasks are first-class protocol objects with unique identifiers, allowing agents to reference, monitor, and cancel work across network boundaries. Streaming operations (SendStreamingMessage) enable real-time progress updates and intermediate results without polling.

Provides an Extensions system (documented in specification) that allows agents to define custom RPC operations and protocol-specific features beyond the core A2A operations, using a plugin-like mechanism. Extensions are declared in AgentCard and negotiated during agent discovery, enabling agents to expose domain-specific capabilities (e.g., custom tool invocation, proprietary streaming formats) while maintaining compatibility with standard A2A clients.

Implements a security layer that supports multiple authentication schemes (declared in AgentCard) including mTLS for gRPC, bearer tokens for REST/JSON-RPC, and custom authentication handlers. The protocol defines how agents advertise their authentication requirements and how clients negotiate credentials during discovery, enabling secure agent-to-agent communication across untrusted networks without requiring a centralized authentication service.

Generates language-specific SDKs (Python, Go, JavaScript, Java, .NET) from the canonical a2a.proto specification using protobuf code generators, with each SDK providing idiomatic bindings for the target language. The generation pipeline (documented in development infrastructure) ensures all SDKs maintain semantic consistency with the protocol specification while providing language-native APIs (async/await in Python, goroutines in Go, promises in JavaScript).

Provides integration guides and reference implementations showing how to adapt existing agent frameworks (LangChain, AutoGen, CrewAI, etc.) to become A2A-compliant. Integration patterns include wrapping framework agents as A2A servers, implementing AgentCard advertisement, and mapping framework-specific task models to A2A Task objects, enabling existing agent ecosystems to interoperate without rewriting core logic.

Defines how A2A and MCP (Model Context Protocol) work together as complementary standards: A2A handles agent-to-agent communication and task orchestration, while MCP handles LLM-to-tool communication and context management. The specification documents integration patterns showing how agents can use MCP servers as tools and how MCP clients can invoke A2A agents, enabling layered architectures where agents coordinate via A2A while LLMs invoke tools via MCP.

Implements a protocol versioning strategy (documented in Protocol Version History) that allows the A2A specification to evolve while maintaining backward compatibility with existing implementations. Version information is embedded in protocol messages and AgentCard metadata, enabling agents to negotiate protocol versions during discovery and gracefully handle version mismatches through fallback mechanisms.