ProtocolDeep Dive

AEE: Why AI Agents Need a Universal Messaging Standard

8 March 20268 min read

Translucent envelope shapes in sky blue connected by luminous threads forming a message routing network

The lesson from 1989

In 1989, Tim Berners-Lee proposed a simple idea: a universal protocol for requesting and delivering documents over a network. Before HTTP, every networked application spoke its own language. File transfer used FTP. Email used SMTP. News used NNTP. If you wanted to build something that touched multiple services, you wrote custom integration code for each one.

HTTP did not replace those protocols. It created a universal request-response pattern that made the web possible. A browser did not need to know how a server was built. A server did not need to know what client was connecting. The envelope was standard. The content was free-form.

AI agents are now at the same inflection point, and they are failing the interoperability test.

The messaging problem nobody is solving

Seventy-two percent of enterprises plan to deploy AI agents from trusted technology providers (KPMG Q4 AI Pulse Survey, January 2026). As organisations move from single-purpose chatbots to systems where specialised agents collaborate on complex tasks, one agent retrieves data, another analyses it, a third generates a report, and a fourth routes it for human review, the number of multi-agent architectures will only increase.

Vendor	Format
OpenAI	function_calling
Anthropic	tool_use
Google	function_declarations
LangChain	agent_step
AutoGen	conversation_msg
CrewAI	task_output

Current state: incompatible formats. Each framework is internally consistent. Across frameworks, chaos.

We have been here before. Before SMTP standardised email delivery, you could not send a message from one mail system to another without a gateway that understood both proprietary formats. Before JSON, data exchange between web services required negotiating XML schemas, SOAP envelopes, and WSDL contracts. Standardisation did not constrain innovation. It enabled it.

What MCP solves, and what it does not

Anthropic's Model Context Protocol (MCP) has been a landmark contribution to the agent ecosystem. With over 10,000 servers and 97 million monthly SDK downloads as of early 2026, MCP has become the de facto standard for how AI applications connect to tools and context providers. It answers a critical question: how does an agent access capabilities?

But MCP deliberately does not answer a different question: how do agents talk to each other?

MCP handles

Tool discovery
Tool call formatting
Result delivery
Context provision

AEE handles

Identity (who sent this?)
Correlation (which conversation?)
Causality (what triggered this?)
Expiration (still relevant?)

MCP handles capability exposure. Agent-to-agent messaging needs its own standard.

The three missing primitives

Identity. Most agent messages do not carry structured information about who sent them. A message might include "from": "assistant" or "role": "tool", but there is no standard way to express that a message came from a specific agent, operated by a specific organisation, on behalf of a specific user. Without structured identity, you cannot build access control, audit trails, or accountability.
Correlation. In a multi-step workflow, a single user request might generate dozens of inter-agent messages. Without a correlation identifier that persists across every hop, tracing cause and effect is forensic reconstruction: scanning timestamps, inferring relationships, hoping the logs are complete. This problem was solved for microservices a decade ago with trace IDs and span IDs. Agent systems have largely ignored the lesson.
Structured intent. When an agent receives a message, it needs to know what is being asked without parsing natural language. A field that says ops.backup.status.check is unambiguous. A payload that says "Please check the backup status" requires inference. At thousands of messages per minute, the difference is the difference between reliable routing and probabilistic guessing.

AEE: the envelope, not the letter

AEE (Agent Envelope Exchange) is a protocol specification designed to fill this gap. It defines a 14-field JSON envelope for agent-to-agent communication. The core principle is borrowed directly from HTTP: standardise the envelope, leave the content to the domain.

json

// An AEE envelope – 14 fields, every question answered
{
  "v": "1",
  "id": "01JFX7K2M4N8P1Q3R5S7T9V0W2",
  "ts": "2026-02-28T10:30:00Z",
  "type": "task",
  "from": "human.adam",
  "to": "agent.sentinel",
  "intent": "quox.security.scan",
  "corr": "CONV_01JFX7K0A2B4C6D8E0F2G4H6J8",
  "reply_to": null,
  "trace": {"trace_id": "9f3c", "span_id": "a12b"},
  "priority": "high",
  "requires": {"timeout_ms": 30000, "evidence": true},
  "payload": {"target": "nw-web-01", "scan_type": "vulnerability"},
  "sig": null
}

Fourteen fields. Each one answers a specific question that every agent system eventually needs answered.

The 14-field envelope

Field	Purpose	Category	Example
v	Protocol version	meta	"1"
id	Unique message identifier (ULID)	meta	"01JFX7K2M4..."
ts	ISO 8601 timestamp	meta	"2026-02-28T10:30:00Z"
type	Envelope classification	meta	"task"
from	Typed sender identity	identity	"human.adam"
to	Typed recipient identity	identity	"agent.sentinel"
intent	Namespaced action identifier	routing	"quox.security.scan"
corr	Conversation correlation ID	correlation	"CONV_01JFX7K0..."
reply_to	Parent message reference	correlation	null
trace	Distributed tracing context	correlation	{"trace_id": "9f3c"}
priority	Execution priority level	constraints	"high"
requires	Operational constraints	constraints	{"timeout_ms": 30000}
payload	Domain-specific content (open)	content	{"target": "nw-web-01"}
sig	Optional cryptographic signature	integrity	null

Typed actor identities

The from and to fields use typed actor identifiers. The prefix is machine-parseable, a policy engine can grant different permissions to human.* and agent.* senders without inspecting the payload.

Prefix	Description
human.*	End users and operators
agent.*	AI agents and autonomous systems
service.*	Backend services and APIs
bus.*	Message buses and routers

Envelope types

