{"slug": "agent-communication-context-protocol-accp-proposal", "title": "Agent Communication Context Protocol (ACCP)- Proposal", "summary": "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.", "body_md": "**Version 0.1 (draft)** · Status: for discussion · Not yet submitted to any\nstandards body\n\nACCP defines how autonomous software agents address, authenticate and exchange structured messages with one another across organisational boundaries.\n\nIt is not a new transport. ACCP is a **profile over RFC 5322 and MIME** — the\nmessage format the world's email already speaks — adding the small number of\nthings agent-to-agent traffic needs and ordinary mail lacks: a machine-readable\npayload with a defined media type, correlation across a conversation, declared\nintent, capability discovery, and mandatory loop control.\n\nA 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.\n\nThe Model Context Protocol (MCP) solved a real problem and does not solve this one. The two run on different axes.\n\n| MCP | ACCP | |\n|---|---|---|\nAxis |\nVertical: an agent reaching down to tools and data |\nHorizontal: an agent reaching across to a peer |\nTrust boundary |\nOne. The agent and its servers are operated together | Many. The two ends may never have met |\nSession |\nLong-lived, stateful, negotiated at connect | None. Every message stands alone |\nTiming |\nSynchronous request/response | Asynchronous. The peer may be offline for days |\nAddressing |\nLocal configuration names the server | Global. An address resolves from anywhere |\nDelivery |\nA connection, or an error | Store-and-forward, with retry and bounce |\nFailure modes |\nConnection refused, tool error | Bounced, delayed, quarantined, silently dropped |\n\nAn agent needs both, and they compose cleanly: **an agent uses MCP to reach its\nown mailbox, and ACCP is what is on the wire between agents.** One is how it\nholds a tool; the other is how it holds a conversation.\n\nAgent-to-agent messaging needs five properties. Building them takes years each:\n\n**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.\n\nExactly 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.\n\nThe 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.\n\nSo 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.\n\nACCP is not unprecedented and does not claim to be.\n\n**FIPA-ACL**(1997–2002) defined agent messages with*performatives*—`inform`\n\n,`request`\n\n,`agree`\n\n,`refuse`\n\n. 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.\n\nThe three can coexist in one agent. They answer different questions.\n\nThe 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.\n\n| Term | Meaning |\n|---|---|\nAgent |\nAn autonomous program addressable at one mailbox address |\nAgent address |\nAn RFC 5322 addr-spec naming an agent |\nACCP message |\nAn RFC 5322 message carrying the headers in §3 |\nPayload |\nThe structured, machine-readable body part (§5) |\nConversation |\nA set of messages correlated by `ACCP-Conversation` |\nHop |\nOne agent-generated message in a conversation |\nEndpoint |\nThe implementation that sends and receives on an agent's behalf |\n\nAn ACCP message MUST be a valid RFC 5322 message. It MUST carry the headers\nbelow. Header field names follow RFC 6648: no `X-`\n\nprefix.\n\n| Header | Value |\n|---|---|\n`ACCP-Version` |\nThe protocol version. `0.1` for this document. |\n`ACCP-Intent` |\nOne of the intents in §4. |\n`ACCP-Conversation` |\nAn opaque token, globally unique at origin, identifying the conversation. |\n`ACCP-Hops` |\nA non-negative integer: how many agent-generated messages precede this one in the conversation, plus one. |\n\nSenders MUST also set `Message-ID`\n\n, `Date`\n\nand `From`\n\nas RFC 5322 requires. A\nreply MUST set `In-Reply-To`\n\nand SHOULD set `References`\n\n.\n\n| Header | Value |\n|---|---|\n`ACCP-Agent` |\nThe sending agent's canonical address, when it differs from `From` (for example when sent through a shared relay). |\n`ACCP-Capability` |\nThe capability token (§6) this message invokes. |\n`ACCP-Correlation` |\nAn opaque token echoed unchanged in the response, for a sender correlating replies to its own outstanding requests. |\n`ACCP-Idempotency-Key` |\nSet by the sender; a receiver that has already acted on this key MUST NOT act again, and SHOULD return its previous response. |\n`ACCP-Expires` |\nAn RFC 3339 timestamp after which the message is no longer worth acting on. |\n\n`ACCP-Conversation`\n\nis generated by the agent that begins the conversation and\nMUST be echoed unchanged by every participant for its lifetime.\n\nIt exists because RFC 5322 threading (`In-Reply-To`\n\n/ `References`\n\n) is\nreconstructed rather than declared, and reconstruction fails: clients truncate\n`References`\n\n, some strip it, and subject-based fallback is a guess. A declared\ntoken is unambiguous.\n\nImplementations MUST still populate `In-Reply-To`\n\nand `References`\n\n, so that mail\nclients — and humans — thread the conversation correctly. When the two\ndisagree, `ACCP-Conversation`\n\nwins.\n\nReceivers 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.\n\n`ACCP-Hops`\n\nMUST be set to zero on a message a human originated, and to the\npredecessor's value plus one on every agent-generated message.\n\nAn 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.\n\nThis 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.\n\n`ACCP-Intent`\n\ndeclares what the sender wants, so a receiver can route and\nprioritise before parsing the payload.\n\n| Intent | Meaning | Reply expected |\n|---|---|---|\n`request` |\nAsking the recipient to do something or answer something | Yes |\n`response` |\nAnswering a prior `request` |\nNo |\n`notify` |\nInforming, with no action required | No |\n`error` |\nReporting that a prior message could not be handled (§7) | No |\n`ack` |\nConfirming receipt where work will take time | No |\n\nA `response`\n\n, `error`\n\nor `ack`\n\nMUST set `In-Reply-To`\n\nto the `Message-ID`\n\nof the\nmessage it answers.\n\nReceivers MUST accept an unrecognised intent and SHOULD treat it as `notify`\n\n,\nso the vocabulary can grow without breaking deployed agents.\n\nThis 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.\n\nStructured content MUST be carried in a MIME part with media type\n`application/accp+json`\n\n, encoded as UTF-8 JSON.\n\nThe part SHOULD carry `Content-Disposition: inline; filename=\"accp.json\"`\n\n, so\nthat mail infrastructure treats it as content rather than an attachment, and so\na human opening the message in a mail client sees something named\ncomprehensibly.\n\nA message MUST NOT contain more than one `application/accp+json`\n\npart. A\nreceiver encountering several MUST use the first and SHOULD report the rest as\nan error.\n\nA message carrying a payload MUST also carry a `text/plain`\n\nor `text/html`\n\npart\nconveying the same substance in prose.\n\nThis 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.\n\nWhere the sender has no prose to offer, the endpoint MUST generate a rendering of the payload rather than omit the part.\n\nACCP standardises the **envelope**, not the ontology. The payload's internal\nstructure is a matter for the two agents and their domain.\n\nA payload SHOULD be a JSON object. It MAY carry a `$schema`\n\nmember naming a JSON\nSchema the sender claims to conform to. Receivers MUST NOT require it.\n\nThis 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.\n\nAn agent that cannot find its counterpart is limited to addresses hardcoded when it was built.\n\nAn endpoint MAY publish a card for an agent, as `application/json`\n\n:\n\n```\n{\n  \"accp_version\": \"0.1\",\n  \"address\": \"invoices@acme.example\",\n  \"display_name\": \"Invoice parser\",\n  \"description\": \"Extracts totals and due dates from invoices.\",\n  \"capabilities\": [\"invoice.parse\", \"invoice.query\"],\n  \"accepts_unsolicited\": false,\n  \"payload_schemas\": {\n    \"invoice.parse\": \"https://acme.example/schemas/invoice-parse.json\"\n  }\n}\n```\n\nPublication MUST be opt-in per agent.\n\nGiven an address, a client SHOULD resolve the card by requesting\n`https://<domain>/.well-known/accp/agent?address=<addr-spec>`\n\n.\n\nAn endpoint MAY additionally offer a search interface. Search is explicitly not part of the core: a queryable index of every agent address is also a harvesting surface, and whether to run one is a policy decision, not a protocol one.\n\n`capabilities`\n\nis a list of dotted lowercase tokens (`invoice.parse`\n\n). They are\nadvisory: a sender uses them to choose a recipient, and a receiver MUST still\nvalidate what actually arrives.\n\nAn agent that cannot handle a message SHOULD reply with `ACCP-Intent: error`\n\nand a payload:\n\n```\n{\n  \"error\": {\n    \"code\": \"payload_invalid\",\n    \"message\": \"quantity must be a positive integer\",\n    \"field\": \"quantity\",\n    \"retryable\": false\n  }\n}\n```\n\nRegistered codes for this version:\n\n| Code | Meaning |\n|---|---|\n`payload_invalid` |\nThe payload was malformed or failed validation |\n`capability_unsupported` |\nThe requested capability is not offered |\n`not_authorized` |\nThe sender is not permitted to make this request |\n`rate_limited` |\nToo many messages; `retryable` is true |\n`hop_limit_exceeded` |\nThe conversation exceeded its hop ceiling |\n`expired` |\n`ACCP-Expires` had passed on arrival |\n`internal_error` |\nThe receiver failed for its own reasons; `retryable` is true |\n\nAn error reply MUST NOT itself provoke an error reply. An endpoint MUST NOT send\n`error`\n\nin response to `error`\n\n. Without this rule, two agents can trade error\nreports indefinitely — the same loop §3.4 guards, arriving by a different door.\n\nEvery agent MUST declare an inbox policy. Endpoints MUST implement all four tiers.\n\n| Policy | Accepts |\n|---|---|\n`open` |\nAny sender |\n`verified` |\nSenders passing DMARC alignment, or vouched for by the endpoint |\n`allowlist` |\nNamed addresses or domains only |\n`closed` |\nNothing; the agent only sends |\n\nThe default for a newly created agent MUST be `verified`\n\n.\n\nA rejected message MUST be recorded with its reason and MUST NOT be delivered.\nRejection SHOULD be silent to the sender where the policy is `allowlist`\n\nor\n`closed`\n\n, to avoid confirming that an address exists.\n\nAn endpoint MUST evaluate SPF, DKIM and DMARC on inbound messages and MUST make the results available to the receiving agent.\n\nAgent identity in ACCP is domain identity: an ACCP message is exactly as\ntrustworthy as the claim that it came from `acme.example`\n\n. This is a real limit.\nIt says nothing about which program at `acme.example`\n\nsent it, or whether that\nprogram was behaving as its operator intended. §9 covers the consequences.\n\nAn agent reading its mail is reading text written by anyone who can reach its address. Prompt injection is not a hypothetical here; it is the expected case.\n\nThe protocol cannot make that content safe. What it requires instead is that the consequences be bounded:\n\n- An endpoint MUST scope an agent's credential to that agent alone. Reading another agent's mail, sending as another address, and changing account configuration MUST be outside what the credential can reach.\n- Endpoints SHOULD treat payload and prose identically for scanning purposes. Hiding an instruction in JSON does not make it inert.\n- Endpoints MUST record what arrived, so an operator can reconstruct why an agent did something.\n\nContainment belongs in the credential, not in the agent's judgement. Whatever the agent is persuaded to attempt, the credential must not be able to do it.\n\n§3.4 and §7 bound automated exchange. Endpoints MUST additionally enforce a per-conversation rate ceiling; 30 messages per minute is a reasonable default. An agent pair exchanging messages as fast as a datacentre allows will exhaust a sending quota and damage a domain's reputation long before a human notices.\n\nIt holds a valid credential and sends well-formed, authenticated messages. Nothing in the envelope detects this. Endpoints MUST provide per-agent sending limits and the ability to suspend an agent immediately.\n\nAutomated senders can generate volume no human can. ACCP's admission policies\n(§8) put the decision with the receiver rather than relying on content\nfiltering, which is why `verified`\n\nand not `open`\n\nis the default. Endpoints\nissuing addresses on a shared domain SHOULD apply progressive sending limits to\nnew agents: reputation on that domain is a shared resource.\n\nACCP inherits email's: hop-to-hop TLS where available, nothing end-to-end.\nPayloads containing personal or sensitive data SHOULD be encrypted with S/MIME\nor OpenPGP, which compose with this profile unchanged — the `application/accp+json`\n\npart is encrypted along with the rest of the body.\n\nAn implementation conforms to **ACCP Core** if it:\n\n- Sends messages that are valid RFC 5322 with all §3.1 headers.\n- Sets\n`ACCP-Hops`\n\ncorrectly and refuses to exceed its ceiling (§3.4). - Carries structured content as\n`application/accp+json`\n\n(§5.1) with a human-readable part alongside (§5.2). - Populates\n`In-Reply-To`\n\nand`References`\n\non replies (§3.3). - Accepts unrecognised intents as\n`notify`\n\n(§4). - Implements all four inbox policies, defaulting to\n`verified`\n\n(§8). - Evaluates SPF, DKIM and DMARC on inbound and exposes the results (§8.1).\n- Never replies to\n`error`\n\nwith`error`\n\n(§7).\n\nCore requires no HTTP API. An implementation that only sends and receives SMTP can conform.\n\nAdds delivery semantics for agents that process messages as work items: at-least-once delivery with leases, acknowledgement, and redelivery of a lease that expires.\n\nAn implementation conforms to the **Mailbox profile** if a message is redelivered\nwhen its lease expires without acknowledgement, and if a message under an\nunexpired lease is not delivered to a second consumer.\n\nThis exists because an agent's failure modes are a worker's, not a mail\nreader's: it crashes mid-task, runs several replicas, and is restarted by a\ndeploy. A read flag loses work in all three cases. Endpoints implementing this\nprofile SHOULD honour `ACCP-Idempotency-Key`\n\n(§3.2), since at-least-once\ndelivery means a message can arrive twice.\n\nAdds §6.2 resolution at `/.well-known/accp/agent`\n\n.\n\n**Payload semantics.**§5.3 standardises the envelope only. Is a capability registry with schema references worth the coordination cost, or does it repeat FIPA's mistake?**Latency floor.** Store-and-forward across the public mail system is seconds to minutes. Should ACCP define a direct-delivery optimisation for peers that can reach each other, with identical semantics and addressing?**Conversation token collisions.**§3.3 scopes by sender domain. Is a structured token (`<uuid>@<domain>`\n\n, matching`Message-ID`\n\n) better than an opaque one?**Economics.** Nothing here meters or charges. Should the protocol carry a payment or quota assertion, or is that strictly an endpoint concern?**Deprecating hop counting.** Is a hop ceiling the right bound, or should it be a conversation-lifetime budget the initiator sets and every participant decrements?**The name.**\"Context\" sits oddly: context is what MCP supplies to a model, whereas this protocol carries messages between peers.** Agent Communication Protocol (ACP)**describes it more accurately. Retained as ACCP here because that is what was asked for; worth settling before anything is published.\n\nA buyer agent requests a quote. Headers folded for readability.\n\n```\nFrom: Buyer <buyer@acme.example>\nTo: seller@widgets.example\nSubject: Quote request: WIDGET-1 x40\nMessage-ID: <01J8X2QK@acme.example>\nDate: Thu, 27 Aug 2026 20:41:03 +0000\nMIME-Version: 1.0\nACCP-Version: 0.1\nACCP-Intent: request\nACCP-Conversation: cnv_01J8X2QK7ZP\nACCP-Hops: 1\nACCP-Capability: quote.request\nACCP-Idempotency-Key: quote-4711\nContent-Type: multipart/alternative; boundary=\"b1\"\n\n--b1\nContent-Type: text/plain; charset=UTF-8\n\nRequesting a quote for 40 units of WIDGET-1, delivered to Kampala\nby 5 September.\n\n--b1\nContent-Type: application/accp+json; charset=UTF-8\nContent-Disposition: inline; filename=\"accp.json\"\n\n{\n  \"sku\": \"WIDGET-1\",\n  \"quantity\": 40,\n  \"deliver_to\": \"Kampala, UG\",\n  \"needed_by\": \"2026-09-05\"\n}\n--b1--\n```\n\nThe seller's reply:\n\n```\nFrom: Seller <seller@widgets.example>\nTo: buyer@acme.example\nSubject: Re: Quote request: WIDGET-1 x40\nMessage-ID: <01J8X2R4@widgets.example>\nIn-Reply-To: <01J8X2QK@acme.example>\nReferences: <01J8X2QK@acme.example>\nACCP-Version: 0.1\nACCP-Intent: response\nACCP-Conversation: cnv_01J8X2QK7ZP\nACCP-Hops: 2\nContent-Type: multipart/alternative; boundary=\"b2\"\n\n--b2\nContent-Type: text/plain; charset=UTF-8\n\n40 units at 12,000 UGX each, total 480,000 UGX. Delivery 3 September.\n\n--b2\nContent-Type: application/accp+json; charset=UTF-8\nContent-Disposition: inline; filename=\"accp.json\"\n\n{\n  \"unit_price\": 12000,\n  \"currency\": \"UGX\",\n  \"total\": 480000,\n  \"delivery_date\": \"2026-09-03\"\n}\n--b2--\n```\n\nNote what did not have to be arranged in advance: no shared session, no service discovery handshake, no requirement that either agent was running when the other sent. The buyer could be scaled to zero when the reply arrives.\n\nWere this pursued as a standard, registration would be required for:\n\n**Media type**`application/accp+json`\n\n, per RFC 6838.**Header fields**`ACCP-Version`\n\n,`ACCP-Intent`\n\n,`ACCP-Conversation`\n\n,`ACCP-Hops`\n\n,`ACCP-Agent`\n\n,`ACCP-Capability`\n\n,`ACCP-Correlation`\n\n,`ACCP-Idempotency-Key`\n\n,`ACCP-Expires`\n\nin the Provisional Message Header Field Names registry, per RFC 3864.**Well-known URI**`accp`\n\n, per RFC 8615.- Registries for intents (§4) and error codes (§7), with a low barrier to entry — specification required rather than standards action.\n\nNone of this has been done. This document is a draft for discussion.", "url": "https://wpnews.pro/news/agent-communication-context-protocol-accp-proposal", "canonical_source": "https://github.com/RupertCloud/Agentmail/blob/main/docs/accp/SPEC.md", "published_at": "2026-08-28 07:26:28+00:00", "updated_at": "2026-08-28 07:48:19.750882+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-infrastructure"], "entities": ["Agent Communication Context Protocol (ACCP)", "Model Context Protocol (MCP)", "A2A (Agent2Agent)", "FIPA-ACL", "RFC 5322", "MIME"], "alternates": {"html": "https://wpnews.pro/news/agent-communication-context-protocol-accp-proposal", "markdown": "https://wpnews.pro/news/agent-communication-context-protocol-accp-proposal.md", "text": "https://wpnews.pro/news/agent-communication-context-protocol-accp-proposal.txt", "jsonld": "https://wpnews.pro/news/agent-communication-context-protocol-accp-proposal.jsonld"}}