Compare

mpl vs A2A

A2A (agent-to-agent) is a peer-to-peer messaging protocol for agents talking directly to other agents. MPL is the contract / quality / audit layer that runs on top. The MPL README places them in the same row of the stack diagram, alongside MCP.

A2A and MCP solve different transport problems (peer-to-peer vs client-server). MPL is transport-agnostic above both. If A2A is your wire, MPL is what makes the messages on that wire typed, scored, and provable.

Fair side-by-side

	A2A	MPL
Layer in the stack	Transport (peer-to-peer agent messaging)	Above the transport
Primary concern	How agents discover each other and exchange task messages	What's in the message, whether it meets quality, whether you can prove it later
Identity / provenance	Agent identity at the transport layer	Provenance block (`agent_id`, `intent`) on every envelope, paired with a content hash
Typed payloads	Message types defined per agent / capability	Versioned `stype` identifiers in a shared registry; same envelope shape across all agents
Quality measurement	Not in scope	QoM profiles applied per envelope; thresholds enforced at the boundary
Audit trail	Not in scope (the application can log)	BLAKE3-hashed records with provenance and QoM, append-only
Mode of operation	In-process or networked, depending on impl	Sidecar proxy; transparent (observe) or strict (enforce)
Status in MPL repo	Targeted; "A2A hardening" is a Phase 3 item per the README	Core protocol & proxy ship today (Phase 1/2 complete)
Substitutable?	No — A2A is the transport	No — MPL composes over A2A, doesn't replace it

When A2A alone is enough

Two agents in a controlled environment, exchanging short tasks, with no external auditability requirement and no need for quality regression over time. A2A handles the transport; you write the validation in the agents themselves.

When you also want MPL

The agent fabric spans teams or organisations, and you need contracts that don't depend on the receiver implementing matching validation.
You want quality scores per message so drift in one agent's behaviour shows up before it's a customer-visible outage.
You have a regulatory ask — SOX, GDPR, HIPAA, EU AI Act — that requires demonstrable, tamper-evident records of agent activity.
You want a single policy language (org.finance.* requires this profile, org.healthcare.* requires consent ref) across the whole fabric.

Honest caveats

A2A integration in MPL is explicitly a Phase 3 item per the project's README ("A2A hardening, production readiness"). The Phase 1 and 2 proxy is built around the HTTP/MCP path first. If A2A is the transport you need today, check the project's current release notes before depending on it for production.

How they run together

Agent A —(A2A)—> MPL Proxy —(A2A)—> Agent B
                       |
                       +——— validates contract
                       +——— scores QoM profile
                       +——— applies policy
                       +——— writes audit record

Sources

MPL README, stack diagram listing A2A alongside MCP at the transport layer.
MPL README Status table: Phase 3 explicitly includes "A2A hardening."
A2A: project home at a2aproject.dev (formerly Google A2A).

If you spot something inaccurate, open an issue.