Agent Interoperability — the A2A Protocol

The problem: agents behind walls essential

Picture the wall you keep running into. Your support agent needs a shipping estimate, so it needs the logistics team's agent. But that agent lives in another team's repo, on another framework, deployed behind another company's login. You can't pip install it, you can't read its code, and you certainly can't redeploy it when it changes. Every integration you've done so far assumed you owned both ends; this is the first time you don't. That is the wall A2A is built to knock a door through.

Here's why your usual move fails. Your instinct is to wrap the other agent as a "tool" and call it like a function — the pattern you learned for MCP. But a tool is a thing you invoke: you pass arguments, it computes, it returns in seconds, and you own it. The other agent is a thing you delegate to: it reasons on its own, keeps its own state, may take minutes to finish, may pause to ask you a clarifying question, and lives outside your control. Modeling that as a synchronous function call is the single most common mistake here, and it breaks the moment the work runs long or the peer talks back. The mismatch is the whole reason A2A is a separate protocol rather than "just another tool."

The plain idea: A2A (Agent-to-Agent) is a shared language for autonomous agents to find each other and hand off work across boundaries — different teams, different frameworks, different companies. Think of it less like an API and more like the etiquette two professionals from different firms use when they collaborate: they introduce themselves and their skills, one hands the other a project, the worker reports progress, and eventually delivers. Nobody has to have merged codebases first. Your agent is great at its job — A2A is how it borrows an ability it will never own, from a peer it will never operate. That's A2A (introduced by Google in 2025, now under open governance); the diagram below fixes the one distinction everything else builds on — down to a tool versus sideways to a peer.

A2A vs MCP — complementary, not competing essential

The fastest way to get A2A wrong is to think it competes with MCP. They sound similar — both are protocols, both let your agent reach outside itself — so people assume they'll pick one. Get this framing wrong and you'll either bolt A2A onto problems that only needed a tool, or try to squeeze a genuine peer agent into a tool schema and fight the protocol forever. So spend a moment here: it's the mental model the rest of the chapter leans on.

The distinction in one image: MCP points down, A2A points sideways. MCP connects your agent down to the tools, data, and resources it uses — things you invoke and own, like a database query or a file read. A2A connects your agent sideways to another agent — an autonomous peer, often across an org boundary, that you delegate to rather than call. Down is "reach into something I control"; sideways is "hand work to a colleague I don't." Once you feel that geometry, the table below is just the same idea broken into five rows.

The analogy that makes it stick: MCP is an API your program calls — you send a request, you get a response, you're in charge of the whole transaction. A2A is a colleague you hand a project to — you brief them, they go off and work autonomously, they check in, and they come back with a deliverable on their own schedule. You don't micromanage a colleague's internal steps the way you'd control an API call, and you can't brief an API the way you'd brief a colleague. The common mistake is treating the colleague like an API (expecting an instant, controlled return) — that's exactly what breaks. Read each row as the same "invoke vs delegate" split seen from a different angle: what's on the other side, how you interact, and where the boundary sits.

Core concepts essential

For two strangers to work together, they need a shared vocabulary — and so do agents. If your agent and a vendor's agent were built by teams who never met, how does yours even know the other exists, what it can do, or how to ask? It can't guess, and it can't read the other's mind. A2A solves this the way humans do when they collaborate across companies: with a small set of agreed-upon nouns that both sides understand. Learn these four and you can read almost any A2A interaction, because everything that happens is expressed in terms of them.

Why these four and not twenty: notice they map cleanly onto how a real handoff works. The Agent Card is the business card and résumé — who I am and what I can do. The Task is the project you hand over — a unit of work with a beginning, a middle, and an end. The Message is a turn in the conversation about that project — a question, an update, a clarification. The Artifact is the finished deliverable handed back. The common trap is collapsing Task and Message into one thing ("I sent it a request and got a reply") — but a single Task usually spans many Messages over time, because the work runs long. Keep the Task as the durable container and the Messages as the turns inside it, and the lifecycle in the next section will feel obvious. Here's the shared vocabulary, one row each.

A2A gives agents a shared vocabulary for discovery and delegation. Four pieces carry most of it.

Lab I2.1 · A delegation flow intermediate

You now know the nouns; this is the verb. Concepts on their own are inert — the payoff is seeing them move. This section is the one you'll replay in your head every time you design an A2A integration, because it's the actual choreography of one agent getting real work out of another it doesn't own. If you can narrate this flow from memory, you understand A2A.

The shape to hold onto has four beats: discover → delegate → stream → deliver. First the client discovers the peer by fetching its Agent Card — the "what can you do and how do I reach you?" step. Then it delegates by submitting a task. Then — and this is the beat beginners skip — the peer streams progress back while it works, because the job takes real time. Finally it delivers the artifact and the task reaches a terminal state. The mistake to avoid is imagining beats two and four glued together with nothing in between (send request, get answer). That's a tool call, not a delegation; the streaming middle is exactly what makes this A2A and not MCP.

