Agent Action Compression Protocol (AACP) Version 1.4
draft-mackay-aacp-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Andrew Mackay | ||
| Last updated | 2026-06-17 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mackay-aacp-03
Independent Submission A. Mackay
Internet-Draft Independent
Updates: draft-mackay-aacp-02 (if approved) 17 June 2026
Intended status: Informational
Expires: 19 December 2026
Agent Action Compression Protocol (AACP) Version 1.4
draft-mackay-aacp-03
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-02 with: framework
integration results for AutoGen (55 percent total cost reduction, 59
coordination hops) and Pydantic AI (85 percent total cost reduction,
59 coordination hops); a four-framework comparison demonstrating that
AACP saving scales with framework coordination verbosity; a new
Mackay Expires 19 December 2026 [Page 1]
Internet-Draft AACP June 2026
framing for typed-result frameworks showing that AACP completes the
determinism picture by adding typed instructions to complement
existing typed results; and publication of five packages on PyPI and
npm covering all four frameworks.
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 19 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 . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Positional Fields . . . . . . . . . . . . . . . . . . . . 6
4.2. Named Fields . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Extended Fields . . . . . . . . . . . . . . . . . . . . . 6
4.4. Packet Examples . . . . . . . . . . . . . . . . . . . . . 6
5. Valid Field Values . . . . . . . . . . . . . . . . . . . . . 7
5.1. TASK Values . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. DOM Values . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Priority Values . . . . . . . . . . . . . . . . . . . . . 8
6. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Mackay Expires 19 December 2026 [Page 2]
Internet-Draft AACP June 2026
6.1. Rule-Based Encoding . . . . . . . . . . . . . . . . . . . 8
6.2. Community Rule Library . . . . . . . . . . . . . . . . . 8
6.3. LLM-Assisted Encoding . . . . . . . . . . . . . . . . . . 9
6.4. Four-Tier Fallback and Registry . . . . . . . . . . . . . 9
7. Validation . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Tokenisation Benchmark . . . . . . . . . . . . . . . . . . . 10
8.1. Methodology . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. Tokenisation Results . . . . . . . . . . . . . . . . . . 11
8.3. Amortisation Benchmark . . . . . . . . . . . . . . . . . 11
8.4. Department Day Multi-Model Validation . . . . . . . . . . 12
8.5. Framework Integration Benchmarks . . . . . . . . . . . . 12
9. Relationship to Existing Protocols . . . . . . . . . . . . . 13
10. Implementation . . . . . . . . . . . . . . . . . . . . . . . 13
11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 13
12. Version Policy . . . . . . . . . . . . . . . . . . . . . . . 14
13. Security Considerations . . . . . . . . . . . . . . . . . . . 14
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
15.1. Normative References . . . . . . . . . . . . . . . . . . 14
15.2. Informative References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
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:
Mackay Expires 19 December 2026 [Page 3]
Internet-Draft AACP June 2026
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
Mackay Expires 19 December 2026 [Page 4]
Internet-Draft AACP June 2026
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.
Mackay Expires 19 December 2026 [Page 5]
Internet-Draft AACP June 2026
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.
fmt: The requested response format (e.g. json, pdf, xlsx).
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:
Mackay Expires 19 December 2026 [Page 6]
Internet-Draft AACP June 2026
FETCH|HR|return:HR-Agent|p:1|aacp:1.1|res:emp_salary|
period:2026-03|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
Score a sales lead using BANT:
CALC|SALES|return:SALES-Agent|p:1|aacp:1.1|res:lead_score|
filter:id=L-001|rules:bant
Resolve a customer complaint with goodwill consideration:
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
Acknowledge receipt and confirm SLA clock started:
ACK|IT|return:IT-Agent|p:1|aacp:1.1|res:incident_ticket|
status:acknowledged
5. Valid Field Values
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.
All 12 TASK values are represented in the community rule library
[AACP-RULES] 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.
5.2. DOM Values
The following DOM values are defined in AACP v1.1: HR, FIN, SALES,
LEGAL, IT, CS, MKT.
Mackay Expires 19 December 2026 [Page 7]
Internet-Draft AACP June 2026
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.
The reference implementation [AACP-SDK] 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)
6.2. Community Rule Library
A community rule library [AACP-RULES] 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:
Mackay Expires 19 December 2026 [Page 8]
Internet-Draft AACP June 2026
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
},
...
]
}
The RuleRegistry class in the SDK provides programmatic access to the
community library:
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
6.3. 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.
6.4. 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.
Mackay Expires 19 December 2026 [Page 9]
Internet-Draft AACP June 2026
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.
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
Mackay Expires 19 December 2026 [Page 10]
Internet-Draft AACP June 2026
8.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. Benchmark date: May 2026.
8.2. Tokenisation Results
Four-hop payroll workflow. Tokens 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% |
+---------------------+-------+------+--------+--------+
8.3. Amortisation Benchmark
A three-scenario amortisation benchmark validated the "one LLM call
per novel pattern" property across 240 encoding operations. June
2026.
+---------------------------+--------+----------+----------+
| 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% |
+---------------------------+--------+----------+----------+
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.
Mackay Expires 19 December 2026 [Page 11]
Internet-Draft AACP June 2026
8.4. Department Day Multi-Model Validation
A five-workflow department day lab [AACP-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.
+-------------------+---------+-----------+---------+---------+
| 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 |
+-------------------+---------+-----------+---------+---------+
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.
8.5. Framework Integration Benchmarks
AACP was integrated into four agent frameworks and benchmarked
against standard natural language coordination on an equivalent five-
workflow, 59-hop department day scenario. June 2026.
+-------------+------+----------------+----------+--------------+
| Framework | Hops | Coord. Calls | Saving | Determinism |
+-------------+------+----------------+----------+--------------+
| LangChain | 59 | 59 -> 0 | 18% | YES |
| CrewAI | 59 | 59 -> 0 | 30% | YES |
| AutoGen | 59 | 59 -> 0 | 55% | YES |
| Pydantic AI | 59 | 59 -> 0 | 85% | YES |
+-------------+------+----------------+----------+--------------+
In all four cases, all 59 coordination LLM calls were eliminated for
known workflows. The saving scales with the verbosity of the
framework's default coordination layer. AutoGen's GroupChat model
produces highly conversational coordination messages; AACP eliminates
these entirely. Pydantic AI presents a distinct case: it already
types the result layer natively. AACP completes the determinism
picture by typing the instruction layer. With AACP, both
coordination instructions and agent results are deterministic and
validated. Reference implementations are available as
[AACP-LANGCHAIN], [AACP-CREWAI], [AACP-AUTOGEN], and [AACP-PYDANTIC].
Mackay Expires 19 December 2026 [Page 12]
Internet-Draft AACP June 2026
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
pip install aacp-autogen # AutoGen integration v0.1.0
pip install aacp-pydantic-ai # Pydantic AI 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.
Mackay Expires 19 December 2026 [Page 13]
Internet-Draft AACP June 2026
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
15.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>.
15.2. Informative References
Mackay Expires 19 December 2026 [Page 14]
Internet-Draft AACP June 2026
[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/>.
[A2A] Google, "Agent-to-Agent Protocol", 2025,
<https://google.github.io/A2A/>.
[AACP-SDK] Mackay, A., "AACP Python SDK v1.4.0", pip install aacp.
https://pypi.org/project/aacp/, June 2026,
<https://github.com/MackayAndrew/aacp>.
[AACP-TS] Mackay, A., "AACP TypeScript SDK v1.4.0", npm install
aacp-ts. https://www.npmjs.com/package/aacp-ts, June 2026,
<https://github.com/MackayAndrew/aacp-ts>.
[AACP-LANGCHAIN]
Mackay, A., "AACP LangChain Integration v0.1.0", pip
install aacp-langchain. 18% total cost reduction, 59
coordination calls eliminated., June 2026,
<https://github.com/MackayAndrew/aacp-langchain>.
[AACP-CREWAI]
Mackay, A., "AACP CrewAI Integration v0.1.0", pip install
aacp-crewai. 30% total cost reduction, 59 coordination
calls eliminated., June 2026,
<https://github.com/MackayAndrew/aacp-crewai>.
[AACP-LAB] Mackay, A., "AACP Multi-Agent Department Day Lab", Five-
workflow department day. Four-model comparison. All 76
coordination hops validated per model run., June 2026,
<https://github.com/MackayAndrew/aacp-lab>.
[AACP-RULES]
Mackay, A., "AACP Community Rule Library v1.1", 241 pre-
validated rules across 7 domains. MIT licensed. API at
https://registry.aacp.dev, June 2026,
<https://github.com/MackayAndrew/aacp-community-rules>.
[AACP-AUTOGEN]
Mackay, A., "AACP AutoGen Integration v0.1.0", pip install
aacp-autogen. 55% total cost reduction, 59 coordination
calls eliminated. Requires Python 3.11 (pyautogen 0.2.x
constraint)., June 2026,
<https://github.com/MackayAndrew/aacp-autogen>.
Mackay Expires 19 December 2026 [Page 15]
Internet-Draft AACP June 2026
[AACP-PYDANTIC]
Mackay, A., "AACP Pydantic AI Integration v0.1.0", pip
install aacp-pydantic-ai. 85% total cost reduction, 59
coordination calls eliminated. Pydantic AI types results
natively; AACP adds typed instructions. Both layers
deterministic with AACP., June 2026,
<https://github.com/MackayAndrew/aacp-pydantic-ai>.
[AACP-DISPATCH]
Mackay, A., "Dispatch AACP VS Code Extension", Syntax
highlighting, validation, hover decode, autocomplete and
token count for AACP packets. Web builder at
https://dispatch.aacp.dev, May 2026,
<https://marketplace.visualstudio.com/
items?itemName=dispatch-aacp.dispatch-aacp>.
Author's Address
Andrew Mackay
Independent
Email: mackayandrewr@gmail.com
URI: https://aacp.dev
Mackay Expires 19 December 2026 [Page 16]