Agent Communication Context Protocol (ACCP)- Proposal A draft proposal, version 0.1, introduces the Agent Communication Context Protocol (ACCP), a profile over RFC 5322 and MIME that enables autonomous software agents to exchange structured messages across organizational boundaries using existing email infrastructure. ACCP adds machine-readable payloads, correlation, intent, capability discovery, and loop control to standard email, and is positioned as complementary to the Model Context Protocol (MCP) and A2A, targeting asynchronous, federated agent-to-agent communication with global addressing, sender authentication, and offline delivery. Version 0.1 draft · Status: for discussion · Not yet submitted to any standards body ACCP defines how autonomous software agents address, authenticate and exchange structured messages with one another across organisational boundaries. It is not a new transport. ACCP is a profile over RFC 5322 and MIME — the message format the world's email already speaks — adding the small number of things agent-to-agent traffic needs and ordinary mail lacks: a machine-readable payload with a defined media type, correlation across a conversation, declared intent, capability discovery, and mandatory loop control. A conformant ACCP message is a valid email. It reaches an agent through the existing federated mail system, and a human can read it in an ordinary mail client. The Model Context Protocol MCP solved a real problem and does not solve this one. The two run on different axes. | MCP | ACCP | | |---|---|---| Axis | Vertical: an agent reaching down to tools and data | Horizontal: an agent reaching across to a peer | Trust boundary | One. The agent and its servers are operated together | Many. The two ends may never have met | Session | Long-lived, stateful, negotiated at connect | None. Every message stands alone | Timing | Synchronous request/response | Asynchronous. The peer may be offline for days | Addressing | Local configuration names the server | Global. An address resolves from anywhere | Delivery | A connection, or an error | Store-and-forward, with retry and bounce | Failure modes | Connection refused, tool error | Bounced, delayed, quarantined, silently dropped | An agent needs both, and they compose cleanly: an agent uses MCP to reach its own mailbox, and ACCP is what is on the wire between agents. One is how it holds a tool; the other is how it holds a conversation. Agent-to-agent messaging needs five properties. Building them takes years each: Global addressing — any agent can be named from anywhere. Federation — no central registry, no operator everyone must join. Sender authentication — the recipient can tell who actually sent it. Offline delivery — the recipient need not be running right now. An audit trail humans can read when something goes wrong. Exactly one deployed system has all five: email. SPF, DKIM and DMARC are imperfect but universal; MX-based routing federates without permission; a mailbox holds messages for an agent that is redeploying. The alternative — a new JSON-RPC service each agent exposes — reinvents addressing, discovery, authentication and retry, and requires both peers to be reachable at the same moment. That last constraint is the fatal one. Agents restart, scale to zero, and run on schedules. So ACCP adds a layer rather than a stack. The cost is email's warts: latency measured in seconds, MIME's awkwardness, spam. Section 9 addresses each. ACCP is not unprecedented and does not claim to be. FIPA-ACL 1997–2002 defined agent messages with performatives — inform , request , agree , refuse . ACCP's intents §4 are deliberately a small, modern subset of that idea. FIPA assumed an agent platform every participant joined; ACCP assumes only that both ends can send mail. A2A Agent2Agent exchanges JSON-RPC over HTTP between agents, with agent cards for discovery. It is a good fit when both peers are online services with a prior arrangement. ACCP targets the case where they are not: different organisations, no shared infrastructure, no guarantee the peer is up. MCP is the vertical axis, as above. ACCP borrows its lesson that the valuable part of a protocol is a boring, well-specified envelope. The three can coexist in one agent. They answer different questions. The key words MUST, MUST NOT, REQUIRED, SHALL, SHOULD, SHOULD NOT, MAY and OPTIONAL are to be interpreted as described in RFC 2119 and RFC 8174. | Term | Meaning | |---|---| Agent | An autonomous program addressable at one mailbox address | Agent address | An RFC 5322 addr-spec naming an agent | ACCP message | An RFC 5322 message carrying the headers in §3 | Payload | The structured, machine-readable body part §5 | Conversation | A set of messages correlated by ACCP-Conversation | Hop | One agent-generated message in a conversation | Endpoint | The implementation that sends and receives on an agent's behalf | An ACCP message MUST be a valid RFC 5322 message. It MUST carry the headers below. Header field names follow RFC 6648: no X- prefix. | Header | Value | |---|---| ACCP-Version | The protocol version. 0.1 for this document. | ACCP-Intent | One of the intents in §4. | ACCP-Conversation | An opaque token, globally unique at origin, identifying the conversation. | ACCP-Hops | A non-negative integer: how many agent-generated messages precede this one in the conversation, plus one. | Senders MUST also set Message-ID , Date and From as RFC 5322 requires. A reply MUST set In-Reply-To and SHOULD set References . | Header | Value | |---|---| ACCP-Agent | The sending agent's canonical address, when it differs from From for example when sent through a shared relay . | ACCP-Capability | The capability token §6 this message invokes. | ACCP-Correlation | An opaque token echoed unchanged in the response, for a sender correlating replies to its own outstanding requests. | ACCP-Idempotency-Key | Set by the sender; a receiver that has already acted on this key MUST NOT act again, and SHOULD return its previous response. | ACCP-Expires | An RFC 3339 timestamp after which the message is no longer worth acting on. | ACCP-Conversation is generated by the agent that begins the conversation and MUST be echoed unchanged by every participant for its lifetime. It exists because RFC 5322 threading In-Reply-To / References is reconstructed rather than declared, and reconstruction fails: clients truncate References , some strip it, and subject-based fallback is a guess. A declared token is unambiguous. Implementations MUST still populate In-Reply-To and References , so that mail clients — and humans — thread the conversation correctly. When the two disagree, ACCP-Conversation wins. Receivers MUST treat the token as opaque. It MUST NOT be parsed for meaning, and implementations MUST NOT assume it is unique across trust boundaries: two organisations may independently mint the same token, so a receiver's index key is sender domain, conversation token , never the token alone. ACCP-Hops MUST be set to zero on a message a human originated, and to the predecessor's value plus one on every agent-generated message. An endpoint MUST refuse to send a message whose hop count would exceed its configured ceiling, and MUST surface the refusal to its operator rather than dropping it silently. The default ceiling SHOULD be 10. This is not an optimisation. Two agents that reply to each other do not get bored, do not go to lunch, and will exchange messages until something external stops them. Every deployed autoresponder loop in email history was bounded by a human noticing. Autonomous peers remove that bound, so the protocol has to supply one. ACCP-Intent declares what the sender wants, so a receiver can route and prioritise before parsing the payload. | Intent | Meaning | Reply expected | |---|---|---| request | Asking the recipient to do something or answer something | Yes | response | Answering a prior request | No | notify | Informing, with no action required | No | error | Reporting that a prior message could not be handled §7 | No | ack | Confirming receipt where work will take time | No | A response , error or ack MUST set In-Reply-To to the Message-ID of the message it answers. Receivers MUST accept an unrecognised intent and SHOULD treat it as notify , so the vocabulary can grow without breaking deployed agents. This list is deliberately short. FIPA-ACL's twenty-two performatives encoded a theory of agent reasoning that implementations did not share; the interoperable subset was always about this size. Structured content MUST be carried in a MIME part with media type application/accp+json , encoded as UTF-8 JSON. The part SHOULD carry Content-Disposition: inline; filename="accp.json" , so that mail infrastructure treats it as content rather than an attachment, and so a human opening the message in a mail client sees something named comprehensibly. A message MUST NOT contain more than one application/accp+json part. A receiver encountering several MUST use the first and SHOULD report the rest as an error. A message carrying a payload MUST also carry a text/plain or text/html part conveying the same substance in prose. This is the requirement implementers will most want to skip, and it is the one that matters most. Agent mail is read by humans far more often than its author expects: in a support queue, during an incident, in a compliance review, in a customer's own inbox when the conversation escapes the platform. A message that is only machine-readable is opaque at exactly the moment somebody needs to understand what an agent did on their behalf. Where the sender has no prose to offer, the endpoint MUST generate a rendering of the payload rather than omit the part. ACCP standardises the envelope , not the ontology. The payload's internal structure is a matter for the two agents and their domain. A payload SHOULD be a JSON object. It MAY carry a $schema member naming a JSON Schema the sender claims to conform to. Receivers MUST NOT require it. This is a deliberate limit. Attempts to standardise a universal agent-interaction ontology have consistently failed; what survives is a shared envelope with domain-specific contents. §11 discusses what a capability registry would need to look like if the ecosystem later wants stronger guarantees. An agent that cannot find its counterpart is limited to addresses hardcoded when it was built. An endpoint MAY publish a card for an agent, as application/json : { "accp version": "0.1", "address": "invoices@acme.example", "display name": "Invoice parser", "description": "Extracts totals and due dates from invoices.", "capabilities": "invoice.parse", "invoice.query" , "accepts unsolicited": false, "payload schemas": { "invoice.parse": "https://acme.example/schemas/invoice-parse.json" } } Publication MUST be opt-in per agent. Given an address, a client SHOULD resolve the card by requesting https://