The type field classifies the envelope itself. The type determines handling semantics, a result or error must include reply_to. A task may include requires constraints like timeouts or human approval gates.

Type	Description	reply_to
task	A request for work	optional
result	Successful completion	required
error	Unsuccessful completion	required
event	Informational, no reply expected	optional
stream	Partial progress update	optional

Correlation: follow the IDs

Every message in a conversation shares the same corr value. Every response points back to the message it answers via reply_to. When a human request cascades through multiple agents, the full chain is reconstructable from any single message.

text

// corr: CONV_01JFX7K0 – all share the same correlation ID
human.adam  ->  agent.router  ->  agent.scanner  ->  service.cve_db
   task           task           task           result
   id: MSG_A       id: MSG_B       id: MSG_C       id: MSG_D
   reply_to: -     reply_to: A     reply_to: B     reply_to: C

ULIDs: sort by ID, get temporal order

Message IDs use ULIDs, Universally Unique Lexicographically Sortable Identifiers. Unlike UUIDs, ULIDs embed a timestamp in their structure, which means they sort chronologically by default. For event-ordered systems, this is a significant operational advantage: you can sort messages by ID and get temporal order without parsing timestamps.

Structured intent: deterministic routing

The intent field provides a hierarchical, namespaced identifier for what the message is requesting. Intents are searchable, filterable, and routable. An agent declares which intents it handles. A router matches incoming intents to capable agents.

text

quox.security.scan
ops.backup.status.check
aee.capability.list
quox.deploy.rollback

// No natural language parsing required.

Envelope and payload: the HTTP analogy

The most important design decision in AEE is what it does not standardise: the payload. The payload field is an open JSON object. Its schema is defined by the intent, not by the AEE specification.

This is precisely how HTTP works. HTTP defines headers, methods, status codes, and content negotiation. It says nothing about what goes in the body. AEE applies the same principle: the envelope is stable, the payload evolves with the domain. New intents can be defined, published, and adopted without changing a single byte of the envelope specification.

HTTP

Headers: stable
Body: domain-specific

AEE

Envelope: stable
Payload: domain-specific

Incremental adoption: MVE-Required vs MVE-5

The protocol supports incremental adoption through two tiers. MVE-Required (Minimal Viable Envelope) includes the 10 fields needed for full agent-to-agent communication. MVE-5 is a 5-field subset for systems that only need structured logging without participating in request-response flows.

Field	Purpose	MVE-Required	MVE-5
v	Protocol version	✓	✓
id	Unique message identifier (ULID)	✓	✓
ts	ISO 8601 timestamp	✓	✓
type	Envelope classification	✓	✓
from	Typed sender identity	✓	✓
to	Typed recipient identity	✓	–
intent	Namespaced action identifier	✓	–
corr	Conversation correlation ID	✓	–
reply_to	Parent message reference	✓	–
trace	Distributed tracing context	✓	–
priority	Execution priority level	–	–
requires	Operational constraints	–	–
payload	Domain-specific content (open)	–	–
sig	Optional cryptographic signature	–	–

MVE-Required: 10 fields. MVE-5: 5 fields.

A team can start by wrapping existing LLM gateway calls in MVE-5 envelopes for observability, then graduate to full MVE-Required when they build agent-to-agent workflows.

What AEE does not do

Intellectual honesty about boundaries is as important for a messaging protocol as it is for an evidence protocol. AEE defines the envelope. It does not define:

Boundary	Description
Transport	AEE is transport-agnostic. Envelopes can be carried over HTTP, WebSockets, message queues, or local function calls.
Tool execution	AEE envelopes can describe a request to execute a tool, but actual execution is handled by a runtime like MCP.
Agent discovery	AEE does not define how agents find each other. Service registries, DNS, or hardcoded routing are all compatible.

These boundaries are deliberate. A protocol that tries to standardise everything standardises nothing.

From specification to production

AEE is deployed in production inside QuoxCORE, where it serves as the messaging backbone for inter-agent communication within the orchestration pipeline. Every agent-to-agent message and audit trail entry uses the AEE envelope format, and VOLT evidence records link back to AEE envelopes via correlation IDs.

The specification is published as an open protocol, including a JSON Schema for envelope validation, example messages, a starter intent registry, and conformance test criteria.

The protocol family

AEE is part of a protocol family that addresses three complementary concerns: messaging (AEE), orchestration control and observability (AOCL), and verifiable evidence (VOLT). Together they provide the infrastructure for agent systems that are observable, controllable, and provable.

Protocol	Description	Role
AEE	Agent message envelopes: identity, correlation, intent	MESSAGING
AOCL	11-layer governance pipeline: control and observability	ORCHESTRATION
VOLT	Tamper-evident evidence chains: cryptographic proof	EVIDENCE
WARD	Content-free hash-chain witnessing: independent audit	WITNESSING

The standard is coming: the question is which one

The AI agent ecosystem is at the stage where every platform is building proprietary messaging. History tells us how this ends. It ends with a standard, either one that the community designs deliberately, or one that emerges messily from a dominant vendor's implementation choices.

HTTP, SMTP, JSON, and now MCP demonstrate that deliberate, minimal, open standards produce better outcomes than proprietary lock-in.

AEE is a bet on that pattern. Fourteen fields. One envelope. Every agent speaks the same language.

Quox (quox.ai) builds trust infrastructure for AI agent operations. Its open protocols, AEE for standardised agent messaging, AOCL for orchestration control and observability, and VOLT for cryptographic evidence chains, provide the accountability architecture that autonomous systems require.

Read the specification

Open protocol specifications. No vendor lock-in, no proprietary formats. Implement them yourself or use QuoxCORE.

Protocol docs Download QuoxCORE