Agent Action Compression Protocol (AACP) Version 1.4

Abstract

This document defines the Agent Action Compression Protocol (AACP), a typed coordination format for agent-to-agent communication in multi-agent large language model (LLM) systems. AACP transforms natural language coordination instructions into deterministic, machine-parseable packets that can be validated before transmission, logged as structured audit records, and replayed consistently across workflow runs.¶

AACP addresses a coordination content layer that existing agent protocols do not cover. The Model Context Protocol (MCP) and Agent-to-Agent Protocol (A2A) operate at the tool access and routing layers respectively. Neither specifies what agents say to each other inside coordination messages. AACP fills this gap with a shared, typed vocabulary for agent coordination intent.¶

For known workflow types, a rule-based encoder produces AACP packets deterministically at zero LLM cost. A four-tier fallback extends this to novel instructions: community registry lookup at zero cost; local cache lookup at zero cost; pattern matching at zero cost; LLM encoding for genuinely novel instructions, logged to registry for permanent reuse. An amortisation benchmark across 240 encoding operations demonstrated 91.6 percent cost saving versus per-call LLM encoding, with 6 LLM calls required across the full run.¶

As a secondary benefit, AACP reduces coordination token usage by approximately 23 percent versus equivalent natural language instructions. Framework integration benchmarks demonstrate 18 percent total workflow cost reduction in LangChain (59 coordination hops) and 30 percent in CrewAI (59 coordination hops), with all coordination LLM calls eliminated in both cases.¶

This document updates draft-mackay-aacp-01 with: an expanded encoder library (8 workflow encoders across 6 domains); a community rule library (241 validated rules at registry.aacp.dev); framework integration results for LangChain and CrewAI; amortisation benchmark data; and a five-workflow multi-model department day validation.¶

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 non-deterministic. The same intent expressed differently across runs makes coordination messages difficult to validate, audit, or replay reliably.¶

AACP replaces natural language coordination with a compact, typed, pipe-delimited packet format that is deterministic, schema-validated, and machine-parseable. The primary value is not token reduction -- it is auditability, determinism, and the elimination of LLM calls from the coordination layer for known workflow types.¶

Consider a payroll workflow where an orchestrator instructs an HR agent to retrieve salary records. A typical English instruction:¶

"Please retrieve the employee salary records for the period
ending March 2026. 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 varies in wording across runs, provides no machine-readable structure, and cannot be reliably audited without natural language processing. The equivalent AACP packet:¶

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

is produced identically on every run by the rule-based encoder, validates against the v1.1 schema before transmission, and constitutes a complete machine-readable audit record. The rule-based encoder produces this packet at zero LLM cost.¶

This document specifies AACP version 1.4 and updates draft-mackay-aacp-01 with expanded encoder coverage, community rule library, framework integration results, amortisation benchmark, and department day validation.¶

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 coordination packets, performs tasks using one or more LLM API calls, and returns structured 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.¶

Coordination tokens:

Tokens consumed by the coordination message itself.¶

Rule-based encoder:

A deterministic encoder producing AACP packets from structured input without an LLM call. Zero API cost per encoding.¶

Community registry:

A curated set of pre-validated AACP rules for common business workflow patterns, available for zero-cost lookup before LLM fallback is attempted.¶

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

Natural language coordination in multi-agent systems creates three distinct operational problems: verbosity, non-determinism, and unstructured audit trails.¶

Verbosity has been identified independently by multiple research groups. Mou et al. (2025) [ECOLANG] 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.¶

Non-determinism is the more operationally significant problem. When coordination messages are expressed in free-form natural language, the same intent produces different messages across runs. This makes it impossible to validate messages before transmission, correlate messages across runs for compliance 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.¶

Framework integration benchmarks confirm the problem is real and widespread. In standard LangChain and CrewAI implementations, every agent-to-agent coordination hop involves an LLM call to generate the instruction. In a five-workflow department day scenario with 59 coordination hops, this results in 59 LLM calls solely for coordination -- before any task work begins. AACP eliminates all 59 coordination calls for known workflows.¶

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

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

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

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

