Agent Engineering6 min readUpdated October 28, 2026

A2A Protocol Explained: Agents Talking to Agents Over a Standard Contract

Your agent becomes a JSON-RPC service with a discovery card. Any client, any framework, any vendor. That is the whole point.

A2A turns an agent into a standard JSON-RPC endpoint with a discovery card. The protocol matters more than the frameworks on top of it.

The core idea is frontend-free: an agent is a service, so call it like one. The discovery card describes what the agent can do and how to authenticate. A client reads the card, posts a task, and receives results as artifacts.

See How We Work

In This Guide

The insight behind the protocol

The core idea is frontend-free: an agent is a service, so call it like one. The discovery card describes what the agent can do and how to authenticate. A client reads the card, posts a task, and receives results as artifacts.
The core idea is frontend-free: an agent is a service, so call it like one. The discovery card describes what the agent can do and how to authenticate. A client reads the card, posts a task, and receives results as artifacts. What I like about this over ad-hoc integrations is the same thing I like about any standard: it removes the negotiation from every handshake. Teams ship agents that other teams can adopt without meetings.

What the contract looks like

Two surfaces. The Agent Card at a well-known path: name, capabilities, streaming support, auth requirements. The RPC surface: usually POST to a single path, accepting task requests and returning task artifacts. Streaming means artifacts arrive incrementally so a UI can show progress. No framework is mandated.
Two surfaces. The Agent Card at a well-known path: name, capabilities, streaming support, auth requirements. The RPC surface: usually POST to a single path, accepting task requests and returning task artifacts. Streaming means artifacts arrive incrementally so a UI can show progress. No framework is mandated. I have stood up A2A servers with a hundred lines of framework code and no vendor CLI.

Where it is still rough

It is early. The Console integrations around Google's platform expect ADK-shaped apps, and extensions like the LangChain one are marked experimental: some platform features refuse agents served over A2A, and trace views can stay empty. The core serving contract works well. The surrounding platform polish is where the rough edges live.
It is early. The Console integrations around Google's platform expect ADK-shaped apps, and extensions like the LangChain one are marked experimental: some platform features refuse agents served over A2A, and trace views can stay empty. The core serving contract works well. The surrounding platform polish is where the rough edges live. Plan for API surface, not for console dashboards.

How to adopt without betting the roadmap

Serve your agent over both A2A and plain REST. The bulk of your logic is a thin adapter either way. That dual path costs a day of work and removes the protocol roulette. If the ecosystem consolidates around A2A, you are done. If something else wins, the adapter changes, not the agent.
Serve your agent over both A2A and plain REST. The bulk of your logic is a thin adapter either way. That dual path costs a day of work and removes the protocol roulette. If the ecosystem consolidates around A2A, you are done. If something else wins, the adapter changes, not the agent.

5 Tips to Get Started

1

If you control both sides of the integration, plain REST can be enough. Use A2A when third parties or internal teams need to discover and call each other's agents.

2

The agent card (/.well-known/agent-card.json) is your agent's front door. Keep capabilities and auth requirements in it truthful.

3

Streaming in A2A is incremental task artifacts, not chat bubbles. Design your UI to show steps, not typing text.

4

You do not need Google's CLI to serve A2A. A small uvicorn app with JSON-RPC at one path plus a discovery card is a compliant server.

5

Treat A2A as the integration contract between teams, not a framework choice. Your internals stay yours.

Ready to Stop Worrying About Infra?

Knowledge is the first step. Get a free 1-hour diagnostic and see where your infrastructure leaks time, money, and focus.

Sources & References

roqy.io cites authoritative sources including engineering blogs, vendor documentation, industry surveys, and academic research to ensure accuracy.

Related Guides

Chatbot vs AI Agent: The Difference That Decides If Your Users Come Back

A chatbot answers. An agent acts. See the architectural difference, what it costs to build each, and which one keeps users on your SaaS.

AI Agent Development Cost in 2026: Full Build Budget Breakdown

What it actually costs to build and run a production AI agent: build fees, model spend, eval infrastructure, and monthly maintenance. Real numbers.

How to Add an AI Agent to Your SaaS Product (2-Week Production Plan)

A 2-week plan to add a production AI agent to your SaaS: pick one workflow, wire tools to your API, add permissions and eval, ship. No rewrite.

MCP vs A2A: Which Protocol Layer Does Your Agent Need?

MCP connects agents to tools and data. A2A connects agents to each other. See where each fits in a SaaS architecture and which one to build first.

R

Ron Cohen — DevOps engineer & founder, roqy.io

Content reviewed by the roqy.io team. Our guides are based on publicly available data and cited sources above.

Disclaimer: This content is for informational and educational purposes only. It does not constitute professional advice or a guarantee of specific results. Infrastructure needs vary by team, stack, and stage. Consult a qualified engineer for advice tailored to your situation.

Frequently Asked Questions

What is A2A in one paragraph?

Agent2Agent is a protocol where agents expose themselves as services: JSON-RPC at a fixed endpoint, a discovery card describing capabilities, and streaming results as task artifacts. Any client that speaks the protocol can invoke your agent without knowing which framework or model is inside.

Is A2A tied to Google?

No. Google's agents-cli vendors one nice implementation, but the protocol is an open contract. You can self-host an A2A server on your own VPS with a small FastAPI app. The card and the endpoints are the contract.

Does A2A replace MCP?

They solve different layers. MCP connects an agent to tools and data. A2A connects agents to each other. Many agent stacks will use both: MCP inside, A2A at the boundary.

What does a minimal A2A deployment need?

A container that serves JSON-RPC at one route, a discovery card at /.well-known/agent-card.json, and streaming support if your model supports token streaming. That plus your auth policy is production shape.

Why should a SaaS founder care now?

Because agent integrations are becoming a client-side staple. A product that can say "our agent speaks A2A, call it from your stack" wins deals that a bespoke dropdown of integrations cannot.

Get the DevOps Ecosystem Behind You

One accountable engineer. Full platform behind him. Month-to-month, no lock-in.

See How It Works