Practice. MCP for Tools, A2A for Agents¶

Many teams mix up two different problems too early:

• how to connect tools and external systems;
• how to organize collaboration between multiple agents.

Because of that, MCP and A2A start to look interchangeable. In reality, they belong to different architectural levels.

1. The Short Rule¶

If you want the shortest version:

• MCP is for working with tools, resources, and adapters;
• A2A is for exchanging tasks, context, and results between agents.

In other words, one protocol is mainly about agent-to-tool, while the other is about agent-to-agent.¹²

2. When You Almost Certainly Need MCP¶

MCP is useful when you have one or more external capabilities that need to be connected systematically:

• document search;
• CRM;
• helpdesk;
• internal APIs;
• file resources;
• knowledge bases;
• execution sandboxes.

In that situation, the main goal is not to "build a society of agents," but to:

• standardize the contract;
• separate adapters from the core runtime;
• simplify policy checks;
• centralize logging, auth, and isolation.

That is where MCP fits naturally.

3. When You Actually Need A2A¶

A2A makes sense when you no longer just have tools, but truly distinct agents with separate responsibility:

• a coordinator;
• a researcher;
• an analyst;
• an executor;
• a domain specialist.

And they need to:

• hand tasks to each other;
• delegate work;
• exchange status;
• return results not as tool payloads, but as the work product of another agent.

That means A2A appears not where you need "one more adapter," but where real agent boundaries already exist in the system.

3.1. A2A Needs Governance, Not Just a Handoff Protocol¶

If one agent can hand a task to another agent, the platform must govern not only the message but also trust between operational roles. Otherwise A2A quickly becomes an opaque delegation chain where nobody can explain who was allowed to act, which policy applied, or who owns the result.

A minimal governance contract for A2A should record:

• the identity of the calling agent and the executing agent;
• the boundaries and lifetime of delegated authority;
• capability discovery: which roles an agent may discover and call;
• an audit trail for the handoff, intermediate status, and final result;
• policy checks before delegation and before external side effects.

The simple production test is this: if an incident review cannot reconstruct which agent delegated what to whom, under which policy, and with which scope, the A2A contour is not production-ready yet.

The extended A2A handoff trust contract should be even more concrete:

• agent identity: every handoff participant has a stable agent id, owner, and operational role;
• delegation chain: the delegation record preserves the original initiator, intermediate agents, and final executor;
• allowed collaboration graph: the platform explicitly defines which agent roles may call each other;
• inter-agent authorization: the receiving agent checks not only the message, but also whether the caller is allowed to request that action;
• policy inheritance: the downstream agent inherits the constraints of the original request instead of receiving broader freedom;
• non-repudiation: the handoff is signed or otherwise tied to trace/evidence so a participant cannot deny the step later;
• failure attribution: telemetry separates initiator error, executor error, policy denial, tool failure, and external-environment unavailability.

That contract turns A2A from a transport between agents into a governed collaboration graph. Without it, a multi-agent system may look distributed, but it will still be investigated like a black box.

A reviewable A2A trust and delegation artifact can look like this:

a2a_trust_delegation:
  remote_agent_id: incident.coordinator.v2
  remote_agent_owner: sre-platform
  trust_tier: constrained_internal
  allowed_tasks:
    - collect_incident_context
    - draft_status_update
  forbidden_tasks:
    - customer_notification_without_approval
    - production_change_without_gate
  delegation_depth: 1
  context_sharing_policy: minimal_relevant_context_only
  memory_sharing_policy: no_profile_memory_write
  tool_access_via_remote_agent: incident_read_tools_only
  approval_propagation: original_approval_constraints_apply
  audit_correlation_id: trace_id:a2a_handoff_id
  failure_attribution: initiator_executor_policy_tool_external
  revocation_policy: revoke_on_policy_drift_or_owner_change