CALC|SALES|return:SALES-Agent|p:1|aacp:1.1|res:lead_score|
filter:id=L-001|rules:bant

RESOLVE|CS|return:CS-Agent|p:1|aacp:1.1|res:complaint|
filter:id=T-001|sentiment:negative|tone:empathetic|
ltv:8500|ccy:GBP|req:resolve,goodwill_consider

ACK|IT|return:IT-Agent|p:1|aacp:1.1|res:incident_ticket|
status:acknowledged

5. Valid Field Values

6. Encoding

GET https://registry.aacp.dev/rules?domain=HR&task=FETCH

{
  "total": 10,
  "rules": [
    {
      "id": "hr-fetch-active-employee-salaries",
      "packet": "FETCH|HR|return:HR-Agent|p:1|aacp:1.1|
                 res:emp_salary|filter:status=active|fmt:json",
      "validated": true
    },
    ...
  ]
}

from aacp import RuleRegistry

registry = RuleRegistry.from_community()
rule = registry.find("fetch active employee salaries", domain="HR")
print(rule.packet)
# FETCH|HR|return:HR-Agent|p:1|aacp:1.1|res:emp_salary|
#   filter:status=active|fmt:json
print(rule.cost)  # 0.0

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:¶
• 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. Tokenisation Benchmark

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

+---------------------------+--------+----------+----------+
| Scenario                  | Calls  | LLM Calls| Saving   |
+---------------------------+--------+----------+----------+
| A: 1 instruction x 30     |     30 |         1|    96.7% |
| B: 5 instructions x 30    |    150 |         4|    91.0% |
| C: Rule-based vs novel    |     60 |         1|    94.4% |
+---------------------------+--------+----------+----------+
| TOTAL                     |    240 |         6|    91.6% |
+---------------------------+--------+----------+----------+

+-------------------+---------+-----------+---------+---------+
| Model             | Cost    | Tokens in | Latency | Success |
+-------------------+---------+-----------+---------+---------+
| gpt-4.1-mini      | $0.0190 |    40,585 |   160s  |  5/5    |
| gpt-4.1           | $0.0984 |    41,005 |   124s  |  5/5    |
| claude-sonnet-4-5 | $0.2237 |    53,127 |   423s  |  5/5    |
| gpt-4o            | $0.2408 |    40,459 |   101s  |  5/5    |
+-------------------+---------+-----------+---------+---------+

+------------+------+----------------+----------+--------------+
| Framework  | Hops | Coord. Calls   | Saving   | Determinism  |
+------------+------+----------------+----------+--------------+
| LangChain  |   59 | 59 -> 0        |     18%  | YES          |
| CrewAI     |   59 | 59 -> 0        |     30%  | YES          |
+------------+------+----------------+----------+--------------+

9. 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 between routing and task execution: deterministic, typed encoding of coordination message content. No existing published protocol addresses this specific layer.¶

10. Implementation

A reference implementation is available as a Python package [AACP-SDK]:¶

pip install aacp            # Python SDK v1.4.0
npm install aacp-ts         # TypeScript SDK v1.4.0
pip install aacp-langchain  # LangChain integration v0.1.0
pip install aacp-crewai     # CrewAI integration v0.1.0

Source repositories, the working lab, community rule library, VS Code extension, and registry API are listed in the Informative References section.¶

11. Extensibility

Unknown named fields generate advisory warnings, not errors. Implementors MAY define organisation-private fields using a namespacing convention (e.g. org_fieldname:) to avoid collision with future AACP fields.¶

Implementors MAY define domain values beyond the seven defined in Section 5.2. The community registry at registry.aacp.dev provides a shared rule library for common workflow patterns. A commercial registry tier supporting private organisation rules is planned.¶

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

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

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 SHOULD be access-controlled and SHOULD NOT be committed to version control when it contains sensitive workflow instructions.¶

14. IANA Considerations

This document has no IANA actions.¶

15. References