Agentic SystemsAdvanced

A2A: When Your Agent Needs Another Team’s Agent

Agent Cards, long-running tasks and artifacts, how A2A differs from MCP, and the honest test for when a plain function call is the better answer.

By Amit UpadhyayPublished 17 OctUpdated 28 Oct 20265 minArticle 4 of 16 in Agentic Systems

A procurement agent discovers a compliance agent from its Agent Card, delegates a task, answers a question, and receives an artifact that it treats as untrusted input.

On this page

The idea at a glance

The problem

When

An agent needs work done by another team’s agent that it cannot see inside

The obvious move

Wrapping the other agent in a tool call

Fails because

A tool call expects a quick answer, but this work takes minutes, may need to ask questions and returns several documents

The fix

The Agent2Agent protocol works by

Delegating a task over A2A, with discovery through an Agent Card, a status you can follow, and artifacts as the output

At the cost of

One more protocol to run and secure, and another model on the other side spending money on context you cannot see

The scenario every mode follows

“Assess vendor Acme GmbH for a €2M contract”

A procurement agent that needs a risk assessment from the compliance team’s agent
~40 assessments a week, 5–30 minutes each
claude-sonnet-5-5

Where the obvious approach breaks

20-minute assessments against a 60-second tool timeout

If you expose the compliance agent as a single blocking tool.

The call times out, and there is no way to ask the follow-up the compliance agent needs. Retrying starts the whole assessment again and pays for it twice.

Helps to know firstMCP integration

Two Teams, Two Agents, One Awkward Meeting

Your procurement agent needs a risk assessment, and the compliance team already has an agent that does exactly that. It runs on a different framework, in a different cloud, owned by people who won't give you its prompts or its tools. Someone suggests wrapping it in an MCP tool. That works until the assessment takes twenty minutes, needs a follow-up question halfway through, and returns three documents. Now your “tool call” is really a conversation between two systems, and a function signature is a poor fit for that.

Agent2Agent (A2A) is a protocol for that conversation. MCP connects an agent to tools and data. A2A connects an agent to another agent, treated as an opaque peer that you delegate work to. Google contributed it to the Linux Foundation, and it reached 1.0 in March 2026. InfoQ's 2026 trends report places agent-to-agent protocols among the innovators, so read this as a technology to understand now and adopt where the need is real.

Read this if

Different teams or companies own the agents that need to work together
You are wrapping an agent in a tool and it keeps not fitting
Someone at work has said you need “a multi-agent strategy” and you want to check

MCP and A2A Solve Different Problems

	MCP	A2A
Connects	An agent to tools and data	An agent to another agent
The other side is	A function you can inspect	An opaque peer with its own reasoning
Unit of work	A tool call	A task that can last a while and ask questions
Discovery	`tools/list`	An Agent Card
Typical boundary	Inside your system	Between teams or organisations

Most systems that use A2A use MCP as well. The compliance agent uses MCP to reach its own policy database, and A2A is how your agent reaches the compliance agent. Neither replaces the other.

The Core Ideas

Agent Card. A JSON document published at a well-known URL (/.well-known/agent-card.json) describing what the agent can do, how to reach it and how to authenticate. Cards can carry signatures, which matters once you stop trusting the network path.
Task. The unit of delegated work, with a status that moves over time. This is the big difference from a function call: a task can be running for an hour, or stop to ask for more input.
Message and Artifact. Messages carry the back-and-forth. Artifacts are the outputs, such as a finished report.
Transports. JSON-RPC 2.0 over HTTP(S), with gRPC and REST bindings, plus server-sent events for streaming and push notifications for long waits.


sequenceDiagram
    participant P as Procurement agent
    participant C as Compliance agent
    P->>C: GET agent-card.json
    C-->>P: Capabilities, endpoint, auth
    P->>C: Send a task, assess vendor Acme
    C-->>P: Working
    C-->>P: Input required, which region?
    P->>C: EU
    C-->>P: Completed, artifact risk-report.pdf

Version 1.0 was a breaking release, with a large refactor separating the application protocol from its transport mappings. If you built on 0.x, plan a migration. For example, the card moved from agent.json to agent-card.json back in 0.3, and 1.0 renamed fields (mediaType replaced mimeType) and replaced the separate part types with one Partmessage, which changed how parts are represented, so follow the spec's migration notes. The current release at the time of writing is 1.0.1.

When It Is the Wrong Tool

Be honest about this first, because the failure I expect to see is teams adopting a protocol for agents that could have been a function. Reach for A2A when you can answer yes to at least one of these:

Another team or company owns the agent, and you can't see inside it.
The work takes minutes or hours and may need to ask questions.
The two sides run on different frameworks or clouds and will keep changing independently.

If you own both agents, they share a codebase, and the call returns in seconds, use a function or an MCP tool. A multi-agentdesign inside one process doesn't need a network protocol at all. The other thing to weigh is cost: each hop can add model, network and orchestration cost on the other side, often reasoning over context you can't see, so measure what a peer actually does.

What Goes Wrong

⚠️ Common Mistakes

1. Trusting what the other agent says

Output from a remote agent is untrusted input, exactly like text from a web page. OWASP calls out Insecure Inter-Agent Communication as ASI07: use mutual authentication, verify signed cards, and allowlist which agents may delegate to which.

2. No timeouts on delegated tasks

A task can legitimately run for an hour, so a missing deadline looks just like a working agent. Set a deadline per task, and decide what happens when it passes.