A human analogy keeps it concrete: it's a supervisor handing a job to a specialist in another department. You look up who does this kind of work (discover), you brief them and hand it over (delegate), they ping you with "30% done… 80% done…" and occasionally ask a clarifying question (stream, including the input-required pause where the task can turn around and ask you something), and then they drop the finished report on your desk (deliver). It's the supervisor topology from L1/M1 — but stretched across a network boundary, so the "handoff" is a wire protocol instead of a function call. Read the diagram top-to-bottom as time passing, and watch which direction each arrow points.

Walk the lifecycle: a client agent discovers a remote agent, delegates a task, receives streamed progress, and gets the result. This is the supervisor topology (L1/M1) stretched across a network boundary.

A2A vs in-process multi-agent (M1/M2) intermediate

Here's a real fork you'll hit on the job. You already build multi-agent systems with CrewAI and AutoGen — several agents cooperating inside one process. So a natural question, and a genuinely load-bearing one for your architecture, is: when a task needs another agent, do you add it to your crew, or reach for A2A? Choose wrong and you either drag a whole protocol into a problem that a function call would have solved, or you try to pull an agent you don't operate into your own runtime and discover you can't. This section is the decision rule.

The plain test is ownership, not capability. Both approaches coordinate multiple agents; the difference is who controls them. If every agent is yours — same codebase, same framework, same deployment you can push a fix to — keep them in-process: it's simpler, faster, and you can refactor freely. The moment an agent is built by another team, runs on another stack, or is operated by someone you can only reach over the network, you've crossed a boundary that in-process coordination can't span, and that's A2A's job. A useful gut-check: could I redeploy this agent myself if it broke? If yes, it's a crew member; if no, it's an A2A peer.

The reassuring part — and the thing most people miss: A2A doesn't replace the coordination patterns you already know, it stretches them across the boundary. The supervisor and network topologies from L1 work exactly the same; a remote A2A agent can be a "member" of your CrewAI crew, and your orchestration logic doesn't change. A2A is just the wire protocol that makes a member reachable when it lives in someone else's building. So this isn't a rival framework to learn — it's the adapter that lets your existing multi-agent design phone across an org line. Read the table as a boundary detector: left column = everything under your roof, right column = the first time something isn't.

You already coordinate multiple agents with CrewAI and AutoGen. When do you need A2A instead?

Trust, auth & reliability across the boundary intermediate

This is the section that keeps A2A systems out of the incident channel. The demo where two agents happily delegate to each other is the easy 80%; the hard 20% — the part that decides whether you can ship this to production — is that you're now taking instructions and data across a line you don't control, from an actor that thinks for itself. Skip this and you've built a beautiful pipe that leaks credentials, acts on poisoned output, and hangs forever when the peer goes down. Every concern here is one you've met before; the point is that crossing the boundary sharpens each one.

The reframe that makes the risks obvious: stop thinking of the remote agent as a helpful colleague and start thinking of it as an untrusted, autonomous remote dependency. "Remote" means it can be slow, down, or fail mid-task — so it needs the same timeouts, retries, and circuit breakers as any network call (A6, O3). "Untrusted" means its output is hostile input until proven otherwise — an artifact can carry prompt injection exactly like a tool result or a retrieved document (T1), so you validate before you act. And "autonomous" is the twist a plain API doesn't have: it reasons on its own, so it might be adversarial, compromised, or simply mistaken in ways a static endpoint never is. The common mistake is letting the friendly "peer" framing lull you into trusting it more than you'd trust a random URL — trust it less, because it's smarter.

Concretely, the boundary turns four familiar knobs up to eleven. Authentication: you're handing credentials to a service you don't run, so scope them to the single task and nothing more (least privilege). Data exposure: delegating sends your data across the line, so decide deliberately what's safe to share and mind residency and privacy (O4). Cost and loops: agents calling agents can fan out expensively or even loop, so bound the depth and spend (M2). And output trust: keep your own safety gate (L5) in front of anything you do with what comes back. Read the table below as a checklist you run before the first delegation ships, not a postmortem you write after — each row is a concern you already respect, now amplified because the other side is autonomous and outside your walls.

Calling an agent you don't control raises every concern that calling your own tools does — amplified, because the other side is autonomous and outside your walls.

Common pitfalls advanced

Every idea in this chapter has a matching way to get it wrong, and these are the six you'll actually meet. Think of this table as the negative image of everything above: each pitfall is what happens when one of the lessons doesn't land. Reading them together is worth more than the sum of the parts, because the failures share a spine — they all come from forgetting that a peer agent is autonomous, remote, and untrusted. Spot that root and every fix follows.

