Independent Submission A. Mackay Internet-Draft Independent Intended status: Informational 28 May 2026 Expires: 29 November 2026 Agent Action Compression Protocol (AACP) Version 1.1 draft-mackay-aacp-00 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. Mackay Expires 29 November 2026 [Page 1] Internet-Draft AACP May 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation and Problem Statement . . . . . . . . . . . . . . 4 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Positional Fields . . . . . . . . . . . . . . . . . . . . 5 4.2. Named Fields . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Extended Fields . . . . . . . . . . . . . . . . . . . . . 6 4.4. Packet Examples . . . . . . . . . . . . . . . . . . . . . 6 5. Valid Field Values . . . . . . . . . . . . . . . . . . . . . 6 5.1. TASK Values . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. DOM Values . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Priority Values . . . . . . . . . . . . . . . . . . . . . 7 6. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Rule-Based Encoding . . . . . . . . . . . . . . . . . . . 7 6.2. LLM-Assisted Encoding . . . . . . . . . . . . . . . . . . 7 6.3. Fallback and Registry . . . . . . . . . . . . . . . . . . 8 7. Validation . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Decoding . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Compression Boundaries . . . . . . . . . . . . . . . . . . . 9 10. Tokenisation Benchmark . . . . . . . . . . . . . . . . . . . 9 10.1. Methodology . . . . . . . . . . . . . . . . . . . . . . 9 10.2. Results . . . . . . . . . . . . . . . . . . . . . . . . 9 10.3. Findings . . . . . . . . . . . . . . . . . . . . . . . . 10 11. Relationship to Existing Protocols . . . . . . . . . . . . . 10 12. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 10 13. Version Policy . . . . . . . . . . . . . . . . . . . . . . . 10 14. Security Considerations . . . . . . . . . . . . . . . . . . . 11 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 16.1. Normative References . . . . . . . . . . . . . . . . . . 11 16.2. Informative References . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Mackay Expires 29 November 2026 [Page 2] Internet-Draft AACP May 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. Mackay Expires 29 November 2026 [Page 3] Internet-Draft AACP May 2026 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. Mackay Expires 29 November 2026 [Page 4] Internet-Draft AACP May 2026 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. Mackay Expires 29 November 2026 [Page 5] Internet-Draft AACP May 2026 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 Mackay Expires 29 November 2026 [Page 6] Internet-Draft AACP May 2026 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. Mackay Expires 29 November 2026 [Page 7] Internet-Draft AACP May 2026 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. 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. Mackay Expires 29 November 2026 [Page 8] Internet-Draft AACP May 2026 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% | +---------------------+-------+------+--------+--------+ Mackay Expires 29 November 2026 [Page 9] Internet-Draft AACP May 2026 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. 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. Mackay Expires 29 November 2026 [Page 10] Internet-Draft AACP May 2026 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 16.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . 16.2. Informative References [ECOLANG] Mou, Y., "EcoLANG: Towards Efficient Agent Communication via Evolved Language", arXiv:2505.06904, May 2025, . [MCP] Anthropic, "Model Context Protocol", 2024, . Mackay Expires 29 November 2026 [Page 11] Internet-Draft AACP May 2026 [A2A] Google, "Agent-to-Agent Protocol", 2025, . Author's Address Andrew Mackay Independent Email: mackayandrewr@gmail.com URI: https://aacp.dev Mackay Expires 29 November 2026 [Page 12]