Agent Action Compression Protocol (AACP) Version 1.1

Internet-Draft	AACP	May 2026
Mackay	Expires 29 November 2026	[Page]

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

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 29 November 2026.¶

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

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

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

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

4.4. Packet Examples

Fetch active employee salary records:¶

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

Merge datasets and run payroll calculation:¶

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

Flag a legal clause for senior review:¶

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

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

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

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

5.3. Priority Values

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

6. Encoding

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

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

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

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

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

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

10.2. Results

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

+---------------------+-------+------+--------+--------+
| 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% |
+---------------------+-------+------+--------+--------+

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

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