Agent Protocols
How do AI agents coordinate without human intermediaries?
Agent protocols define how autonomous systems discover, communicate, transact, and collaborate. As AI agents become economic actors, they need shared standards — the same way humans needed HTTP for the web and TCP/IP for the internet.
This section covers coordination protocols — the technical standards that enable agents and systems to interact. For the broader concept of protocols as sequenced methods (health protocols, business protocols), see Naming Standards.
Agent protocols are the coordination infrastructure for agency — they give phygital beings the capacity to discover, transact, and prove intent. Without protocols, agents have capability but no coordination. With them, the five components of agency extend to autonomous systems.
Protocol Stack
| Layer | Protocol | Governed By | What It Enables |
|---|---|---|---|
| Communication | A2A | Linux Foundation | Agent discovery, task delegation, coordination |
| Tool Access | MCP | Linux Foundation | AI model access to external tools and data |
| Commerce | UCP | Google (open) | Checkout, discounts, fulfillment — agents buying and selling |
| Payment | AP2 | Google (open) | Payment authorization via verifiable credentials |
| Identity | Verifiable Intent | Mastercard + Google | Cryptographic proof linking human intent to agent transaction |
| Settlement | x402, card rails, stablecoins | Various | Value transfer — crypto-native or traditional |
| Attribution | PCP | Story Protocol | IP provenance and creative value flow |
Physical agents enter this same commerce flow — peaq DID for identity, Intercognitive for coordination.
The Google stack: A2A + UCP + AP2 form a coherent ecosystem — communicate, then commerce, then pay. Each protocol is open (Apache 2.0) and moving toward foundation governance.
The competitor: ACP (Agentic Commerce Protocol) from OpenAI + Stripe takes a different approach — merchant-centric, card-rail native. See Agent Commerce for the standards war analysis.
Commerce Flow
DISCOVER → COMMUNICATE → COMMERCE → AUTHORIZE → SETTLE → EVALUATE
↓ ↓ ↓ ↓ ↓ ↓
Agent A2A UCP AP2 Stablecoin PCP
Cards Messages Checkout VDC or card Reputation
| Stage | Protocol | What Happens |
|---|---|---|
| Discover | A2A Agent Cards | Agent publishes /.well-known/agent.json, clients find it |
| Communicate | A2A Tasks + Messages | Agents coordinate, delegate, stream results |
| Commerce | UCP | Agent browses catalog, builds cart, applies discounts |
| Authorize | AP2 + Verifiable Intent | Agent proves payment authority; human consent is traceable |
| Settle | x402 / card rails / stablecoins | Value moves from buyer to seller |
| Evaluate | PCP / reputation systems | Quality signal feeds back into discovery |
Physical agents enter the same flow via peaq DID (identity) and Intercognitive (coordination). Start with Agent Commerce for the landscape. Read UCP for how agents shop, AP2 for how they pay, Verifiable Intent for how consent is proven.
Two Foundations
Both communication protocols are Linux Foundation projects. Complementary, not competing:
| A2A | MCP | |
|---|---|---|
| Connects | Agent to agent | Agent to tool |
| Pattern | Peer-to-peer coordination | Client-server tool access |
| Use case | "Research this, then delegate analysis" | "Query this database, read this file" |
| Governance | Linux Foundation | Linux Foundation |
An agent uses MCP to access data sources, then A2A to delegate specialized work to other agents, then UCP/AP2 to buy things on behalf of the user. Same agent, three protocols, one workflow.
Where Tracks Converge
Digital agents and physical agents share the same infrastructure requirements. The commerce flow is identical. The actor type differs.
| Need | Digital Agent | Physical Agent |
|---|---|---|
| Identity | DID (A2A Agent Cards) | peaq DID |
| Verified time | Block timestamp | Universal Machine Time (UMT) |
| Delegation | Verifiable Intent | Verifiable Intent — same eight constraints |
| Payment | AP2 / x402 | AP2 / x402 |
| Settlement | Sui / card rails | Peaq / Sui |
| Coordination | A2A task delegation | Intercognitive orchestration |
Intercognitive is the proof. The same six-stage commerce flow — DISCOVER → COMMUNICATE → COMMERCE → AUTHORIZE → SETTLE → EVALUATE — runs on physical machines. The nine pillars are the infrastructure layer of that flow for physical agents.
Both tracks share the same structural requirement: benchmarkable standards establish trust. Trust Architecture defines what that means — and where the gap between theory and live systems still exists.
Internal Protocols
| Protocol | What It Governs |
|---|---|
| PRD Handoff | How the dream team writes PRDs and how engineering reads them — Story Contract, Build Contract (FAVV v2.1), parser detection |
Context
- Intelligent Hyperlinks — Agent protocols are generation three: hyperlinks that carry entire business processes
- Tokenization — What the pipe carries: ownership as programmable, tradeable units
- A2A Protocol — How agents discover and coordinate
- UCP — How agents buy and sell
- AP2 — How agents authorize payments
- MCP — How agents access tools
- Verifiable Intent — Cryptographic proof linking human intent to agent action
- Agent Commerce — The standards war for agent transactions
- Proof of Creativity — IP attribution for AI-generated content
- Essential Algorithm — The commerce flow IS the essential algorithm: INTENT → ROUTE → INFRA → SETTLE → FEEDBACK
- Protocols — Algorithms decide the route; protocols enable the handshake
- Phygital Beings — Agents as economic actors
- Smart Contracts — On-chain settlement infrastructure
- Intercognitive Standard — Nine pillars for physical AI coordination
- Peaq — Economy of Things — Machine identity and settlement for DePIN devices
Questions
When agents can discover, communicate, transact, and evaluate each other — who writes the rules of engagement?
- If Google's stack (A2A + UCP + AP2) and OpenAI's stack (MCP + ACP) both succeed, does the agent that speaks both protocols win?
- What happens to the concept of "customer experience" when the customer is an algorithm?
- At what point does protocol governance matter more than protocol design?