localmTUTS
FollowFollowSubscribe
Video Lesson·6 mins

Why Agent2Agent Protocol?

Explore the motivation behind A2A — how it solves the interoperability problem and complements MCP.

Why Agent2Agent Protocol? · 6 mins
Instructor:Welcome back to LocalM Tuts. I am Nilay Parikh. This is Lesson 2 of 16 — Why Agent2Agent Protocol? In this previous lesson we introduced A2A — protocol, the N square integration problem and the course road map. If you are watching, this is a stand alone video. Find the complete course list link below following along with our tutorial site. Link is visible. If you are mainly here for code practical implementation, which starts in Lesson 5 — building your first A2A agent and between the less than 8 and
Instructor:13 the walk through of 6 framework. But we recommend this foundation lessons first. They explain the design decision and you will encounter in every coding session. Right now we have tool calling where the model invokes functions directly, and we have MCP — the Model Context Protocol — which connects the model to structured data sources and tools. But neither of this solve agent to agent communication. Tool calling is synchronous and one directional. MCP is about connecting to data and tools, not to other
Instructor:autonomous agents. Let me walk through what A2A standardizes. The raw REST API to not first the message format A2A defines Messages with typed Parts such as text, files, structured data, etc. Second — streaming. A2A uses SSE, Server-Sent Events, built into the protocol. So you get a real time task update without building your own streaming infrastructure. Third — discovery. Every A2A agent publishes the Agent Card at the well-known URL. This JSON document describes the agent's skills,
Instructor:capabilities, authentication requirement, another region this part to know what the agent can do. Fourth — the lifecycle. A2A defines the state machine submitted, working input required, completed, failed, canceled. Every agent knows the same lifecycle contract. The 5th authentication — A2A supports OAuth 2.0, OIDC, API keys and mutual TLS out of the box You can declare the authentication requirement in your Agent Card and the client will honour it. A2A is built on 5 core design values. Agentic — agents are
Instructor:autonomous peers, not passive tools. Composable. Any agent can call any other agent opaque. Callers do not need to know the agent's internals. Enterprise-ready with built-in streaming, authentication, push notifications, extensions, etc., and open — Apache 2.0 license, the Linux Foundation governance, and of course its completely vendor neutral. Where does A2A fit in this stack? Think of it this way — at the bottom you have models such as like in our example Phi-4, Kimi K2 Thinking. Qwen. Above that we
Instructor:have frameworks such as ADK, LangGraph, CrewAI, Microsoft Agent Framework, OpenAI Agents SDK, Claude Agent SDK, then protocol. A2A connects Agents horizontally and MCP connects Agents 2 tools vertically. On the top of the protocol set the orchestration. Any framework can orchestrate multi agent workflows and activity top your user facing applications. A2A was Originally proposed by Google in April 2025. As an open open protocol for agent interoperability, it quickly gain industry support and
Instructor:was transferred to the Linux Foundation for the neutral governance. The current specification in RC 1.0 with this 3 protocol bindings: JSON-RPC 2 point O, HTTP/gRPC, and HTTP+ JSON+REST. In this course, we use JSON-RPC binding. It's the most common in the ecosystem. One important thing — A2A does not run your agents. It does not choose your model or replace MCP. It's a purely a communication protocol. Think think of it like an HTTP for agent. You do not need to know the implementation, just the contract.
Instructor:Thanks for watching this lesson on LocalM Tuts. In the next lesson, we will deep dive into A2A's architecture, agent card messages, task state machines, SSE streaming, JSON-RPC methods. You can find the next video in the A2A Protocol course playlist. See you there.
Learning Objectives4
  • Quantify the N² integration scale problem
  • Compare REST API integration vs. A2A protocol approach
  • Understand A2A's five design values
  • Map the A2A agent stack layers
Q&A

Q & A

Q

How does A2A differ from MCP (Model Context Protocol)?

MCP connects a single model to tools and data sources. A2A connects two or more autonomous agents — each potentially running different models — allowing them to discover each other and delegate tasks across organizational boundaries.

Q

Why can't agents just call each other's APIs directly?

They can, but without a common protocol you need custom integration for every pair of agents. A2A provides a standard discovery mechanism (Agent Card), task format, and streaming contract so any A2A-compliant agent can talk to any other.

Q

Is A2A tied to Google or any specific cloud provider?

No. A2A was initiated by Google but is now governed by the Linux Foundation under an Apache 2.0 license. It is completely vendor-neutral. In this course we use GitHub Models, Azure AI Foundry, and Foundry Local — no Google Cloud required.

Q

Can I use A2A with frameworks not covered in this course?

Absolutely. A2A is framework-agnostic. Any language or framework that can serve HTTP and handle JSON-RPC 2.0 can implement an A2A server. The spec also supports gRPC and HTTP+JSON/REST protocol bindings.