Watch how they cluster. The first two are identity mistakes — reaching for A2A when in-process would do (over-engineering a boundary that isn't there), and modeling a peer as a synchronous function (forgetting tasks run long and stream). The next three are trust mistakes — believing an artifact without validating it, calling a remote with no timeout or retry, and handing over credentials broader than the task needs. The last is a systems mistake — letting agent-to-agent calls fan out or loop without a cap. The honest truth is that none of these fixes are exotic; they're the resiliency (A6, O3), safety-gating (L5, T1), and cost-bounding (M2) habits you already have, simply applied across a wire. Read each row as "the lesson, and what it costs to skip it."

Exercises advanced

card = {
    "name": "logistics-agent",
    "endpoint": "https://vendor.example/a2a",
    "skills": ["route-planning", "eta-estimate"],
    "auth": "bearer",
}
def can_do(card, skill):
    if skill in card["skills"]:
        return f"yes -> POST {card['endpoint']} (auth: {card['auth']})"
    return f"no -- {card['name']} does not advertise '{skill}'"

print(can_do(card, "eta-estimate"))    # yes -> POST ...
print(can_do(card, "invoice-audit"))   # no -- not advertised

ALLOWED = {
    "submitted":      {"working", "failed"},
    "working":        {"input-required", "completed", "failed"},
    "input-required": {"working", "failed"},
    "completed":      set(),   # terminal
    "failed":         set(),   # terminal
}
def transition(state, nxt):
    if nxt in ALLOWED[state]:
        return nxt
    raise ValueError(f"illegal {state} -> {nxt}")

s = "submitted"
for nxt in ["working", "input-required", "working", "completed"]:
    s = transition(s, nxt)
    print("->", s)
try:
    transition("completed", "working")   # terminal, must raise
except ValueError as e:
    print("blocked:", e)

REGISTRY = [
    {"name": "a", "skills": ["translate"], "auth": "none"},
    {"name": "b", "skills": ["route-planning"], "auth": "oauth2"},
    {"name": "c", "skills": ["route-planning"], "auth": "bearer"},
]
def discover(registry, skill, supported_auth):
    hits = [c for c in registry
            if skill in c["skills"] and c["auth"] in supported_auth]
    if not hits:
        return None
    return hits[0]["name"]   # first match; could rank on latency/cost

print(discover(REGISTRY, "route-planning", {"bearer", "none"}))  # c
print(discover(REGISTRY, "route-planning", {"none"}))            # None
print(discover(REGISTRY, "translate", {"none"}))                 # a

def remote_agent(task):
    # a long-running peer that streams progress, then an artifact
    yield {"type": "status", "state": "working", "pct": 30}
    yield {"type": "status", "state": "working", "pct": 80}
    yield {"type": "artifact", "name": "route.json",
           "data": {"stops": task["stops"], "eta_min": 42}}
    yield {"type": "status", "state": "completed"}

def delegate(task):
    artifacts, final = [], None
    for ev in remote_agent(task):
        if ev["type"] == "status":
            print("update:", ev.get("state"), ev.get("pct", ""))
            final = ev["state"]
        elif ev["type"] == "artifact":
            artifacts.append(ev)
    return final, artifacts

state, arts = delegate({"stops": ["A", "B", "C"]})
print("final:", state, "artifacts:", [a["name"] for a in arts])

def route(target):
    # target: dict describing what we're connecting to
    if target["kind"] == "function" or target["kind"] == "resource":
        return "MCP", "a capability you invoke and own"
    if target["kind"] == "agent" and target["autonomous"]:
        return "A2A", "an autonomous peer you delegate a task to"
    return "MCP", "default: treat as an owned capability"

for t in [
    {"kind": "function", "name": "get_weather"},
    {"kind": "agent", "autonomous": True, "name": "vendor-logistics"},
    {"kind": "resource", "name": "s3-doc"},
]:
    proto, why = route(t)
    print(f"{t['name']:20} -> {proto:4} ({why})")

import time

def guarded_delegate(card, skill, token, deadline_s=2, max_retries=2):
    # 1) trust: skill must be advertised and auth must match
    if skill not in card["skills"]:
        return {"ok": False, "reason": "skill not advertised"}
    if card["auth"] == "bearer" and not token:
        return {"ok": False, "reason": "missing bearer token"}
    # 2) reliability: bounded retries against a flaky peer
    attempt = 0
    while attempt <= max_retries:
        attempt += 1
        ok, artifact = _call_peer(card, skill, fail_first=1, attempt=attempt)
        if ok:
            return {"ok": True, "attempt": attempt, "artifact": artifact}
    return {"ok": False, "reason": "peer unavailable after retries"}

def _call_peer(card, skill, fail_first, attempt):
    time.sleep(0)                       # stand-in for network I/O
    if attempt <= fail_first:
        return False, None              # simulate a transient failure
    return True, {"skill": skill, "value": "OK"}

card = {"name": "partner", "skills": ["audit"], "auth": "bearer"}
print(guarded_delegate(card, "audit", token="t0k"))   # ok after retry
print(guarded_delegate(card, "audit", token=""))       # blocked: no token
print(guarded_delegate(card, "ship", token="t0k"))     # blocked: not advertised

Knowledge check check yourself