Agent Action Compression Protocol (AACP) Version 1.4

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

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

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) 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 nor 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.

Packet Format An AACP packet is a sequence of pipe-delimited fields. The pipe character (U+007C, "|") is the field separator. 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.

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.

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.
fmt:: The requested response format (e.g. json, pdf, xlsx).

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.

Packet Examples Fetch active employee salary records: Merge datasets and calculate payroll: Flag a legal clause for review: Score a sales lead using BANT: Resolve a customer complaint with goodwill consideration: Acknowledge receipt and confirm SLA clock started:

Valid Field Values

TASK Values The following TASK values are defined in AACP v1.1: FETCH, PROC, FLAG, RESOLVE, LOG, SEND, BUILD, MERGE, CALC, REPORT, ACK, SYNC. All 12 TASK values are represented in the community rule library with validated usage examples across 7 business domains. Implementations MUST warn on unrecognised TASK values. Implementations MUST NOT reject packets with unrecognised TASK values, to permit forward compatibility.

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.

Priority Values The p: field accepts: 1 (critical), 2 (medium, default), 3 (low).

Encoding

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. The reference implementation provides eight workflow encoders across six domains, each grounded in a documented real-world platform:

PayrollEncoder -- HR payroll (HMRC PAYE, 6 hops)
ITEncoder -- IT provisioning (Microsoft Entra ID, 5 hops)
InvoiceEncoder -- AP processing (three-way match, 3 hops)
ContractEncoder -- Legal review (NDA/MSA, 2-3 hops)
SalesEncoder -- Lead qualification (Salesforce Agentforce 2026, 5 hops)
JMLEncoder -- HR onboarding (ConductorOne, Lumos, 6 hops)
CSResolutionEncoder -- CS resolution (Zendesk 2026, 5 hops)
MonthEndEncoder -- Finance close (NetSuite Autonomous Close 2026, 6 hops)

Community Rule Library A community rule library of 241 pre-validated AACP coordination rules is available covering all 12 TASK types across all 7 DOM values. The library is MIT-licensed and hosted at registry.aacp.dev as a queryable REST API. Example query: The RuleRegistry class in the SDK provides programmatic access to the community library:

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.

Four-Tier Fallback and Registry The FallbackEncoder routes encoding requests through four tiers in priority order: Tier 0 -- Community registry: The instruction is matched against the community rule library. A match returns the pre-validated packet at zero cost. Tier 1 -- Hash cache lookup: The SHA-256 hash of the normalised instruction is looked up in the local registry. An exact match returns the cached packet at zero cost. Tier 2 -- Pattern match: The instruction is matched against keyword patterns from the registry and built-in pattern set. A match above threshold returns the cached or rule-based packet at zero cost. Tier 3 -- LLM fallback: Novel instructions with no match are encoded via LLM and logged to the local registry, enabling Tier 1 routing on all subsequent occurrences. This architecture ensures each novel instruction pattern incurs at most one LLM encoding call. An amortisation benchmark across 240 encoding operations (6 novel instructions, each repeated 30 times, plus rule-based comparisons) demonstrated 91.6 percent cost saving versus per-call LLM encoding, with 6 LLM calls required across the full benchmark run.

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.

Tokenisation Benchmark

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. Benchmark date: May 2026.

Tokenisation Results Four-hop payroll workflow. Tokens from live API.

Amortisation Benchmark A three-scenario amortisation benchmark validated the "one LLM call per novel pattern" property across 240 encoding operations. June 2026. In Scenario B, the first instruction had been encoded in Scenario A and was served from cache at zero cost across all 30 repetitions. Four new instructions each required one LLM call and zero cost on all subsequent calls.

Department Day Multi-Model Validation A five-workflow department day lab validated AACP packet interpretation across four LLM models. The lab runs payroll, month-end close, sales qualification, customer service resolution, and JML onboarding workflows using real CSV data. June 2026. All four models correctly interpreted AACP v1.1 packets across all five workflows and 76 coordination hops per model run without model-specific prompt tuning. Every packet validated against the v1.1 schema. The deterministic audit agent wrote structured records at zero LLM cost on every run.

Framework Integration Benchmarks AACP was integrated into two leading agent frameworks and benchmarked against standard natural language coordination on an equivalent five-workflow, 59-hop department day scenario. June 2026. 0 | 18% | YES | | CrewAI | 59 | 59 -> 0 | 30% | YES | +------------+------+----------------+----------+--------------+ ]]> In both cases, all 59 coordination LLM calls were eliminated. The higher saving in CrewAI reflects its more verbose default natural language task descriptions. In both frameworks, coordination messages became deterministic, schema-validated, and machine-readable audit records. Reference implementations are available as and .

Relationship to Existing Protocols 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 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.

Implementation A reference implementation is available as a Python package : Source repositories, the working lab, community rule library, VS Code extension, and registry API are listed in the Informative References section.

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.

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.

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.

IANA Considerations This document has no IANA actions.