Agent Action Compression Protocol (AACP) Version 1.1

Abstract

This document defines the Agent Action Compression Protocol (AACP), a pipe-delimited coordination format for agent-to-agent communication in multi-agent large language model (LLM) systems. AACP replaces verbose natural language instructions exchanged between autonomous agents with a compact, structured, machine-parseable packet format.¶

Measured against live API tokenisation on Claude Sonnet 4.5 and GPT-4o, AACP reduces coordination token usage by approximately 23 percent versus equivalent natural language instructions across a four-hop payroll workflow benchmark.¶

AACP operates above transport protocols such as the Model Context Protocol (MCP) and Agent-to-Agent Protocol (A2A), compressing message payload content rather than addressing routing or delivery. The protocol is transport-agnostic, model-agnostic, and designed to complement rather than replace existing agent coordination infrastructure.¶

1. Introduction

Multi-agent LLM systems coordinate by exchanging instructions between autonomous agents. In current implementations, these coordination messages are typically written in natural language -- verbose, ambiguous, and token-expensive.¶

Consider a four-agent payroll workflow where an orchestrating agent must instruct an HRMS agent to retrieve salary records. A typical English instruction might read:¶

"Please retrieve the employee salary records for the period
ending 31 August 2024. I need all active employees, their
departments, cost centres, base salary, any changes made this
month, and pension contribution rates. Return as JSON array."

This instruction consumes 56 tokens on Claude Sonnet 4.5. The equivalent AACP packet:¶

FETCH|HR|return:HR-Agent|p:1|aacp:1.1|res:emp_salary|
period:2024-08|filter:status=active|fmt:json

consumes 52 tokens -- a 7.1 percent reduction on this hop alone, with larger reductions observed on hops with longer instructions (33.8 percent on a MERGE instruction). Across a four-hop payroll workflow the total coordination token reduction is 22.9 percent on Claude Sonnet 4.5 and 23.7 percent on GPT-4o.¶

Beyond token reduction, AACP provides:¶

• Unambiguous, machine-parseable coordination messages¶
• Schema validation before transmission¶
• Deterministic encoding for known workflow types¶
• Structured audit trails for compliance purposes¶
• Model-agnostic format interpretable across LLM providers¶

This document specifies AACP version 1.1.¶

2. 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 all capitals, as shown here.¶

Agent:

An autonomous software process that receives instructions, performs tasks using one or more LLM API calls, and returns results.¶

Coordination message:

An instruction sent from one agent to another that describes what action to take, on what resource, with what parameters, and where to return the result. Distinct from task content (the actual work the receiving agent performs).¶

AACP packet:

A pipe-delimited string conforming to the format defined in Section 4, used as a coordination message.¶

Task tokens:

Tokens consumed by an agent performing its actual work (reading documents, generating reports, analysing data). AACP does not compress task tokens.¶

Coordination tokens:

Tokens consumed by the coordination message itself. AACP compresses these.¶

Rule-based encoder:

A deterministic encoder that produces AACP packets from structured input without an LLM call. Zero API cost.¶

LLM encoder:

An encoder that uses an LLM API call to compress an English instruction into an AACP packet. Used for novel instructions outside known workflow patterns.¶

3. Motivation and Problem Statement

The problem of verbosity in agent communication has been independently identified in published research. Mou et al. (2025) [ECOLANG] observed that "there exists redundancy in current agent communication: when expressing the same intention, agents tend to use lengthy and repetitive language" and achieved greater than 20 percent token reduction through evolved compression language for social simulation.¶

AACP addresses the same observed problem with a different approach: a structured, typed packet schema targeting business workflow coordination rather than evolved natural language compression.¶

The specific technical gap AACP fills: neither MCP [MCP] nor A2A [A2A] address the semantic content of coordination messages. Both protocols operate at the transport and routing layers. AACP operates at the content layer, compressing what agents say to each other rather than how messages are delivered.¶

4. Packet Format

An AACP packet is a sequence of pipe-delimited fields. The pipe character (U+007C, "|") is the field separator.¶

packet = task "|" dom "|" named-fields

TASK and DOM are positional (fields 0 and 1 respectively). All other fields MUST be named key:value pairs. Empty positional slots MUST NOT appear in v1.1 packets.¶

FETCH|HR|return:HR-Agent|p:1|aacp:1.1|res:emp_salary|
period:2024-08|filter:status=active|fmt:json

