Independent Submission A. Cowles Internet-Draft Quox Ltd Intended status: Experimental 28 February 2026 Expires: 1 September 2026 Agent Envelope Exchange (AEE): A Minimal JSON Envelope Format for Inter- Agent Communication draft-cowles-aee-00 Abstract Agent Envelope Exchange (AEE) defines a minimal, transport- independent JSON envelope format for communication between autonomous AI agents, traditional services, and human participants. The envelope comprises 14 well-defined fields that provide message identity, typing, correlation, tracing, priority, and extensibility without prescribing payload semantics or transport mechanisms. AEE separates the concerns of message routing and lifecycle management (the envelope) from domain-specific meaning (intent schemas), enabling portable, composable, and auditable workflows across heterogeneous agent frameworks. This document specifies the envelope structure, validity rules, conformance levels, entity identifier conventions, a reserved intent namespace for protocol negotiation, and a referencing strategy that avoids envelope nesting. 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 1 September 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Cowles Expires 1 September 2026 [Page 1] Internet-Draft AEE February 2026 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. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Envelope Format . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. JSON Schema . . . . . . . . . . . . . . . . . . . . . . . 7 4. Message Types . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Entity Identifiers . . . . . . . . . . . . . . . . . . . . . 9 5.1. Identifier Format . . . . . . . . . . . . . . . . . . . . 9 5.2. Common Type Prefixes . . . . . . . . . . . . . . . . . . 9 5.3. Causality Tracing Across Entity Types . . . . . . . . . . 10 6. Validity Rules . . . . . . . . . . . . . . . . . . . . . . . 10 7. Conformance Levels . . . . . . . . . . . . . . . . . . . . . 11 7.1. MVE-Required (Schema-Valid) . . . . . . . . . . . . . . . 11 7.2. MVE-5 (Log-Friendly) . . . . . . . . . . . . . . . . . . 12 8. Signatures . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Intent Namespace . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Naming Conventions . . . . . . . . . . . . . . . . . . . 14 9.2. Reserved Namespace: aee.* . . . . . . . . . . . . . . . . 14 9.3. Intent Schema Publishing . . . . . . . . . . . . . . . . 16 10. Referencing Strategy . . . . . . . . . . . . . . . . . . . . 16 10.1. Rationale: Avoiding Nested Envelopes . . . . . . . . . . 16 10.2. The payload.references Array . . . . . . . . . . . . . . 16 10.3. Exception: Archival and Forensic Snapshots . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 11.1. Replay Attacks and Correlation ID Uniqueness . . . . . . 18 11.2. Signature Verification and Trust Model . . . . . . . . . 18 11.3. Envelope Integrity Without Signatures . . . . . . . . . 18 11.4. Privacy of Payload Contents . . . . . . . . . . . . . . 19 11.5. Trust Boundaries Between Agents . . . . . . . . . . . . 19 11.6. Denial of Service via Priority Field Abuse . . . . . . . 19 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 13.2. Informative References . . . . . . . . . . . . . . . . . 20 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 Cowles Expires 1 September 2026 [Page 2] Internet-Draft AEE February 2026 1. Introduction The rapid proliferation of autonomous AI agent frameworks -- including LangGraph, AutoGen, CrewAI, and numerous proprietary systems -- has created a fragmented landscape for inter-agent communication. Each framework defines its own message structures, correlation mechanisms, and error conventions, making it difficult to compose workflows that span multiple agent runtimes or organizational boundaries. Existing approaches suffer from several deficiencies: * *No standard envelope format:* Messages lack a consistent structure for identity, typing, and metadata, forcing each integration to define bespoke serialization. * *Lost causality:* Without standardized correlation and reply-to semantics, tracing a request through a chain of agents requires framework-specific tooling. * *Coupled semantics:* Many systems conflate the message container with the message content, making it impossible to validate routing independently of payload. * *Human exclusion:* Most agent protocols treat human participants as external to the messaging model rather than as first-class senders and recipients. AEE addresses these problems by defining a minimal 14-field JSON envelope that standardizes message identity, type classification, sender/recipient addressing, intent declaration, correlation, distributed tracing hooks, priority signaling, execution constraints, payload carriage, and optional cryptographic signatures. The envelope is deliberately small and stable: it provides just enough structure for messages to be routed, correlated, traced, and validated, while delegating all domain-specific semantics to intent schemas that evolve independently. AEE does not prescribe a transport mechanism. Envelopes MAY be carried over HTTP, WebSocket, NATS, Kafka, Redis Streams, or any other reliable or unreliable channel. The protocol is intentionally transport-agnostic to maximize adoption across diverse deployment topologies. Cowles Expires 1 September 2026 [Page 3] Internet-Draft AEE February 2026 2. Conventions and Definitions 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. The following terms are used throughout this document: Envelope The top-level JSON object defined by this specification, containing metadata fields and a payload. Intent A namespaced identifier declaring the semantic purpose of a message. The intent determines which payload schema applies. Entity Any participant in AEE communication: an autonomous agent, a traditional service, a human operator, or a broadcast channel. Correlation The mechanism by which related messages (e.g., a task and its result) are linked via shared identifiers. MVE Minimal Viable Envelope. A subset of envelope fields sufficient for a particular conformance tier. 3. Envelope Format An AEE message is a JSON object [RFC8259] with exactly 14 top-level fields. The envelope is designed to be small, stable, and forward- compatible. The meaning of a message is determined by the combination of its "type" and "intent" fields; the "payload" carries intent-specific data whose schema is defined externally. +====+==========+=========+=============+==========================+ | # | Field | Type | Required | Description | +====+==========+=========+=============+==========================+ | 1 | v | string | Yes | Envelope schema version. | | | | | | For this specification, | | | | | | the value MUST be "1". | +----+----------+---------+-------------+--------------------------+ | 2 | id | string | Yes | Unique message | | | | | | identifier. ULID or | | | | | | UUID [RFC4122] is | | | | | | RECOMMENDED. Minimum | | | | | | length: 8 characters. | +----+----------+---------+-------------+--------------------------+ | 3 | ts | string | Yes | Timestamp of message | | | | | | creation. ISO 8601 UTC | Cowles Expires 1 September 2026 [Page 4] Internet-Draft AEE February 2026 | | | | | format is RECOMMENDED | | | | | | (e.g., | | | | | | "2025-12-14T03:45:12Z"). | | | | | | Minimum length: 10 | | | | | | characters. | +----+----------+---------+-------------+--------------------------+ | 4 | type | string | Yes | Message type. MUST be | | | | | | one of: "task", | | | | | | "result", "event", | | | | | | "error", "stream". | +----+----------+---------+-------------+--------------------------+ | 5 | from | string | Yes | Sender entity identifier | | | | | | (see Section 5). | | | | | | Minimum length: 1 | | | | | | character. | +----+----------+---------+-------------+--------------------------+ | 6 | to | string | Yes | Recipient entity | | | | | | identifier or channel | | | | | | (see Section 5). | | | | | | Minimum length: 1 | | | | | | character. | +----+----------+---------+-------------+--------------------------+ | 7 | intent | string | Yes | Namespaced intent | | | | | | identifier declaring the | | | | | | semantic purpose of the | | | | | | message (see Section 9). | | | | | | Minimum length: 3 | | | | | | characters. | +----+----------+---------+-------------+--------------------------+ | 8 | corr | string | Yes | Correlation identifier | | | | | | linking all messages in | | | | | | a workflow or | | | | | | conversation thread. | | | | | | Minimum length: 8 | | | | | | characters. | +----+----------+---------+-------------+--------------------------+ | 9 | reply_to | string | Conditional | The "id" of the message | | | | or null | | being replied to. MUST | | | | | | be non-null (minimum 8 | | | | | | characters) when "type" | | | | | | is "result" or "error". | | | | | | SHOULD be null for other | | | | | | types. | +----+----------+---------+-------------+--------------------------+ | 10 | trace | object | No | Distributed tracing | | | | or null | | context with "trace_id" | | | | | | and "span_id" string | | | | | | properties. RECOMMENDED | Cowles Expires 1 September 2026 [Page 5] Internet-Draft AEE February 2026 | | | | | when an observability | | | | | | system is in use. | +----+----------+---------+-------------+--------------------------+ | 11 | priority | string | Yes | Message priority. MUST | | | | | | be one of: "low", | | | | | | "normal", "high", | | | | | | "urgent". | +----+----------+---------+-------------+--------------------------+ | 12 | requires | object | No | Execution constraints | | | | or null | | and expectations. | | | | | | Common keys include | | | | | | "timeout_ms" (number), | | | | | | "human_approval" | | | | | | (boolean), "evidence" | | | | | | (boolean), "format" | | | | | | (string), and | | | | | | "min_confidence" | | | | | | (number, 0 to 1). | | | | | | Unknown keys MUST be | | | | | | ignored by consumers. | +----+----------+---------+-------------+--------------------------+ | 13 | payload | object | Yes | Intent-specific data. | | | | | | The shape is defined by | | | | | | the intent schema, not | | | | | | by this specification. | | | | | | MUST be a JSON object. | +----+----------+---------+-------------+--------------------------+ | 14 | sig | object, | No | Optional cryptographic | | | | string, | | signature or | | | | or null | | authentication proof | | | | | | (see Section 8). | +----+----------+---------+-------------+--------------------------+ Table 1: AEE Envelope Fields The following example shows a complete AEE envelope of type "task": Cowles Expires 1 September 2026 [Page 6] Internet-Draft AEE February 2026 { "v": "1", "id": "01JFB2R1JZKQ9V3K8W8Y9W1F2A", "ts": "2025-12-14T03:45:12Z", "type": "task", "from": "agent.manager", "to": "agent.backup_auditor", "intent": "ops.backup.status.check", "corr": "01JFB2QX0K8X5K6ZJ9G2C0C1MW", "reply_to": null, "trace": {"trace_id": "9f3c", "span_id": "a12b"}, "priority": "high", "requires": { "timeout_ms": 30000, "evidence": true, "human_approval": false }, "payload": {"cluster": "node.lan", "window": "24h"}, "sig": null } 3.1. JSON Schema A normative JSON Schema (draft 2020-12) for the AEE v1 envelope is published alongside this specification. The schema validates envelope structure only; intent-specific payload validation is performed by separate schemas associated with each intent. The schema enforces all required fields, type constraints, enumeration values, and the conditional requirement that "reply_to" MUST be a non-null string of at least 8 characters when "type" is "result" or "error". The schema sets "additionalProperties" to true at the top level to support forward compatibility. 4. Message Types The "type" field classifies the purpose and expected behavior of each envelope. Exactly five message types are defined: task A request to perform work. A "task" message sets an expectation that the recipient will eventually respond with either a "result" or an "error" envelope sharing the same "corr" value and a "reply_to" referencing this task's "id". The sender MAY specify execution constraints in the "requires" field (e.g., timeout, required evidence, human approval). result Successful completion of a task. The "reply_to" field MUST Cowles Expires 1 September 2026 [Page 7] Internet-Draft AEE February 2026 contain the "id" of the originating "task" envelope. The "payload" carries the intent-specific output of the completed work. event An informational signal that does not require a reply. Events are used for notifications, status broadcasts, and telemetry. The "reply_to" field SHOULD be null. error Unsuccessful completion of a task. The "reply_to" field MUST contain the "id" of the originating "task" envelope. The "payload" SHOULD include a "code" string, a human-readable "message" string, and a "retryable" boolean. Additional fields such as "backoff_ms" and "evidence_refs" MAY be included. stream A partial or progress update related to a task or long- running process. Stream messages allow the recipient to observe intermediate state without waiting for the final result. Multiple "stream" envelopes MAY share the same "corr" and precede the terminal "result" or "error". The following example shows a "result" envelope responding to the task shown in Section 3: { "v": "1", "id": "01JFB2S7T8N4J8B7QH1GJ8Z1Y2", "ts": "2025-12-14T03:45:20Z", "type": "result", "from": "agent.backup_auditor", "to": "agent.manager", "intent": "ops.backup.status.check", "corr": "01JFB2QX0K8X5K6ZJ9G2C0C1MW", "reply_to": "01JFB2R1JZKQ9V3K8W8Y9W1F2A", "trace": {"trace_id": "9f3c", "span_id": "b77c"}, "priority": "high", "requires": {"evidence": true}, "payload": { "status": "PARTIAL_FAILURE", "failed": [ {"node": "pve02", "reason": "connection_refused:8007"} ], "confidence": 0.96, "evidence_refs": ["log:pbs01:job/2025-12-14T02:00Z"] }, "sig": null } The following example shows an "error" envelope: Cowles Expires 1 September 2026 [Page 8] Internet-Draft AEE February 2026 { "v": "1", "id": "01JFB2T3W9H0J1FQWQ7B2M3D5E", "ts": "2025-12-14T03:45:21Z", "type": "error", "from": "agent.backup_auditor", "to": "agent.manager", "intent": "ops.backup.status.check", "corr": "01JFB2QX0K8X5K6ZJ9G2C0C1MW", "reply_to": "01JFB2R1JZKQ9V3K8W8Y9W1F2A", "trace": {"trace_id": "9f3c", "span_id": "c01d"}, "priority": "high", "requires": {"evidence": true}, "payload": { "code": "E_TIMEOUT", "message": "PBS API did not respond within 30s", "retryable": true, "backoff_ms": 60000, "evidence_refs": ["tcp:pve02->pbs01:8007"] }, "sig": null } 5. Entity Identifiers The "from" and "to" fields accept any entity identifier string. AEE treats all participants -- autonomous agents, traditional services, human operators, and broadcast channels -- as first-class senders and recipients. There is no distinction at the envelope level between a message sent by a human and one sent by an agent. 5.1. Identifier Format The RECOMMENDED identifier format is: . where "type" indicates the entity category and "name" is a locally unique identifier within that category. Implementations MAY use any unique string, but the typed format improves debuggability and log readability. 5.2. Common Type Prefixes The following type prefixes are defined as conventions. This list is not exhaustive; implementations MAY define additional prefixes. agent.* Autonomous agents (e.g., "agent.backup_auditor", Cowles Expires 1 September 2026 [Page 9] Internet-Draft AEE February 2026 "agent.code_reviewer"). service.* Traditional (non-agent) services (e.g., "service.billing", "service.auth"). human.* Human participants (e.g., "human.adam", "human.ops_lead"). bus.* Broadcast channels or topic-based routing targets (e.g., "bus.ops", "bus.alerts"). 5.3. Causality Tracing Across Entity Types When a human initiates a task that cascades through multiple agents, the full causality chain is traceable through the combination of "from", "to", "corr", and "reply_to" fields. For example, a chain such as "human.adam" to "agent.router" to "agent.reviewer" to "service.linter" maintains complete provenance regardless of entity type at each hop. 6. Validity Rules The following rules are normative. An AEE envelope that violates any MUST-level rule is invalid and SHOULD be rejected by conforming implementations. 1. The fields "v", "id", "ts", "type", "from", "to", "intent", "corr", "priority", and "payload" MUST be present in every envelope. 2. The "type" field MUST contain one of the following values: "task", "result", "event", "error", "stream". 3. If "type" is "result" or "error", the "reply_to" field MUST be present and MUST be a non-null string with a minimum length of 8 characters, corresponding to the "id" of the originating "task" envelope. 4. The "payload" field MUST be a JSON object. The structure of the payload is defined by the intent schema associated with the "intent" value. 5. The "v" field MUST contain the string "1" for envelopes conforming to this version of the specification. 6. The "priority" field MUST contain one of the following values: "low", "normal", "high", "urgent". Cowles Expires 1 September 2026 [Page 10] Internet-Draft AEE February 2026 7. Unknown top-level fields MUST be ignored by consumers. This ensures forward compatibility: future versions or extensions may add fields without breaking existing implementations. 8. Consumers SHOULD log at minimum the following fields for observability: "id", "corr", "intent", "from", "to", "type", and "priority". 9. Producers SHOULD include the "trace" field with "trace_id" and "span_id" values when an observability or distributed tracing system is in use. 10. Within the "requires" object, unknown keys MUST be ignored by consumers. Producers SHOULD keep the "requires" object compact. 7. Conformance Levels AEE supports incremental adoption through two defined conformance tiers. Not every system needs full specification compliance on initial deployment. 7.1. MVE-Required (Schema-Valid) The Minimal Viable Envelope (MVE-Required) tier includes all fields required by the JSON Schema: * "v" * "id" * "ts" * "type" * "from" * "to" * "intent" * "corr" * "priority" * "payload" Cowles Expires 1 September 2026 [Page 11] Internet-Draft AEE February 2026 A system emitting envelopes with all 10 MVE-Required fields is fully schema-valid and interoperable with any AEE-compliant consumer. A system MAY claim MVE-Required compliance if: 1. It emits envelopes with all 10 required fields. 2. Those envelopes validate against the AEE v1 JSON Schema. 3. The "reply_to" field is non-null for "result" and "error" types. MVE-Required certification attests to structural compliance only. It does not certify payload schema conformance, semantic correctness of intents, or support for the "aee.*" protocol intents defined in Section 9. 7.2. MVE-5 (Log-Friendly) For logging, telemetry, and observability-only contexts, a 5-field subset is recognized: * "v" * "id" * "type" * "from" * "intent" MVE-5 is *NOT* schema-valid AEE. It is a convenience envelope for systems that only emit logs or telemetry and do not participate in request/response flows. MVE-5 envelopes: * Can be parsed by AEE-aware log aggregators. * Cannot be used for task/result correlation (missing "corr" and "reply_to"). * SHOULD NOT be sent to agents expecting full envelopes. 8. Signatures The "sig" field provides an OPTIONAL mechanism for cryptographic authentication and integrity verification of AEE envelopes. When signatures are used, the signing process SHOULD bind at minimum the following fields: Cowles Expires 1 September 2026 [Page 12] Internet-Draft AEE February 2026 * "v" * "id" * "ts" * "type" * "from" * "to" * "intent" * "corr" * "reply_to" * "payload" The "sig" field MAY be a JSON object or a string. When it is an object, the following structure is RECOMMENDED: { "alg": "ed25519", "kid": "key-2", "value": "" } alg The signature algorithm. Ed25519 is RECOMMENDED for new implementations. HMAC-SHA256 ("HS256") MAY also be used in symmetric-key environments. kid Key identifier, enabling key rotation and multi-key environments. value The signature or HMAC value, typically Base64-encoded. This specification does not define a key distribution mechanism. Deployments SHOULD establish key management procedures appropriate to their trust model. Future companion documents may define a security profile with detailed signing procedures, key exchange, and replay protection. Cowles Expires 1 September 2026 [Page 13] Internet-Draft AEE February 2026 9. Intent Namespace The "intent" field carries a namespaced identifier that declares the semantic purpose of a message. The intent determines which payload schema applies: each intent publishes separate schemas for "task", "result", and (optionally) "error" payloads. This separation means the envelope can be validated independently of payload content. 9.1. Naming Conventions The RECOMMENDED naming format uses flexible dotted notation: ... Examples: * "ops.network.port.probe" * "ops.backup.status.check" * "infra.proxmox.vm.create" * "docs.summarize.with_citations" Verbs SHOULD be explicit (e.g., "check", "probe", "create", "summarize"). Implementations SHOULD avoid overloading a single intent with multiple optional behaviors. Intent schemas MAY be versioned independently of the AEE envelope specification. If two agents cannot agree on an intent identifier, they do not share semantics. The absence of a recognized intent is not an error; it simply indicates that the agents lack a shared vocabulary for that operation. 9.2. Reserved Namespace: aee.* The "aee.*" namespace is reserved for protocol negotiation and context retrieval. These intents enable agents to discover capabilities, fetch context, and validate payloads without custom integration. They are protocol primitives, not orchestration mechanisms. The following core intents are defined: Cowles Expires 1 September 2026 [Page 14] Internet-Draft AEE February 2026 +======================+=========================================+ | Intent | Purpose | +======================+=========================================+ | aee.status.ping | Liveness check. The recipient MUST | | | respond with a result containing | | | {"pong": true}. | +----------------------+-----------------------------------------+ | aee.status.health | Health and readiness status. The | | | result payload MUST include a "status" | | | field with one of: "healthy", | | | "degraded", "unhealthy". | +----------------------+-----------------------------------------+ | aee.spec.query | Return supported AEE version and | | | capabilities. The result MUST include | | | "aee_version" and MAY include an | | | "extensions" array. | +----------------------+-----------------------------------------+ | aee.capability.list | List supported intents. The task MAY | | | include a "namespace_filter" string. | | | The result MUST include an "intents" | | | array of strings. | +----------------------+-----------------------------------------+ | aee.context.fetch | Retrieve an envelope or payload by | | | reference. The task MUST include "id" | | | and MAY include "corr", "locator", and | | | "hash" for verification. | +----------------------+-----------------------------------------+ | aee.context.refute | Reject a referenced context with a | | | reason. The task MUST include "id" and | | | "reason". The result MUST include | | | "acknowledged" (boolean). | +----------------------+-----------------------------------------+ | aee.validate.payload | Validate a payload against an intent | | | schema. The task MUST include "intent" | | | and "payload_to_validate". The result | | | MUST include "valid" (boolean) and MAY | | | include an "errors" array. | +----------------------+-----------------------------------------+ Table 2: Reserved aee.* Protocol Intents Implementations claiming AEE compliance are not required to implement all "aee.*" intents. However, "aee.status.ping" SHOULD be supported by all agents to enable basic liveness detection. Cowles Expires 1 September 2026 [Page 15] Internet-Draft AEE February 2026 Application-specific intents MUST NOT use the "aee.*" namespace. If a use case requires scheduling, workflow, or orchestration semantics, those intents belong in an application namespace (or in a companion protocol such as AOCL [AOCL]). 9.3. Intent Schema Publishing AEE does not standardize the "payload" field's internal structure. Instead, each intent publishes separate JSON Schema documents for its "task", "result", and "error" payload variants. The RECOMMENDED file layout is: envelope/aee-v1.schema.json intents/.task.schema.json intents/.result.schema.json intents/.error.schema.json AEE does not require a centralized intent registry. Communities MAY publish intent schemas in version-controlled repositories, package registries, or any other distribution mechanism appropriate to their ecosystem. 10. Referencing Strategy When an envelope needs to reference prior context (e.g., the original task that spawned a result, or related evidence from another workflow), AEE prescribes a reference-based approach rather than embedding full envelopes within payloads. 10.1. Rationale: Avoiding Nested Envelopes Embedding full envelopes inside payloads creates several problems: * *Matryoshka bloat:* Deeply nested structures grow with each hop in a multi-agent workflow, consuming storage and bandwidth. * *Token collapse:* Large language models (LLMs) processing nested envelopes waste context window tokens on redundant structural metadata. * *Signature ambiguity:* When envelopes are nested, it becomes unclear which envelope's signature is authoritative -- the outer or the inner. 10.2. The payload.references Array When referencing prior envelopes, implementations SHOULD use a "references" array within the payload: Cowles Expires 1 September 2026 [Page 16] Internet-Draft AEE February 2026 { "payload": { "references": [ { "id": "01JFB2R1JZKQ9V3K8W8Y9W1F2A", "corr": "01JFB2QX0K8X5K6ZJ9G2C0C1MW", "type": "aee.envelope", "locator": "store://envelopes/01JFB2R1JZKQ9V3K8W8Y9W1F2A", "hash": "sha256:a1b2c3..." } ] } } Each reference object contains the following fields: id (REQUIRED) The referenced envelope's "id" value. corr (OPTIONAL) The correlation ID for additional context. type (REQUIRED) The reference type. For envelope references, the value MUST be "aee.envelope". locator (OPTIONAL) A URI or path that can be used to retrieve the full referenced envelope, for example via the "aee.context.fetch" intent. hash (OPTIONAL) A content hash (e.g., "sha256:...") for integrity verification of the referenced envelope. To retrieve the full envelope behind a reference, consumers SHOULD use the "aee.context.fetch" protocol intent (see Section 9). 10.3. Exception: Archival and Forensic Snapshots When creating immutable audit logs or forensic snapshots, embedding full envelopes as inert blobs within a "result" payload is acceptable. These embedded envelopes are historical records, not active routing participants. Implementations MUST NOT attempt to route or process embedded archival envelopes as live messages. 11. Security Considerations Cowles Expires 1 September 2026 [Page 17] Internet-Draft AEE February 2026 11.1. Replay Attacks and Correlation ID Uniqueness Each AEE envelope carries a unique "id" field and a "corr" field linking related messages. If message identifiers are predictable or reused, an attacker could replay previously captured envelopes to trigger duplicate work or corrupt workflow state. Implementations MUST generate "id" values using cryptographically random or lexicographically-sortable unique identifiers (e.g., ULIDs or UUIDs [RFC4122]). Consumers SHOULD maintain a deduplication window and reject envelopes with previously seen "id" values within that window. The "ts" field SHOULD be checked against a reasonable clock-skew tolerance to detect stale replays. 11.2. Signature Verification and Trust Model The "sig" field is OPTIONAL, meaning that unsigned envelopes are valid per this specification. Deployments operating in environments where message authenticity is critical MUST require signatures and establish a trust model for key distribution. Ed25519 is RECOMMENDED for asymmetric signatures due to its performance characteristics and resistance to implementation pitfalls. When signatures are present, consumers MUST verify them before processing the envelope. A failed signature verification MUST result in rejection of the envelope. This specification does not define a public key infrastructure (PKI) or key exchange mechanism. Deployments SHOULD document their key management procedures, including key rotation schedules, revocation mechanisms, and the scope of trust for each key identifier ("kid"). 11.3. Envelope Integrity Without Signatures In deployments where the "sig" field is not used, envelope integrity depends entirely on the security properties of the transport layer. If envelopes are carried over an unencrypted or unauthenticated channel, any intermediary can modify envelope fields -- including "from", "to", "intent", and "payload" -- without detection. Deployments that do not use envelope-level signatures MUST ensure that the transport layer provides adequate integrity and authentication guarantees (e.g., TLS with mutual authentication). For tamper-evident recording of envelope exchanges, the companion VOLT protocol [VOLT] defines cryptographic hash chains that can provide post-hoc verification of envelope integrity. Cowles Expires 1 September 2026 [Page 18] Internet-Draft AEE February 2026 11.4. Privacy of Payload Contents AEE envelopes carry arbitrary payload data that may include personally identifiable information (PII), credentials, internal system details, or other sensitive content. The envelope format does not provide payload encryption. Implementations handling sensitive data SHOULD encrypt payloads at the application layer or ensure that the transport provides confidentiality (e.g., TLS). The "requires" field MUST NOT be used to carry secrets; credentials should be transmitted through secure side-channels rather than embedded in envelope metadata. The logging guidance in Section 6 (rule 8) recommends logging several envelope fields for observability. Implementations MUST ensure that logged fields do not inadvertently expose sensitive payload contents. The "intent" field, while not typically sensitive, may reveal operational patterns; deployments SHOULD consider the information leakage implications of intent names in log aggregation systems. 11.5. Trust Boundaries Between Agents AEE entity identifiers (see Section 5) are self-asserted: the "from" field is populated by the sender, and there is no built-in mechanism to verify that the claimed sender identity is authentic. In multi- tenant or cross-organizational deployments, a malicious agent could impersonate another agent by setting an arbitrary "from" value. Deployments MUST implement identity verification at trust boundaries, either through envelope signatures (see Section 8), transport-layer authentication, or a gateway that validates sender identity before forwarding envelopes. When envelopes cross trust boundaries (e.g., from an internal agent network to an external partner's agents), implementations SHOULD validate all envelope fields at the boundary, strip or redact sensitive payload content, and apply allowlist-based intent filtering to prevent unauthorized operations. 11.6. Denial of Service via Priority Field Abuse The "priority" field allows senders to signal message urgency. A malicious or misconfigured agent could set all messages to "urgent" priority, starving normal-priority messages of processing resources. Implementations SHOULD enforce per-sender priority quotas or rate limits. Infrastructure components SHOULD NOT blindly trust the "priority" field from untrusted sources; instead, they SHOULD apply policy-based priority assignment or capping at trust boundaries. Cowles Expires 1 September 2026 [Page 19] Internet-Draft AEE February 2026 Similarly, the "requires" field's "timeout_ms" value could be abused to hold resources for extended periods. Consumers SHOULD enforce maximum timeout values regardless of the requested timeout, and SHOULD release resources promptly when timeouts expire. 12. IANA Considerations This document has no IANA actions. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . 13.2. Informative References [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, . [AOCL] Cowles, A., "Agent Orchestration Control Layers (AOCL)", Work in Progress, Internet-Draft, draft-cowles-aocl-00, 2026, . [VOLT] Cowles, A., "Verifiable Operations Ledger and Trace (VOLT)", Work in Progress, Internet-Draft, draft-cowles- volt-00, 2026, . Cowles Expires 1 September 2026 [Page 20] Internet-Draft AEE February 2026 Acknowledgements The author wishes to thank the early adopters and reviewers of the AEE specification within the Quox ecosystem, whose feedback on real- world agent interoperability challenges shaped the design of this envelope format. Author's Address Adam Cowles Quox Ltd London United Kingdom Email: adam@quox.ai URI: https://quox.ai Cowles Expires 1 September 2026 [Page 21]