AMP Overview

AMP (Agent Messaging Protocol) is a native communication protocol designed for the AI Agent ecosystem. It provides binary-efficient, agent-to-agent communication with built-in identity, capability invocation, and credential exchange.

Why AMP?

Existing communication infrastructure was designed for humans:

Infrastructure	Era	Agent Problems
Email (IMAP/SMTP)	1986	Eventual consistency, no native identity
HTTP APIs	1990s	Point-to-point, no standard identity, requires pre-arrangement
WebSocket	2011	Connection-centric, no identity verification standard
DIDComm	2022	Designed for humans/institutions, not agent-optimized

Agents have fundamentally different communication needs:

Human Messages	Agent Messages
Primarily natural language	Primarily structured data
Can be ignored/delayed	Must process or return error
"Read" status sufficient	Needs "processed success/failure"
Low frequency (seconds/minutes)	Potentially high frequency (milliseconds)
JSON/text sufficient	Needs binary efficiency

Core Design

AMP is an independent protocol — not a DIDComm profile or extension. While it borrows concepts from DIDComm (encryption modes, DID resolution, routing), it is purpose-built for agent workloads.

Protocol Layers

┌──────────────────────────────────┐
│  Application Layer               │
│  Capability invocation, document │
│  exchange, credential exchange   │
├──────────────────────────────────┤
│  Security Layer                  │
│  Signing, encryption,            │
│  verification (Ed25519)          │
├──────────────────────────────────┤
│  Transport Layer                 │
│  TCP, HTTP, WebSocket            │
│  (transport-agnostic)            │
└──────────────────────────────────┘

Message Format

AMP uses CBOR (Concise Binary Object Representation) for wire encoding — compact, schema-friendly, and faster to parse than JSON.

Every AMP message has a standard envelope:

• Sender DID — Cryptographic identity of the sender
• Recipient DID — Target agent
• Message ID — Time-correlated unique identifier
• Type — Message type code
• Timestamp — For replay protection
• Signature — Ed25519 cryptographic proof
• Body — Type-specific payload

Conformance Profiles

Profile	Description
AMP Core	Envelope, security, handshake, error/ack behavior — minimal interoperability baseline
AMP Full	AMP Core plus document/credential/delegation application flows

Key Capabilities

Capability Invocation (RPC)

Agents can invoke each other's capabilities with structured request/response semantics, including progress updates and streaming results.

Document Exchange

Structured exchange of documents between agents — inline for small payloads, streaming for large ones.

Credential Exchange

Verifiable credential presentation and verification following W3C VC standards.

Delegation

Agents can act on behalf of other agents or humans, carrying cryptographic delegation proofs in messages.

Interoperability

AMP provides optional bridges to other ecosystems:

┌─────────────────────────────────────────┐
│              AMP Core                    │
│  (Independent protocol, DID-native)     │
├─────────────────────────────────────────┤
│        Optional Bridges                  │
│  - A2A Agent Card export                │
│  - MCP tool exposure                    │
│  - DIDComm message translation          │
└─────────────────────────────────────────┘

An AMP agent can be discovered via A2A, exposed as MCP tools, or bridged to DIDComm — but AMP does not depend on any of these protocols.

Related RFCs

AMP is specified across multiple RFCs:

• RFC 001 — Core messaging protocol (envelope, types, security)
• RFC 002 — Transport bindings (TCP, HTTP, WebSocket)
• RFC 003 — Relay and store-and-forward for offline agents
• RFC 004 — Capability schema and version negotiation
• RFC 005 — Delegation credentials and authorization

See the full RFC Index for all specifications.

Further Reading

• AMP First Principles — Design rationale and protocol comparison analysis
• RFC 001 Full Specification — Complete normative specification