MERGE|HR|return:HR-Agent|p:1|aacp:1.1|rules:payroll_v2|
validate:budget_cc

FLAG|LEGAL|return:LEG-Agent|p:1|aacp:1.1|type:NDA|
party:Acme-Ltd|clause:s7|issue:ip_rights_restriction|
risk:high|block:signature

BUILD|IT|return:IT-Agent|p:1|aacp:1.1|res:ad_account|
filter:usr=j.smith|fields:email,dept,grp,pwd_reset

5. Valid Field Values

6. Encoding

7. Validation

AACP validators MUST check the following:¶

• Field 0 (TASK) is present and is a recognised TASK value¶
• Field 1 (DOM) is present and is a recognised DOM value¶
• A return: named field is present and non-empty¶
• An aacp: named field is present¶

AACP validators SHOULD warn on:¶

• Unrecognised TASK or DOM values¶
• Missing p: field¶
• AACP version mismatch¶
• sentiment: field present without tone: field¶
• ltv: field present without ccy: field¶
• Unknown extended field keys¶

Validation errors MUST be reported before packet transmission. Validation warnings SHOULD be logged but MUST NOT prevent transmission.¶

8. Decoding

AACP packets are designed to be human-readable as written. Decoders MAY expand packets into structured English for audit purposes, user interfaces, or debugging.¶

For audit purposes, the AACP packet itself is the canonical record. Decoded English output is advisory only.¶

9. Compression Boundaries

Coordination tokens compress well: routing instructions, resource references, structured intent, action verbs, and metadata are efficiently expressed in AACP.¶

Task tokens do not compress: the actual work an agent performs is expressed in task content passed alongside the coordination packet. AACP does not and cannot compress task tokens.¶

Emotional and relational context compresses poorly. Implementors SHOULD use AACP for routing and metadata in these cases and pass full English context in the task content field.¶

Total workflow cost impact depends on the ratio of coordination to task tokens. Coordination-heavy workflows benefit most.¶

10. Tokenisation Benchmark

+---------------------+-------+------+--------+--------+
| Hop                 |English| AACP |Claude% |GPT-4o% |
+---------------------+-------+------+--------+--------+
| fetch employees     |    56 |   52 |  -7.1% | -12.7% |
| fetch budgets       |    57 |   47 | -17.5% | -16.0% |
| merge and calculate |    65 |   43 | -33.8% | -31.6% |
| generate report     |    62 |   43 | -30.6% | -33.3% |
+---------------------+-------+------+--------+--------+
| TOTAL               |   240 |  185 | -22.9% | -23.7% |
+---------------------+-------+------+--------+--------+

11. Relationship to Existing Protocols

MCP [MCP] defines how agents access external tools and resources. AACP operates inside MCP message payloads, compressing the coordination instructions. The two protocols are complementary.¶

A2A [A2A] defines agent discovery and task routing between agents. AACP compresses the content of messages that A2A routes. The two protocols are complementary.¶

AACP fills a distinct layer: semantic compression of coordination message content. No existing published protocol addresses this specific layer.¶

12. Extensibility

Unknown named fields generate advisory warnings, not errors. Implementors MAY define organisation-private fields using a namespacing convention to avoid collision with future AACP fields.¶

Implementors MAY define domain values beyond the seven defined in Section 5.2. A community encoding registry is planned for v2.0.¶

13. Version Policy

The aacp: field MUST be included in every packet and MUST specify the protocol version. Breaking changes increment the major version. Additive changes increment the minor version. Implementations SHOULD warn on version mismatch but MUST NOT reject packets on version mismatch alone.¶

14. Security Considerations

Packet injection: AACP packets are plain text and MUST be treated as untrusted input. Validators MUST be applied to all received packets before processing. Implementations MUST NOT execute actions based on unvalidated packets.¶

Prompt injection via packets: malicious content in AACP field values could be interpreted as instructions by a receiving LLM agent. Implementations SHOULD sanitise field values before including them in LLM prompts. Field values SHOULD be treated as data, not instructions.¶

Replay attacks: AACP v1.1 does not include sequence numbers or timestamps. Implementations operating in security-sensitive environments SHOULD add replay protection at the transport layer.¶

Sensitive data in packets: sensitive data (PII, financial records, credentials) MUST NOT be embedded in AACP field values. Use data pointer references (data_ptr:) that resolve through authenticated data access layers instead.¶

15. IANA Considerations

This document has no IANA actions.¶

16. References