3. Losing the trace at the boundary

When an answer is wrong, you need to follow it across both systems. Propagate trace context on every call, or debugging stops at the edge of your own service.

4. Cascades

A retry from agent A can trigger retries in B and C. OWASP lists Cascading Failures as ASI08. Put budgets and circuit breakers on every delegation, since the failure otherwise spreads to everything that trusts the first agent.

Designing a Good Agent Card

Your card is what other agents use to decide whether to call you, so write it like an API contract. List skills with clear names and descriptions, say what inputs each one needs, and give realistic examples. Vague descriptions cause the same problems as vague tool descriptions: wrong calls, or no calls at all. Keep skills narrow. An agent that claims to "help with compliance" tells a caller little, whereas "assess a vendor's data-processing risk, given a company name and region" can be chosen correctly.

Version your card, publish it behind authentication if it reveals internal capabilities, and sign it. Remember that 1.0 was a breaking change, so if you're using an SDK, pin its version, and check which protocol version your peers speak before you upgrade.

What I Would Do First

Check whether you have the problem. If you do, start with a single delegation across one team boundary, with a signed card, a deadline and shared tracing. Get that one working well before you add a second. The AG-UI protocol is worth a look if you also need agents to stream to a front end, but keep that decision separate from this one.

Decisions and trade-offs

The choices this rests on

Each choice has a reason and a point where it stops being right. The Test questions are built from these.

1
Use A2A when another team owns the agent and you cannot see inside it
The protocol exists for opaque peers that run for a while and ask questions. Inside one codebase, a function call does the same job with none of the overhead.
Stops being right when
You own both sides and calls return in seconds. Then use a function or an MCP tool.
2
Authenticate both sides, verify signed cards, and allowlist which agents may delegate
An Agent Card says what an agent claims to be. Without verification, anyone can publish one, which is why OWASP lists insecure inter-agent communication as ASI07.
Stops being right when
Never across a trust boundary.
3
Treat everything a remote agent returns as untrusted input
The other agent read pages you did not, and an injection can pass straight through its report into your decisions.
Stops being right when
Never for decisions with real consequences.
4
Set a deadline and a budget on every delegated task
A long task looks exactly like a stuck one, and a retry at one hop can multiply across the chain.
Stops being right when
The task is purely internal, cheap and has its own hard timeout.

In production

Running it once real traffic arrives

What to watch, what it costs at the scenario’s volume, and what to check first when something goes wrong.

What to watch

Tasks past their deadline
Shows a slow or stuck peer before your users do.
< 2%
Cost per delegated task
The other side is spending money too, and you may see only the invoice.
Stable
Traces that cross the boundary
Without them, debugging ends at your own service.
100%
Card verification failures
A failure may mean a key rotation or an impostor.
0 unexplained

What it costs

Your side40 tasks × ~$0.05 of orchestration calls$2/week

Peer side40 tasks × ~$1 of research and tool calls$40/week

Retry after a timeoutone repeated assessment+$1 each

TotalThe peer’s model usage dominates, so agree on budgets with its owners

These figures are illustrative. Ask the owning team what a task really costs before you automate calls to it.

When it breaks

Tasks sit in “working” for hours

CheckIs the peer healthy, and did your deadline fire?
FixCancel at the deadline and notify a person, rather than waiting

A signature check suddenly fails

CheckDid the peer rotate its keys?
FixConfirm through a separate channel before trusting a new key

An answer is wrong and nobody knows why

CheckDoes the trace continue into the peer?
FixPass trace context on every call, and agree on a shared format

In the real world

A delegation across two teams

A composite of early enterprise A2A pilots. Details are illustrative.

Before

Procurement wanted compliance checks in its workflow, and the compliance team would not expose its prompts or tools. A blocking tool call kept timing out.

What they built

Compliance published an Agent Card behind the company’s identity provider
Procurement delegated tasks with a deadline and followed their status
Reports came back as artifacts, treated as untrusted input
Trace context was shared across both systems

What changed

Assessments stopped timing out
Each team kept control of its own agent

The lessonThe protocol paid for itself at an organisational boundary. Inside one team, it would just have been extra work.

When not to use it

Reach for something else when

If you needUse instead

Agents in one codebase owned by one teamA function call or an in-process orchestrator

Giving an agent access to a tool or data sourceThe Model Context Protocol

Agents moving money with no human checksA person in the loop, since the payment protocols are still early

Check yourself

Two questions before you move on

Answer in your head first, then open the answer.

What makes a task different from a tool call?

A task has a status that changes over time, can run for a long while, and can stop to ask for more input.

Why treat a report from a trusted team’s agent as untrusted?

That agent read external content you did not see, and an injection can travel through its report into your decision.

Where this leads

Agent observability

Once work crosses systems, a trace is the only way to see what happened.

Next topic →

Next: See →

Sources

A2A agent-protocols multi-agent interoperability

← PreviousBuilding a Production Tool Registry Next →Harness Engineering: Everything Around the Model

Continue reading

All Agentic Systems articles →

Agentic Systems6 min

Agent Skills: Knowledge That Loads on Demand

Stop growing your system prompt. How SKILL.md folders and progressive disclosure work, how to write a description that fires, and when a skill beats a tool or an MCP server.

Agentic Systems5 min

Durable Agents and Sandboxing: Surviving the Crash

Checkpoints do not make a side effect safe. Idempotency keys, the interrupt replay trap, choosing a runtime, and the isolation and egress rules that contain generated code.