Agent Context Compression Protocol (ACCP)

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)¶
• 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.¶

2.1. Architecture

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

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.1. Frame Structure

An ACCP Frame is a single-line UTF-8 string defined by the following ABNF grammar ([RFC5234]):¶

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.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: +, -, %, >, <.¶
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

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:¶

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:¶

Standard error codes:¶

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:¶

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.1. Core Intents

4.2. Standard Key Abbreviations

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.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¶
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.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

{
  "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.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¶

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.1. Minimum Conformance (Level 1)

An implementation MUST support:¶

• Frame encoding/decoding (Section 3)¶
• Core intents (Section 4.1)¶
• 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)¶

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.¶
• "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.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¶

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.1. Media Type Registration

Type name:

application¶

Subtype name:

accp¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

UTF-8¶

Security considerations:

See Section 9 of this document¶

Interoperability considerations:

N/A¶

Published specification:

This document¶