How A2A works

An A2A server publishes an Agent Card that describes its name, provider, skills, input and output modes, interfaces, security requirements, and optional capabilities. The official discovery guide describes well-known URLs, curated registries, and direct configuration as discovery patterns.

A client sends a Message. The remote agent may respond directly or create a Task. Tasks carry state and can produce Artifacts. Depending on declared capabilities and the chosen binding, clients can poll, stream, or receive push updates. Context identifiers can group related exchanges, while task identifiers refer to a specific unit of work.

Agent Cards help a client decide whether an agent appears suitable. They do not prove that its output is accurate or that the agent is safe. Authentication, authorization, trust policy, testing, and monitoring remain separate controls.

Decision table

Requirement: Read or update a system through a defined operation; Prefer MCP: Yes; Prefer A2A: No; Use both: Sometimes

Requirement: Delegate an open-ended domain task; Prefer MCP: No; Prefer A2A: Yes; Use both: Often

Requirement: Keep the remote implementation opaque; Prefer MCP: Possible; Prefer A2A: Core design; Use both: Yes

Requirement: Discover tool schemas; Prefer MCP: Core design; Prefer A2A: Not the primary purpose; Use both: Yes

Requirement: Discover remote-agent skills and endpoints; Prefer MCP: No; Prefer A2A: Core design; Use both: Yes

Requirement: Track a long-running delegated task; Prefer MCP: Extension/platform dependent; Prefer A2A: Core task model; Use both: Often

Requirement: Connect agents built on different frameworks; Prefer MCP: Indirectly through tools; Prefer A2A: Core purpose; Use both: Yes

Requirement: Give each specialist agent its own tool set; Prefer MCP: Not by itself; Prefer A2A: A2A delegates to specialists; Use both: Yes

Requirement: Deterministic record update with strict validation; Prefer MCP: Strong fit; Prefer A2A: Usually excessive; Use both: Rarely

A combined architecture

A practical combined system has three levels:

1. A user-facing orchestrator receives a goal.

2. It delegates bounded domain tasks to remote specialists through A2A.

3. Each specialist uses MCP to reach the systems and data it is authorized to access.

For example, a sales orchestrator can delegate account research to a research agent over A2A. That agent can use separate MCP servers for the CRM, approved web research, and document storage. It returns a structured research artifact. The orchestrator can then delegate proposal drafting to another agent without giving the drafting agent CRM write access.

This separation can improve least privilege and ownership, but only if boundaries are real. Reusing one unrestricted credential across every agent defeats the benefit.

Security and governance

For MCP, govern servers and tools. Record the server owner, endpoint, transport, authorization method, allowed tools, data classes, destructive actions, and approval requirements. Validate OAuth token audience and never pass a client token unchanged to a downstream API.

For A2A, govern agents and delegation. Verify the endpoint and Agent Card through a trusted discovery path. Use authenticated extended cards for sensitive capabilities where supported. The latest A2A specification describes optional JWS signatures for Agent Cards, but a signature confirms integrity and origin, not business suitability.

For both protocols:

• bind every action to an authenticated principal;

• use least-privilege credentials per agent or service boundary;

• constrain tool and task inputs;

• require confirmation for payments, deletion, external communication, or irreversible changes;

• log delegation, tool calls, authorization decisions, and final outcomes;

• prevent untrusted content from silently changing instructions;

• evaluate outputs and side effects, not only HTTP success;

• define timeouts, retries, idempotency, cancellation, and compensation.