Layering
MCP, A2A and AMMP sit at different layers
AMMP is not an alternative to MCP or A2A. Each connects different things, and each is good at different things. This is a layering summary, not a verdict. Check the details against each protocol's own documentation before relying on them.
| Connects | Good at | Where send authority lives | What the other side needs | |
|---|---|---|---|---|
| MCP | A model to tools and context | Giving agents capabilities through a common tool interface | With the tool server, and whatever credentials it holds | Not a cross-organisation protocol |
| A2A | Agent services to each other | Task lifecycles, progress reporting, streaming and conversation between agent services | Within each service and its agreed authentication | A reachable, compatible agent service and an agreed authentication arrangement |
| AMMP | An agent's connector to its email runtime | Keeping email authority outside the agent | In the trusted runtime only | An email address |
MCP
MCP connects a model to tools and context. Where authority lives depends on the tool server and the credentials it holds: MCP itself does not decide that.
AMMP can sit behind MCP. In the Claude Code and Codex connectors, for example, the agent sees ordinary MCP tools: a read-only inbox, and a submit tool that writes a gated request. AMMP is the specification behind those tools, which is why they carry no send capability. The two are complementary.
A2A
A2A connects agent services directly. It has real strengths:
- explicit task lifecycles;
- progress reporting;
- streaming;
- conversational interaction between agent services.
It does not require the same vendor, cloud or directory on both sides, and managed platforms can supply much of the plumbing. Credential isolation, policy enforcement and human approval can be built around A2A as well as around email.
Either way, cross-organisation automation still needs agreement on:
- business authorisation;
- data governance;
- failure handling;
- revocation.
AMMP
AMMP defines the boundary between an agent's connector and its trusted email runtime. It adds nothing to the wire between organisations: the other side sees ordinary email. So an organisation can deploy an agent under AMMP without its counterparties changing anything, whether each counterparty is a person with an inbox or an agent of its own.
Hypothesis For relationships that already run on email, AMMP may reduce the coordination needed to automate safely, not only the code. This is a hypothesis to test, not a finding. Services that are intentionally integrated may well be better served by direct agent-to-agent protocols.
For how AMMP relates to IETF work, such as DKIM, DMARC and WIMSE, see AMMP at the IETF.
See also: How it works · For implementers · Glossary.