The artifact should be reviewed against concrete A2A failure modes: delegation laundering, context over-sharing, remote-agent impersonation, unbounded delegation chains, conflicting actions, lost accountability, and cross-agent prompt injection.

4. The Typical Mistake: Building Multi-Agent Too Early¶

In practice, the confusion usually looks like this:

1. The team has one runtime.
2. It needs to connect three systems.
3. Instead of capability contracts, the team starts designing multi-agent orchestration.

That is almost always unnecessary complexity.

If the system still has no real reason to split responsibility between agents, then:

• tools are better connected through MCP;
• orchestration is better kept inside one runtime;
• multi-agent coordination is better postponed.

A good practical rule is: if the entity does not make its own decisions and does not have its own operational role, it is probably not an agent yet. It is a capability.

4.1. Multi-agent reliability research currently reinforces skepticism¶

This point is worth one more practical note. Recent papers on multi-agent reliability do not yet provide a strong reason to make runtimes more complex by default. If anything, they show how quickly coordination failures, verification gaps, and ambiguity grow when a system is split without a clear need.

The practical reading is:

• the research does not say “build more agents”;
• the research says “if you already build multi-agent systems, use explicit contracts, verification loops, and diagnosable handoffs”;
• the current best practice is still single-agent first.

That is why A2A should be introduced not because it looks architecturally elegant, but because the system already contains separate operational roles that can no longer be honestly described as tools.

4.2. Agreement between several agents is not independent verification¶

Even if several agents reach a similar conclusion, that still does not prove the system has produced an independent verification signal.

The common problems are familiar:

• agents see the same contaminated context;
• the reasoning paths are too similar;
• the manager agent nudges downstream agents toward the expected answer;
• the consensus looks convincing while resting on the same bad assumption.

That is why multi-agent agreement is better treated as a signal, not as proof of correctness.

5. Decision Table¶

6. What This Looks Like in a Mature Architecture¶

In a mature platform, these ideas do not compete. They sit on different layers.

flowchart LR
    A["Coordinator agent"] --> B["A2A handoff"]
    B --> C["Specialist agent"]
    A --> D["MCP client"]
    C --> E["MCP client"]
    D --> F["Tool / resource server"]
    E --> G["Tool / resource server"]

The healthy pattern is:

• an agent works with tools through MCP;
• an agent works with another agent through A2A;
• policy and audit should cover both directions.

7. When Not to Use A2A¶

There are a few red flags:

• you want to use a second agent only as an API wrapper;
• the second agent has no separate policy surface;
• it has no separate operational identity;
• it can be described more simply as a capability contract;
• parallelism and specialization do not produce clear value.

In all those cases, it is better to stay with MCP or even an ordinary gateway/adapter layer.

8. Minimal Code Sketch¶

Below is a very small sketch that shows the difference in thinking:

def call_tool_via_mcp(tool_name: str, payload: dict) -> dict:
    return {"kind": "tool_result", "tool": tool_name, "payload": payload}


def delegate_via_a2a(agent_name: str, task: dict) -> dict:
    return {"kind": "agent_result", "agent": agent_name, "task": task}

The point is not the code itself, but the interaction type:

• a tool call returns a capability result;
• an A2A handoff returns the work result of another agent.

Those are different operational semantics, and it is useful not to blur them together.

9. What to Do Right Away¶

Start with this short list and mark every "no" explicitly:

• Do I need a new agent or just a new capability?
• Does this entity have its own role, policy surface, and lifecycle?
• Is this a delegation problem or an integration problem?
• Can I explain why MCP is not enough here?
• Am I building a multi-agent topology earlier than I actually need?

If those questions are hard to answer, it is usually safer to choose MCP first, not A2A.

10. What to Do Next¶

• Part IV. Tools and Execution
• Chapter 9. Sandbox Execution and MCP as an Integration Contract
• Chapter 10. Idempotency, Retries, Rate Limits, and Rollback Boundaries
• Research Frontier: Memory, Observability, and Multi-Agent Reliability
• Sources