Internet Engineering Task Force RB. Benzing Internet-Draft April 2026 Intended status: Standards Track Expires: 9 October 2026 Agent Context Compression Protocol (ACCP) draft-benzing-accp-00 Abstract This document specifies the Agent Context Compression Protocol (ACCP), a semantic encoding and context management protocol for communication between AI agents within agentic harnesses. ACCP defines a compact message format, intent ontology, state compression strategy, and codec interface that collectively reduce token consumption by 60-90% compared to natural language or standard JSON messaging. ACCP is designed to complement existing protocols (MCP, A2A) and is transport-agnostic. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 October 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Benzing Expires 9 October 2026 [Page 1] Internet-Draft ACCP April 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Frame Lifecycle . . . . . . . . . . . . . . . . . . . . . 5 3. Message Format (ACCP-M) . . . . . . . . . . . . . . . . . . . 5 3.1. Frame Structure . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Typed Value Canonical Rules . . . . . . . . . . . . . 6 3.2. Frame Examples . . . . . . . . . . . . . . . . . . . . . 7 3.3. Token Optimization Rules . . . . . . . . . . . . . . . . 7 3.4. Frame Size Limits . . . . . . . . . . . . . . . . . . . . 8 3.5. Standard Message Envelope . . . . . . . . . . . . . . . . 8 3.6. Error Model . . . . . . . . . . . . . . . . . . . . . . . 9 3.7. Delivery Semantics . . . . . . . . . . . . . . . . . . . 11 4. Intent and Operation Ontology (ACCP-I) . . . . . . . . . . . 12 4.1. Core Intents . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Standard Key Abbreviations . . . . . . . . . . . . . . . 13 4.3. Operation Registry . . . . . . . . . . . . . . . . . . . 14 5. Context State Management (ACCP-S) . . . . . . . . . . . . . . 14 5.1. State Hierarchy . . . . . . . . . . . . . . . . . . . . . 14 5.2. Compression Checkpoints . . . . . . . . . . . . . . . . . 14 5.3. Checkpoint Process . . . . . . . . . . . . . . . . . . . 15 5.4. Delta Encoding . . . . . . . . . . . . . . . . . . . . . 15 6. Schema Registry (ACCP-R) . . . . . . . . . . . . . . . . . . 15 6.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. Registry Structure . . . . . . . . . . . . . . . . . . . 15 6.3. Usage in Frames . . . . . . . . . . . . . . . . . . . . . 16 6.4. Registry Negotiation . . . . . . . . . . . . . . . . . . 16 7. Codec API Specification . . . . . . . . . . . . . . . . . . . 16 7.1. Interface Definition . . . . . . . . . . . . . . . . . . 16 7.2. Encoding Pipeline . . . . . . . . . . . . . . . . . . . . 17 7.3. Decoding Pipeline . . . . . . . . . . . . . . . . . . . . 17 8. Conformance Requirements . . . . . . . . . . . . . . . . . . 17 8.1. Minimum Conformance (Level 1) . . . . . . . . . . . . . . 17 8.2. Standard Conformance (Level 2) . . . . . . . . . . . . . 18 Benzing Expires 9 October 2026 [Page 2] Internet-Draft ACCP April 2026 8.3. Full Conformance (Level 3) . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Domain Profiles . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Chat Profile (CH) . . . . . . . . . . . . . . . . . . . 19 10.2. Tool / MCP Profile (TC) . . . . . . . . . . . . . . . . 19 10.3. Transaction Profile (TX) . . . . . . . . . . . . . . . . 19 10.4. Streaming Profile (ST) . . . . . . . . . . . . . . . . . 20 10.5. Workflow Profile (TA) . . . . . . . . . . . . . . . . . 20 11. Transport Bindings . . . . . . . . . . . . . . . . . . . . . 20 11.1. ACCP-over-HTTP . . . . . . . . . . . . . . . . . . . . . 20 11.2. ACCP-over-WebSocket . . . . . . . . . . . . . . . . . . 21 11.3. ACCP-over-MCP . . . . . . . . . . . . . . . . . . . . . 21 11.4. ACCP-over-A2A . . . . . . . . . . . . . . . . . . . . . 21 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 12.1. Media Type Registration . . . . . . . . . . . . . . . . 21 13. Normative References . . . . . . . . . . . . . . . . . . . . 22 14. Informative References . . . . . . . . . . . . . . . . . . . 22 Appendix A. Token Comparison Benchmarks . . . . . . . . . . . . 22 Appendix B. Future Work . . . . . . . . . . . . . . . . . . . . 23 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction 1.1. Motivation The operational cost of multi-agent AI systems is dominated by token consumption at the LLM inference layer. Existing agent communication protocols optimize for interoperability, discovery, and routing but transmit messages in verbose formats (natural language, pretty- printed JSON) that are highly wasteful from a token-cost perspective. ACCP addresses this by introducing a protocol layer between the orchestration harness and the LLM API that encodes agent communication into a compact, semantically-faithful format. 1.2. Scope ACCP defines: * Message encoding format (Section 3) * Intent and operation codes (Section 4) * Context state management (Section 5) * Schema registry interface (Section 6) Benzing Expires 9 October 2026 [Page 3] Internet-Draft ACCP April 2026 * Codec API (Section 7) ACCP does NOT define: * Transport mechanisms (defer to [MCP]/[A2A]/HTTP) * Agent discovery or routing (defer to [A2A]/ANP) * LLM API specifics * Authentication or authorization (defer to transport layer) 1.3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in capitalized, as shown here. +============+======================================================+ | Term | Definition | +============+======================================================+ | Agent | An autonomous LLM-backed process within a harness | +------------+------------------------------------------------------+ | Harness | The orchestration framework managing agents | +------------+------------------------------------------------------+ | Codec | The ACCP encoder/decoder library | +------------+------------------------------------------------------+ | Frame | A single ACCP-encoded message unit | +------------+------------------------------------------------------+ | Session | A bounded sequence of frames comprising one | | | workflow | +------------+------------------------------------------------------+ | Checkpoint | A state compression boundary | +------------+------------------------------------------------------+ | Intent | A standardized operation code | +------------+------------------------------------------------------+ Table 1 2. Protocol Overview 2.1. Architecture Benzing Expires 9 October 2026 [Page 4] Internet-Draft ACCP April 2026 Agent A Agent B | | +-- compose message (NL/struct) | | | | | +----v-----+ | | | ACCP | | | | Encoder | | | +----+-----+ | | | (ACCP Frame) | | +----v-----+ +-----+-----+ | |Transport | -------> | Transport | | |(MCP/A2A) | | (MCP/A2A) | | +----------+ +-----+-----+ | | | +-----v-----+ | | ACCP | | | Decoder | | +-----+-----+ | | | inject into LLM context Figure 1: ACCP Architecture 2.2. Frame Lifecycle 1. Sending agent composes a message (natural language or structured) 2. ACCP Encoder compresses it into a Frame 3. Frame is transmitted via the existing transport layer 4. ACCP Decoder at receiving end reconstructs the semantic content 5. Decoded content is injected into the receiving agent's LLM context 3. Message Format (ACCP-M) 3.1. Frame Structure An ACCP Frame is a single-line UTF-8 string defined by the following ABNF grammar ([RFC5234]): Benzing Expires 9 October 2026 [Page 5] Internet-Draft ACCP April 2026 frame = header body [metadata] header = "@" agent-id ">" intent body = ":" operation "{" [payload] "}" metadata = "[" meta-pairs "]" payload = param *( "|" param ) param = key ":" value value = typed-literal / array / map / ref / null typed-literal = boolean / integer / decimal / string boolean = "true" / "false" integer = ["-"] 1*DIGIT decimal = ["-"] 1*DIGIT "." 1*DIGIT string = 1*( safe-char / escaped-char ) safe-char = VCHAR except delimiter escaped-char = "\" delimiter delimiter = "@" / ">" / ":" / "{" / "}" / "[" / "]" / "|" / "$" / "," / "~" / "\" null = "~" array = "[" [ value *( "," value ) ] "]" map = "{" [ key ":" value *( "," key ":" value ) ] "}" ref = "$" ref-key meta-pairs = param *( "," param ) agent-id = 1*( ALPHA / DIGIT / "-" / "_" ) intent = 1*( ALPHA ) operation = 1*( ALPHA / DIGIT / "_" ) key = 1*( ALPHA / DIGIT / "_" ) ref-key = 1*( ALPHA / DIGIT / "_" / "." ) 3.1.1. Typed Value Canonical Rules +=========+===========================+=====================+ | Type | Wire Format | Example | +=========+===========================+=====================+ | String | Raw printable ASCII; | hello, a\:b | | | delimiters escaped with \ | | +---------+---------------------------+---------------------+ | Integer | Decimal, no leading zeros | 42, -7 | +---------+---------------------------+---------------------+ | Decimal | Canonical 6dp, trailing | 3.14, -0.5 | | | zeros stripped | | +---------+---------------------------+---------------------+ | Boolean | true or false | true | +---------+---------------------------+---------------------+ | Null | ~ | ~ | +---------+---------------------------+---------------------+ | Array | [v1,v2,v3] | [1,2,3] | +---------+---------------------------+---------------------+ | Map | {k1:v1,k2:v2} -- keys | {a:1,b:2} | Benzing Expires 9 October 2026 [Page 6] Internet-Draft ACCP April 2026 | | sorted ascending | | +---------+---------------------------+---------------------+ | Ref | $tier.key | $warm.ckpt_1.status | +---------+---------------------------+---------------------+ Table 2 Decimal values MUST be serialized with up to 6 decimal places, trailing zeros stripped. Encoders MUST NOT use scientific notation. 3.2. Frame Examples Task completion with findings: @research>done:analyze{d:q3_sales|f:[rev:-12%QoQ,ent_seg:decline, churn:+3.2%]|nx:@strategy:plan} Request with parameters: @planner>req:schedule{who:@dev_team|when:sprint_14| task:impl_auth_module|pri:high} Query with context reference: @analyst>qry:lookup{src:$ctx.sales_db|q:revenue_by_region|fmt:summary} State sync: @orchestrator>sync:state{v:7|delta:{task_3:done,task_4:wip, budget:$42.30}} Error with escalation: @data_agent>fail:fetch{src:api.crm|err:timeout_30s|retry:3| esc:@supervisor} 3.3. Token Optimization Rules Encoders MUST follow these rules to minimize token count: 1. No whitespace -- Frames MUST NOT contain spaces, tabs, or newlines. 2. Abbreviated keys -- Use shortest unambiguous key names (see Section 4.2). 3. Symbolic values -- Prefer symbols over words: +, -, %, >, <. Benzing Expires 9 October 2026 [Page 7] Internet-Draft ACCP April 2026 4. Reference over inline -- If a value exceeds 50 characters, store in state and reference via $key. 5. Omit defaults -- Do not encode values that match the schema default. 6. Coalesce arrays -- Use comma separation within brackets, no spaces. 3.4. Frame Size Limits +=============+===================+===================+ | Component | Max Tokens (soft) | Max Tokens (hard) | +=============+===================+===================+ | Header | 5 | 10 | +-------------+-------------------+-------------------+ | Body | 50 | 200 | +-------------+-------------------+-------------------+ | Metadata | 10 | 30 | +-------------+-------------------+-------------------+ | Total Frame | 65 | 240 | +-------------+-------------------+-------------------+ Table 3 Frames exceeding the hard limit SHOULD be split into a frame sequence or reference external state. 3.5. Standard Message Envelope Every ACCP frame MUST include the following envelope fields in its metadata block: Benzing Expires 9 October 2026 [Page 8] Internet-Draft ACCP April 2026 +================+========+============+==========+=================+ | Field | Abbrev | Type | Required | Description | +================+========+============+==========+=================+ | msg_id | mid | string(12) | MUST | Unique message | | | | | | identifier | | | | | | (hex, 12 | | | | | | chars) | +----------------+--------+------------+----------+-----------------+ | sequence | seq | integer | MUST | Monotonically | | | | | | increasing per | | | | | | session | +----------------+--------+------------+----------+-----------------+ | timestamp | ts | integer | MUST | Unix epoch | | | | | | seconds | +----------------+--------+------------+----------+-----------------+ | correlation_id | cid | string | SHOULD | Links request | | | | | | to response | +----------------+--------+------------+----------+-----------------+ | causation_id | aid | string | MAY | Links to the | | | | | | message that | | | | | | caused this | | | | | | one | +----------------+--------+------------+----------+-----------------+ | session_id | sid | string | SHOULD | ACCP session | | | | | | identifier | +----------------+--------+------------+----------+-----------------+ | ttl | ttl | integer | MAY | Seconds until | | | | | | frame expires; | | | | | | 0 = no expiry | +----------------+--------+------------+----------+-----------------+ Table 4 Example metadata block: [mid:49679033e07c,seq:3,ts:1714000000,cid:corr123,sid:abc-session] Decoders MUST reject frames with expired TTL. Frames missing "mid" or "seq" MUST be rejected. 3.6. Error Model Standard error frames use intent "fail", operation "error", and schema "ER". Error code taxonomy: Benzing Expires 9 October 2026 [Page 9] Internet-Draft ACCP April 2026 +=======+===============================+ | Range | Category | +=======+===============================+ | E1xxx | Parse / grammar errors | +-------+-------------------------------+ | E2xxx | State store errors | +-------+-------------------------------+ | E3xxx | Transport / delivery errors | +-------+-------------------------------+ | E4xxx | Tool / MCP errors | +-------+-------------------------------+ | E5xxx | Policy / authorization errors | +-------+-------------------------------+ | E9xxx | Internal / unknown errors | +-------+-------------------------------+ Table 5 Standard error codes: Benzing Expires 9 October 2026 [Page 10] Internet-Draft ACCP April 2026 +=======+======================+===========+ | Code | Name | Retryable | +=======+======================+===========+ | E1001 | PARSE_ERROR | No | +-------+----------------------+-----------+ | E1002 | INVALID_INTENT | No | +-------+----------------------+-----------+ | E1003 | UNKNOWN_SCHEMA | No | +-------+----------------------+-----------+ | E1004 | INVALID_TYPE | No | +-------+----------------------+-----------+ | E2001 | REF_NOT_FOUND | No | +-------+----------------------+-----------+ | E2002 | REF_EXPIRED | No | +-------+----------------------+-----------+ | E2003 | BUDGET_EXCEEDED | No | +-------+----------------------+-----------+ | E3001 | TIMEOUT | Yes | +-------+----------------------+-----------+ | E3002 | DUPLICATE | No | +-------+----------------------+-----------+ | E3003 | SEQUENCE_GAP | Yes | +-------+----------------------+-----------+ | E4001 | TOOL_NOT_FOUND | No | +-------+----------------------+-----------+ | E4002 | TOOL_EXEC_FAILED | Yes | +-------+----------------------+-----------+ | E4003 | TOOL_SCHEMA_MISMATCH | No | +-------+----------------------+-----------+ | E5001 | POLICY_DENIED | No | +-------+----------------------+-----------+ | E5002 | UNAUTHORIZED_REF | No | +-------+----------------------+-----------+ | E9999 | INTERNAL_ERROR | Yes | +-------+----------------------+-----------+ Table 6 Error frame example: @agent>fail:error{code:E3001|msg:connection_timed_out|retry:true| schema:ER}[mid:abc,seq:4,ts:1714000001] 3.7. Delivery Semantics Implementations MUST enforce the following delivery guarantees: Benzing Expires 9 October 2026 [Page 11] Internet-Draft ACCP April 2026 1. Idempotency: Decoders MUST maintain a set of seen "msg_id" values per session. Frames with a previously seen "msg_id" MUST be rejected with error E3002 DUPLICATE. 2. Ordering: Frames MUST be processed in ascending "seq" order. A gap in sequence numbers MUST trigger error E3003 SEQUENCE_GAP. 3. Retries: Frames with retryable error codes MAY be retransmitted with the same "correlation_id" and a new "msg_id" and "seq". 4. Cancellation: A "cancel" intent frame referencing a "correlation_id" MUST stop all processing for that request chain. 5. TTL enforcement: Frames received after their TTL has elapsed MUST be rejected silently (no error response, to prevent timing attacks). 4. Intent and Operation Ontology (ACCP-I) 4.1. Core Intents +========+=============+============================================+ | Code | Meaning | Description | +========+=============+============================================+ | req | Request | Request another agent | | | | to perform an action | +--------+-------------+--------------------------------------------+ | done | Complete | Report task completion | | | | with results | +--------+-------------+--------------------------------------------+ | fail | Failure | Report task failure | | | | with error details | +--------+-------------+--------------------------------------------+ | wait | Waiting | Awaiting external | | | | input or dependency | +--------+-------------+--------------------------------------------+ | esc | Escalate | Delegate to a higher- | | | | authority agent | +--------+-------------+--------------------------------------------+ | comp | Compress | Trigger context | | | | compression checkpoint | +--------+-------------+--------------------------------------------+ | sync | Synchronize | Share or request state | | | | synchronization | +--------+-------------+--------------------------------------------+ | qry | Query | Request information | | | | lookup | +--------+-------------+--------------------------------------------+ Benzing Expires 9 October 2026 [Page 12] Internet-Draft ACCP April 2026 | ack | Acknowledge | Confirm receipt of a | | | | frame | +--------+-------------+--------------------------------------------+ | cancel | Cancel | Abort an in-progress | | | | task | +--------+-------------+--------------------------------------------+ | stream | Stream | Begin streaming | | | | incremental results | +--------+-------------+--------------------------------------------+ | end | End stream | Close a streaming | | | | sequence | +--------+-------------+--------------------------------------------+ Table 7 4.2. Standard Key Abbreviations +==============+=====================+ | Abbreviation | Full Meaning | +==============+=====================+ | d | data / dataset | +--------------+---------------------+ | f | findings / fields | +--------------+---------------------+ | nx | next action | +--------------+---------------------+ | src | source | +--------------+---------------------+ | dst | destination | +--------------+---------------------+ | q | query | +--------------+---------------------+ | fmt | format | +--------------+---------------------+ | pri | priority | +--------------+---------------------+ | err | error | +--------------+---------------------+ | v | version | +--------------+---------------------+ | ts | timestamp | +--------------+---------------------+ | ttl | time-to-live | +--------------+---------------------+ | ctx | context reference | +--------------+---------------------+ | who | target agent/entity | +--------------+---------------------+ Benzing Expires 9 October 2026 [Page 13] Internet-Draft ACCP April 2026 | when | temporal constraint | +--------------+---------------------+ | why | rationale code | +--------------+---------------------+ Table 8 4.3. Operation Registry Operations are domain-specific verbs registered in the Schema Registry (Section 6). Core operations: analyze, plan, execute, review, approve, reject, fetch, transform, summarize, classify, generate, validate, schedule, notify, merge, split, route, cache, purge Harnesses MAY register custom operations via the registry extension mechanism. 5. Context State Management (ACCP-S) 5.1. State Hierarchy ACCP defines a three-tier state model: Tier 1: HOT STATE (in-context) Current frame + immediate parent frames. Active task parameters. Max budget: 500 tokens. Tier 2: WARM STATE (compressed summaries) Checkpoint summaries from completed phases. Key-fact extractions. Referenced via $warm.key. Max budget: 200 tokens per checkpoint. Tier 3: COLD STATE (external store) Full conversation history. Raw tool outputs. Referenced via $cold.key. Zero token budget (not injected into context). 5.2. Compression Checkpoints A checkpoint MUST be triggered when ANY of the following conditions are met: 1. An agent completes a task ("done" intent) 2. Accumulated hot state exceeds 400 tokens 3. A handoff between agents occurs ("esc" intent) 4. The harness signals a phase boundary Benzing Expires 9 October 2026 [Page 14] Internet-Draft ACCP April 2026 5. An agent explicitly requests compression ("comp" intent) 5.3. Checkpoint Process 1. Freeze current hot state 2. Extract key facts (entity, value, relationship triples) 3. Generate compressed summary (less than or equal to 100 tokens) 4. Move summary to warm state with checkpoint ID 5. Move raw data to cold state 6. Reset hot state with checkpoint reference 5.4. Delta Encoding After checkpoint N, subsequent frames SHOULD transmit only deltas: @agent>sync:state{v:N+1|delta:{changed_key:new_val,removed_key:null}} The decoder reconstructs full state by applying deltas to the last checkpoint. 6. Schema Registry (ACCP-R) 6.1. Purpose The schema registry allows agents to reference pre-defined data structures by compact codes rather than re-describing them in every message. This eliminates the need to re-inject tool definitions and response schemas into the context window. 6.2. Registry Structure Benzing Expires 9 October 2026 [Page 15] Internet-Draft ACCP April 2026 { "schemas": { "sales_report": { "code": "SR", "version": 1, "fields": ["period", "revenue", "growth_pct", "segments", "notes"], "defaults": { "period": "quarterly", "segments": [] } }, "task_assignment": { "code": "TA", "version": 2, "fields": ["assignee", "task", "priority", "deadline", "deps"], "defaults": { "priority": "medium", "deps": [] } } } } 6.3. Usage in Frames @planner>req:execute{schema:TA|assignee:@dev|task:auth_module| deadline:sprint_14} The decoder expands "schema:TA" into the full field set, populating defaults for omitted fields. 6.4. Registry Negotiation At session start, agents MUST exchange registry versions: @orchestrator>sync:registry{v:3|hash:a7f2c1} If hashes match, no further exchange is needed. On mismatch, the full registry delta is transmitted once and cached. 7. Codec API Specification 7.1. Interface Definition The codec interface defines the following operations that conforming implementations MUST provide: Encode(message, session) -> Frame Encode a structured message into an ACCP Frame Decode(frame, session) -> Message Decode an ACCP Frame back into a structured message Benzing Expires 9 October 2026 [Page 16] Internet-Draft ACCP April 2026 Checkpoint(session) -> CheckpointResult Trigger a compression checkpoint GetBudget(session) -> TokenBudget Get current token budget usage RegisterSchema(name, schema) Register a custom schema 7.2. Encoding Pipeline 1. Schema resolution (expand or compact via registry) 2. Key abbreviation (full keys to abbreviated keys) 3. Value compression (inline values to references if large) 4. Default omission (remove fields matching schema defaults) 5. Token estimation (count via BPE tokenizer) 6. Budget check (within frame limits): if YES, emit single frame; if NO, split into frame sequence or externalize to state 7. Emit ACCP Frame string 7.3. Decoding Pipeline 1. Parse grammar (header, body, metadata) 2. Resolve references ($warm.key, $cold.key, schema codes) 3. Expand abbreviations (abbreviated keys to full keys) 4. Apply schema defaults (fill omitted fields) 5. Reconstruct structured message 6. Return structured message for LLM context injection 8. Conformance Requirements 8.1. Minimum Conformance (Level 1) An implementation MUST support: * Frame encoding/decoding (Section 3) * Core intents (Section 4.1) Benzing Expires 9 October 2026 [Page 17] Internet-Draft ACCP April 2026 * Basic key abbreviations (Section 4.2) 8.2. Standard Conformance (Level 2) An implementation MUST additionally support: * Context state management (Section 5) * Compression checkpoints (Section 5.2) * Schema registry (Section 6) 8.3. Full Conformance (Level 3) An implementation MUST additionally support: * Delta encoding (Section 5.4) * Registry negotiation (Section 6.4) * Token budget enforcement (Section 7.1) * Streaming frames (Section 4.1, "stream"/"end" intents) 9. Security Considerations 1. Opacity risk: Compact formats are harder for humans to audit. Implementations SHOULD provide a "debug mode" that logs decoded human-readable equivalents. 2. Injection: Frame parsing MUST validate grammar strictly. Malformed frames MUST be rejected, not partially parsed. 3. State store access: Cold state references MUST be scoped to the current session. Cross-session state access requires explicit authorization. 4. Registry tampering: Schema registries SHOULD be integrity-checked via hash (Section 6.4). 5. Parser DoS Protection: Decoders MUST implement strict limits on array nesting depth (recommended maximum: 5 levels) and limit payload parsing complexity to prevent resource exhaustion attacks. Benzing Expires 9 October 2026 [Page 18] Internet-Draft ACCP April 2026 10. Domain Profiles A Domain Profile is a named combination of schema codes, intent sequences, and operational patterns optimised for a specific use case. Profiles are additive -- a harness may activate multiple profiles simultaneously. 10.1. Chat Profile (CH) Schema: CH -- fields: role, content, turn, lang, reply_to. Defaults: role=assistant, lang=en. @user>req:chat{content:What_are_Q3_findings?|role:user|turn:1| schema:CH}[mid:...,seq:1] @assistant>done:chat{content:Revenue_declined_12%.|turn:2| schema:CH}[mid:...,seq:2,cid:...] 10.2. Tool / MCP Profile (TC) Schema: TC -- fields: tool_name, arguments, result, status, error_code. Defaults: status=ok. @orchestrator>req:tool{tool:web_search|args:{q:ACCP,max:5}| schema:TC}[mid:m1,seq:1] @tool_agent>done:tool{tool:web_search|res:{hits:[...]}|stat:ok| schema:TC}[mid:m2,seq:2,cid:m1] Tool calls MUST include "correlation_id" in the response to link result to request. Tool errors MUST use schema "ER" with code E4002 TOOL_EXEC_FAILED. 10.3. Transaction Profile (TX) Schema: TX -- fields: transaction_id, amount, currency, account, reference, status, retryable. Defaults: currency=USD, status=pending, retryable=false. @payments>req:transaction{txn:txn_001|amt:142.5|acc:acct_9876| schema:TX}[mid:...,seq:5] @payments>done:transaction{txn:txn_001|stat:settled| schema:TX}[mid:...,seq:6,cid:...] Transaction safety requirements: * "transaction_id" MUST be stable across retries (idempotency key). * "amount" MUST be serialized as decimal (not string) to avoid precision loss. Benzing Expires 9 October 2026 [Page 19] Internet-Draft ACCP April 2026 * "currency" SHOULD follow ISO 4217. * Retries MUST use the same "transaction_id" with a new "msg_id". 10.4. Streaming Profile (ST) Schema: ST -- fields: chunk_index, total_chunks, data, is_final. Defaults: is_final=false. @streamer>stream:infer{idx:0|tot:3|d:Hello| schema:ST}[mid:m1,seq:1,cid:stream_abc] @streamer>stream:infer{idx:1|tot:3|d:_world| schema:ST}[mid:m2,seq:2,cid:stream_abc] @streamer>stream:infer{idx:2|tot:3|d:!|done:true| schema:ST}[mid:m3,seq:3,cid:stream_abc] All chunks in a stream MUST share the same "correlation_id". The final chunk MUST set "is_final=true". Consumers MUST buffer and reorder by "chunk_index" before processing. 10.5. Workflow Profile (TA) Schema: TA -- fields: assignee, task, priority, deadline, deps. Defaults: priority=medium, deps=[]. @planner>req:schedule{asgn:@dev|task:impl_auth|dead:sprint_14| pri:high|schema:TA}[mid:...,seq:8] @dev>done:schedule{task:impl_auth|stat:complete|prog:100| schema:TA}[mid:...,seq:9,cid:...] 11. Transport Bindings ACCP frames are transport-agnostic. The following bindings define how frames are carried over common transports. 11.1. ACCP-over-HTTP * Method: POST /accp/v1/frames * Content-Type: application/accp * Body: One ACCP frame string per request (UTF-8) * Response: 200 OK with response ACCP frame, or 400 with ER-schema error frame body * Streaming: use Transfer-Encoding: chunked with one ST-schema frame per chunk Benzing Expires 9 October 2026 [Page 20] Internet-Draft ACCP April 2026 11.2. ACCP-over-WebSocket * Frame type: text * One ACCP frame string per WebSocket message * Session established by the first sync:registry frame from the initiator * Heartbeat: ping/pong intent frames every 30 seconds 11.3. ACCP-over-MCP * ACCP frames are carried as MCP resource content with MIME type application/accp * Tool calls use the TC profile; results are returned as MCP tool responses containing the TC-schema done:tool frame * Registry sync occurs at MCP session initialization via a sync:registry frame in the system prompt 11.4. ACCP-over-A2A * ACCP frames are embedded as A2A message parts with content type application/accp * A2A task creation maps to ACCP "req" intent; task completion maps to "done" * A2A streaming artifact parts map 1:1 to ST-schema stream frames 12. IANA Considerations This document requests IANA registration of the media type "application/accp" for ACCP frame payloads. 12.1. Media Type Registration Type name: application Subtype name: accp Required parameters: N/A Optional parameters: N/A Encoding considerations: UTF-8 Benzing Expires 9 October 2026 [Page 21] Internet-Draft ACCP April 2026 Security considerations: See Section 9 of this document Interoperability considerations: N/A Published specification: This document 13. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . 14. Informative References [MCP] Anthropic, "Model Context Protocol", 2024. [A2A] Google, "Agent2Agent (A2A) Protocol Specification", 2025. [ACP] IBM, "Agent Communication Protocol (ACP)", 2025. Appendix A. Token Comparison Benchmarks +=================+===========+=============+========+===========+ | Scenario | NL Tokens | JSON Tokens | ACCP | Reduction | | | | | Tokens | | +=================+===========+=============+========+===========+ | Task completion | 85 | 62 | 22 | 74% | | + findings | | | | | +-----------------+-----------+-------------+--------+-----------+ | Task request + | 45 | 38 | 15 | 67% | | params | | | | | +-----------------+-----------+-------------+--------+-----------+ | Error + | 60 | 48 | 18 | 70% | | escalation | | | | | +-----------------+-----------+-------------+--------+-----------+ | State sync (10 | 120 | 95 | 35 | 71% | | fields) | | | | | +-----------------+-----------+-------------+--------+-----------+ Benzing Expires 9 October 2026 [Page 22] Internet-Draft ACCP April 2026 | Full 5-agent | 8,500 | 6,200 | 1,800 | 79% | | pipeline | | | | | +-----------------+-----------+-------------+--------+-----------+ Table 9 Note: Benchmarks are based on empirical validation of Phase 1 implementation. Appendix B. Future Work * Model-specific tokenizer profiles: Optimize encoding per model's BPE vocabulary. * Adaptive compression: ML-based encoder that learns optimal compression per domain. Acknowledgements The author acknowledges the contributions of the broader AI agent protocol community, including the developers of [MCP], [A2A], and [ACP], whose work informed the design of ACCP. Author's Address Russell Benzing Email: me@russellbenzing.com Benzing Expires 9 October 2026 [Page 23]