Independent Submission A. Mackay Internet-Draft Independent Updates: draft-mackay-aacp-00 (if approved) 30 May 2026 Intended status: Informational Expires: 1 December 2026 Agent Action Compression Protocol (AACP) Version 1.1 draft-mackay-aacp-01 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 transforms verbose natural language coordination instructions into deterministic, typed, machine-parseable packets that can be validated before transmission, logged as structured audit records, and replayed consistently across workflow runs. For known workflow types, a rule-based encoder produces AACP packets deterministically at zero LLM cost. A three-tier fallback encoder extends this to novel instructions: exact matches are served from a local registry cache at zero cost; pattern matches route to rule- based encoding at zero cost; novel instructions are encoded via LLM and logged to the registry, ensuring each novel pattern incurs at most one LLM encoding call regardless of how many times it subsequently appears. As a secondary benefit, AACP reduces coordination token usage by approximately 23 percent versus equivalent natural language instructions, measured against live API tokenisation on Claude Sonnet 4.5 and GPT-4o. Consistent token reduction has been validated across four models: Claude Sonnet 4.5, GPT-4o, GPT-4.1, and GPT-4.1-mini. 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. Mackay Expires 1 December 2026 [Page 1] Internet-Draft AACP May 2026 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 1 December 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 . . . . . . . . . . . . . . 5 4. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Positional Fields . . . . . . . . . . . . . . . . . . . . 6 4.2. Named Fields . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Extended Fields . . . . . . . . . . . . . . . . . . . . . 7 4.4. Packet Examples . . . . . . . . . . . . . . . . . . . . . 7 5. Valid Field Values . . . . . . . . . . . . . . . . . . . . . 7 5.1. TASK Values . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. DOM Values . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Priority Values . . . . . . . . . . . . . . . . . . . . . 8 6. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Rule-Based Encoding . . . . . . . . . . . . . . . . . . . 8 6.2. LLM-Assisted Encoding . . . . . . . . . . . . . . . . . . 8 6.3. Three-Tier Fallback and Registry . . . . . . . . . . . . 9 7. Validation . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Decoding . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Compression Boundaries . . . . . . . . . . . . . . . . . . . 10 10. Tokenisation Benchmark . . . . . . . . . . . . . . . . . . . 10 10.1. Methodology . . . . . . . . . . . . . . . . . . . . . . 10 10.2. Tokenisation Results . . . . . . . . . . . . . . . . . . 10 10.3. Multi-Model Lab Validation . . . . . . . . . . . . . . . 11 Mackay Expires 1 December 2026 [Page 2] Internet-Draft AACP May 2026 10.4. Encoding Cost Comparison . . . . . . . . . . . . . . . . 12 11. Relationship to Existing Protocols . . . . . . . . . . . . . 12 12. Implementation . . . . . . . . . . . . . . . . . . . . . . . 12 13. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 13 14. Version Policy . . . . . . . . . . . . . . . . . . . . . . . 13 15. Security Considerations . . . . . . . . . . . . . . . . . . . 13 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 17.1. Normative References . . . . . . . . . . . . . . . . . . 14 17.2. Informative References . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 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 expensive to tokenise. More significantly, natural language coordination instructions are non-deterministic: the same intent may be expressed differently across runs, making coordination messages difficult to validate, log, replay, or audit. AACP addresses both problems. It replaces natural language coordination instructions with a compact, typed, pipe-delimited packet format that is deterministic, schema-validated, and structured for machine parsing. Consider a four-agent payroll workflow where an orchestrating agent instructs an HRMS agent to retrieve salary records. A typical English instruction: "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. It is verbose, includes pleasantries, and will vary in wording across runs. 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, is produced identically on every run by the rule- based encoder, validates against the v1.1 schema before transmission, and can be logged as a structured audit record without post- processing. Mackay Expires 1 December 2026 [Page 3] Internet-Draft AACP May 2026 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, measured from live API usage_metadata. The rule-based encoder produces all four packets at zero LLM cost. Beyond token reduction, AACP provides: * Deterministic encoding -- identical input produces identical output * Zero-cost encoding for known workflows via rule-based encoders * Schema validation before packet transmission * Structured, machine-readable audit trail without post-processing * Self-improving fallback with registry cache * Model-agnostic format validated across four LLM providers This document specifies AACP version 1.1 and updates draft-mackay- aacp-00 with validated multi-model results, the closed fallback loop specification, and reference to the working open-source implementation. 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 describing what action to take, on what resource, with what parameters, and where to return the result. Distinct from task content. 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. AACP does not reduce task tokens. Mackay Expires 1 December 2026 [Page 4] Internet-Draft AACP May 2026 Coordination tokens: Tokens consumed by the coordination message itself. AACP reduces these by approximately 23 percent versus verbose English. Rule-based encoder: A deterministic encoder producing AACP packets from structured input without an LLM call. Zero API cost per encoding. LLM encoder: An encoder using an LLM API call to compress an English instruction into an AACP packet. Used for novel instructions outside known workflow patterns. Registry: A local store of previously LLM-encoded instructions and their resulting AACP packets, enabling cache lookup on subsequent identical or similar instructions. 3. Motivation and Problem Statement The problem of verbosity in agent communication has been identified independently by multiple research groups. Mou et al. (2025) [ECOLANG] observed that "there exists redundancy in current agent communication" and achieved greater than 20 percent token reduction through evolved compression language for social simulation. AACP addresses the same problem with a typed, portable packet schema targeting business workflow coordination. Beyond verbosity, the non-deterministic nature of natural language coordination creates operational problems at scale. When coordination messages are expressed in free-form English, the same intent produces different messages on different runs. This makes it difficult to validate messages before transmission, correlate messages across runs for audit purposes, or replay workflows reliably. 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, defining what agents say to each other rather than how messages are delivered. At enterprise scale, coordination token overhead is a measurable cost and sustainability concern. Agentic systems consume 5 to 30 times more tokens per task than standard single-turn interactions. In multi-agent workflows, coordination messages compound with every agent hop. For a payroll system processing 500 monthly runs, the coordination token reduction provided by AACP eliminates the cost of 500 LLM encoding calls and reduces input tokens on every coordination hop. Mackay Expires 1 December 2026 [Page 5] Internet-Draft AACP May 2026 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. The following named fields MUST appear in every packet: return: The agent identifier 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. 1=critical, 2=medium (default), 3=low. res: The resource identifier the action applies to. period: A time period, expressed as YYYY-MM or similar. filter: A filter expression applied to the resource. fields: Comma-separated return fields. 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). Mackay Expires 1 December 2026 [Page 6] Internet-Draft AACP May 2026 4.3. Extended Fields Additional named fields MAY be appended after core fields. Defined extended keys include: 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 calculate payroll: MERGE|HR|return:HR-Agent|p:1|aacp:1.1|rules:payroll_v2| validate:budget_cc Flag a legal clause for 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 Process supplier invoice: PROC|FIN|return:FIN-Agent|p:2|aacp:1.1|res:invoice| sup:ABC-Ltd|amt:4200|ccy:GBP|match:PO-441|terms:net30 Write deterministic audit record: LOG|HR|return:AUD-Agent|p:2|aacp:1.1|actor:ORCHESTRATOR| chain:HR-AGENT,FIN-AGENT,HR-AGENT,HR-AGENT| status:review_required 5. Valid Field Values Mackay Expires 1 December 2026 [Page 7] 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. Implementors MAY define additional domain values. Unrecognised DOM values SHOULD generate advisory warnings. 5.3. Priority Values The p: field accepts: 1 (critical), 2 (medium, default), 3 (low). 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 on every run. Reference implementations are provided for the following workflow types in the open-source SDK [AACP-SDK]: * Payroll (PayrollEncoder, 6 coordination hops) * IT Provisioning (ITEncoder, 6 coordination hops) * Invoice Processing (InvoiceEncoder, 3 coordination hops) * Contract Review (ContractEncoder, 3 coordination 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. At current pricing for Claude Sonnet 4.5 this costs approximately $0.0006 USD per instruction. Mackay Expires 1 December 2026 [Page 8] Internet-Draft AACP May 2026 6.3. Three-Tier Fallback and Registry The FallbackEncoder routes encoding requests through three tiers in priority order: Tier 1 -- Hash cache lookup: The SHA-256 hash of the normalised English instruction is looked up in the local registry. An exact match returns the cached packet immediately at zero cost. The times_seen counter is incremented. Tier 2 -- Pattern match: The instruction is matched against keyword patterns from both the registry and a built-in pattern set. A match above the configured threshold returns the cached packet or routes to rule-based encoding, both at zero cost. Tier 3 -- LLM fallback: Novel instructions with no match are encoded via LLM. The result is logged to the registry with extracted keywords, enabling Tier 1 and Tier 2 routing on all subsequent occurrences. This architecture ensures that each novel instruction pattern incurs at most one LLM encoding call regardless of how many times the instruction subsequently appears in the system. The "one LLM call per pattern, reused indefinitely" property has been validated in the reference implementation [AACP-SDK]. 7. Validation AACP validators MUST check: * Field 0 (TASK) is present and recognised * Field 1 (DOM) is present and recognised * 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: present without tone: Mackay Expires 1 December 2026 [Page 9] Internet-Draft AACP May 2026 * ltv: present without ccy: * Unknown extended field keys Validation errors MUST be reported before transmission. 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 or debugging. For audit purposes, the AACP packet itself is the canonical record. Decoded output is advisory. 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 unchanged by AACP. Total workflow cost impact depends on the ratio of coordination to task tokens. 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. 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. The English baseline is the full verbose instruction the AACP packet replaces in production. Benchmark date: May 2026. 10.2. Tokenisation Results Four-hop payroll workflow. Tokens from live API. Mackay Expires 1 December 2026 [Page 10] Internet-Draft AACP May 2026 +---------------------+-------+------+--------+--------+ | 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. Multi-Model Lab Validation A working multi-agent payroll lab [AACP-LAB] validates AACP packet interpretation across four models on a five-hop Q1 FY2026 payroll workflow. The workflow reads from real CSV data files and produces formatted Excel output via agent coordination using AACP packets throughout. +-------------------+---------+-----------+---------+---------+ | Model | Cost | Tokens in | Latency | Success | +-------------------+---------+-----------+---------+---------+ | gpt-4.1-mini | $0.0044 | 7,566 | 82.5s | Y | | gpt-4.1 | $0.0224 | 7,673 | 39.4s | Y | | claude-sonnet-4-5 | $0.0416 | 9,062 | 77.5s | Y | | gpt-4o | $0.0552 | 7,615 | 31.6s | Y | +-------------------+---------+-----------+---------+---------+ All four models correctly interpreted AACP v1.1 packets across all five workflow hops without model-specific prompt tuning. Every packet validated against the v1.1 schema. The deterministic audit agent (Tier 0 -- no LLM call, $0.00) wrote structured audit records on every run. A notable quality difference was observed: Claude Sonnet 4.5 identified anomalies across all four cost centres (8 total) while GPT models identified anomalies in two. For compliance-critical workflows, model selection should consider reasoning depth alongside cost. For coordination-heavy operational workflows where task complexity is low and structured output is the primary requirement, GPT-4.1-mini at $0.0044 per five-hop run provides adequate quality at significantly lower cost. Mackay Expires 1 December 2026 [Page 11] Internet-Draft AACP May 2026 10.4. Encoding Cost Comparison For workflows handled by rule-based encoders, the total encoding cost per workflow run is $0.00 regardless of the number of hops. The LLM fallback encoder costs approximately $0.0006 per novel instruction. Once logged to the registry, the same instruction is subsequently served from cache at $0.00. For comparison, encoding the same four coordination messages via direct LLM call (without AACP rule-based encoding) costs approximately $0.0024 at Claude Sonnet 4.5 pricing. Over 500 monthly payroll runs, the rule-based encoder saves approximately $1.20 in encoding costs alone, in addition to the coordination token reduction on every hop. 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 that describe what to retrieve or action. 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: deterministic, typed encoding of coordination message content. No existing published protocol addresses this specific layer. 12. Implementation A reference implementation of AACP v1.1 is available as an open- source Python package [AACP-SDK]: pip install aacp The package includes the rule-based encoder with four workflow encoder implementations, the three-tier fallback encoder with registry, the schema validator, and a packet decoder. The package is available at https://pypi.org/project/aacp/ and the source is published at https://github.com/MackayAndrew/aacp under the MIT licence. A working multi-agent lab demonstrating AACP coordination across four LLM models is available at https://github.com/MackayAndrew/aacp-lab [AACP-LAB]. Mackay Expires 1 December 2026 [Page 12] Internet-Draft AACP May 2026 13. 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 (e.g. org_fieldname:). Implementors MAY define domain values beyond the seven defined in Section 5.2. A community encoding registry is planned for a future version, enabling shared rule-based patterns across implementors. 14. 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. 15. Security Considerations Packet injection: AACP packets MUST be treated as untrusted input. Validators MUST be applied before processing. Implementations MUST NOT execute actions based on unvalidated packets. Prompt injection: 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. Security-sensitive environments SHOULD add replay protection at the transport layer. Sensitive data: PII, financial records, and credentials MUST NOT be embedded in AACP field values. Use authenticated data access layers referenced by pointer instead. Registry security: the local registry stores previously encoded instructions and their resulting packets. The registry file SHOULD be access-controlled and SHOULD NOT be committed to version control when it contains sensitive workflow instructions. 16. IANA Considerations This document has no IANA actions. Mackay Expires 1 December 2026 [Page 13] Internet-Draft AACP May 2026 17. References 17.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, . 17.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, . [A2A] Google, "Agent-to-Agent Protocol", 2025, . [AACP-SDK] Mackay, A., "AACP Python SDK", Available at https://pypi.org/project/aacp/, 2026, . [AACP-LAB] Mackay, A., "AACP Multi-Agent Lab", Four-model payroll workflow validation. Q1 FY2026 payroll close with Excel output., 2026, . Author's Address Andrew Mackay Independent Email: mackayandrewr@gmail.com URI: https://aacp.dev Mackay Expires 1 December 2026 [Page 14]