Agent Action Compression Protocol (AACP) Version 1.1
draft-mackay-aacp-00

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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

16.2.  Informative References

   [ECOLANG]  Mou, Y., "EcoLANG: Towards Efficient Agent Communication
              via Evolved Language", arXiv:2505.06904, May 2025,
              <https://arxiv.org/abs/2505.06904>.

   [MCP]      Anthropic, "Model Context Protocol", 2024,
              <https://modelcontextprotocol.io/>.

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

   [A2A]      Google, "Agent-to-Agent Protocol", 2025,
              <https://google.github.io/A2A/>.

Author's Address

   Andrew Mackay
   Independent
   Email: mackayandrewr@gmail.com
   URI:   https://aacp.dev

Mackay                  Expires 29 November 2026               [Page 12]