Agent Action Compression Protocol (AACP) Version 1.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: This instruction consumes 56 tokens on Claude Sonnet 4.5. The equivalent AACP packet: 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.

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

Motivation and Problem Statement The problem of verbosity in agent communication has been independently identified in published research. Mou et al. (2025) 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 nor 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.

Packet Format An AACP packet is a sequence of pipe-delimited fields. The pipe character (U+007C, "|") is the field separator. 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.

Positional Fields

Field 0 -- TASK:: The action verb. REQUIRED. MUST be one of the values defined in Section 5.1.
Field 1 -- DOM:: The business domain context. REQUIRED. MUST be one of the values defined in Section 5.2.

Named Fields After the two positional fields, all fields are named using the format key:value where key is a lowercase ASCII string and value is the field content. The following named fields MUST appear in every packet:

return:: The agent identifier or role that receives the result. REQUIRED.
aacp:: The protocol version. REQUIRED. MUST be "1.1" for packets conforming to this specification.

The following named fields are RECOMMENDED where applicable:

p:: Priority. Values: 1 (critical), 2 (medium), 3 (low). Defaults to 2 if omitted.
res:: The resource identifier the action applies to.
period:: A time period for the action, expressed as YYYY-MM or similar abbreviated form.
filter:: A filter expression applied to the resource.
fields:: Comma-separated list of return fields requested. SHOULD be omitted when the receiving agent has default field definitions in its system configuration.
fmt:: The requested response format (e.g. json, pdf, xlsx).

Extended Fields Additional named fields MAY be appended after the core fields. The following extended field keys are defined in this version: src, src_prev, rules, validate, tmpl, data_ptr, amt, ccy, sup, match, terms, type, party, clause, issue, risk, block, flags, req, highlight, status, to, subj, att, flag_msg, tone, sentiment, actor, chain, prog, ltv, loyalty, urgency. Unknown extended keys MUST generate advisory warnings in validators, not errors. This permits forward compatibility and organisation-private extensions.

Packet Examples Fetch active employee salary records: Merge datasets and run payroll calculation: Flag a legal clause for senior review: Build IT user account:

Valid Field Values

TASK Values The following TASK values are defined in AACP v1.1: FETCH, PROC, FLAG, RESOLVE, LOG, SEND, BUILD, MERGE, CALC, REPORT, ACK, SYNC. Implementations MUST warn on unrecognised TASK values. Implementations MUST NOT reject packets with unrecognised TASK values, to permit forward compatibility.

DOM Values The following DOM values are defined in AACP v1.1: HR, FIN, SALES, LEGAL, IT, CS, MKT. Domain extensions MAY be defined by implementors. Unrecognised DOM values SHOULD generate advisory warnings.

Priority Values The p: field accepts the following values: 1 (critical -- process immediately), 2 (medium -- standard processing, default), 3 (low -- process when capacity allows).

Encoding

Rule-Based Encoding For known, repetitive workflow types, a rule-based encoder deterministically produces AACP packets from structured input without an LLM API call. This approach has zero API cost and produces identical output for identical input. Reference implementations are provided for: Payroll (PayrollEncoder, 6 coordination hops), IT Provisioning (ITEncoder, 6 hops), Invoice Processing (InvoiceEncoder, 3 hops), and Contract Review (ContractEncoder, 3 hops).

LLM-Assisted Encoding For novel instructions outside known workflow patterns, an LLM-assisted encoder produces AACP packets by submitting the English instruction to a language model with the AACP specification as a system prompt.

Fallback and Registry A fallback encoder routes structured input to rule-based encoding and English input to LLM-assisted encoding. Every LLM-assisted encoding call is logged to a local registry as a candidate for future rule-based encoding. This creates a self-improving loop: novel patterns are encoded once via LLM and subsequently encoded deterministically at zero cost.

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.

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.

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.

Tokenisation Benchmark

Methodology Coordination token counts were measured using live API usage_metadata. Each message was submitted as a bare user message with no system prompt and max_tokens=1 to isolate coordination token counts. English baseline is the full verbose instruction the AACP packet replaces in production. Benchmark date: May 2026.

Results Four-hop payroll workflow. Token counts from live API.

Findings AACP v1.1 pipe-delimited format achieves consistent coordination token reduction across both tested models and all four workflow hops. Four formats were evaluated before selecting pipe-delimited. The bracket-based [KEY:VALUE] format increased token count by approximately 45 percent on Claude versus English, due to the tokenisation cost of bracket and colon characters. Embedding field lists and URI data pointers in packets increases token count significantly and SHOULD be avoided where the receiving agent has default field definitions in its system configuration.

Relationship to Existing Protocols 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 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.

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.

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.

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.

IANA Considerations This document has no IANA actions.