Standards
Three Protocols, One Standards Body
Quox submitted three protocol specifications to the IETF as Internet-Drafts, covering agent messaging, governance, and evidence. This is what we filed and why it matters.
28 February 20267 min read
Update, 31 August 2026: the withdrawal recorded in an earlier version of this note is history. All four protocols are live IETF Internet-Drafts: AEE, AOCL and VOLT refreshed at -01, and WARD filed for the first time, together current to 4 March 2027. Since this post was written, all four protocols also gained SDKs and conformance suites. The post is preserved as the record of the original February 2026 filing.
| Protocol | Full name | Description | Draft ID |
|---|---|---|---|
| AEE | Agent Envelope Exchange | 14-field JSON envelope for agent messaging | draft-cowles-aee-00 |
| AOCL | Agent Orchestration Control Layers | 11-layer governance pipeline | draft-cowles-aocl-00 |
| VOLT | Verifiable Operations Ledger & Trace | Cryptographic hash-chain evidence | draft-cowles-volt-00 |
Why protocols, why now
AI agents are shipping faster than the guardrails around them. Every platform has its own message format, its own permission model, its own audit log. None of them interoperate. When something goes wrong, there is no standard way to reconstruct what happened, who authorised it, or whether the evidence has been tampered with.
Quox was built to run agents in production for real organisations. That meant solving three problems before anything else: how agents communicate, how their behaviour is governed, and how you prove what actually happened. We wrote protocols for each one, implemented them, and then submitted all three to the IETF as Internet-Drafts on the same day.
These are not theoretical specifications. They run in the QuoxCORE platform today, processing every agent message and decision in production.
Three problems, three protocols
| Question | Protocol |
|---|---|
| How do agents communicate? | AEE |
| How is agent behaviour governed? | AOCL |
| How do you prove what happened? | VOLT |
AEE: the envelope
The Agent Envelope Exchange defines a 14-field JSON envelope that wraps every message between agents, tools, and human operators. Every envelope carries a unique identifier, a correlation ID for threading related actions, timestamps, source and destination identifiers, content type, priority, and security metadata.
The key property: envelopes are transport-agnostic. The same envelope structure works over HTTP, WebSocket, message queues, or local function calls. Agents do not need to know how their messages travel, only that every message has a consistent, inspectable wrapper.
// AEE envelope — 14 fields, transport-agnostic
{
envelope_id: "ENV_20260228_X7K9",
correlation_id: "CORR_20260228_A1B2",
source: "agent:research-01",
destination: "agent:analyst-02",
content_type: "application/json",
priority: 3,
payload: { ... }
}AOCL: the governance pipeline
The Agent Orchestration Control Layers specification defines an 11-layer pipeline that every agent action must pass through before it can execute. Each layer addresses a distinct governance concern: identity, policy, capability, context, content safety, privacy, rate limiting, human oversight, cost management, observability, and audit.
Layers are evaluated in order. Any layer can halt execution with a denial reason, and the denial is itself recorded as a governance event. This means blocked actions generate the same evidence trail as permitted ones.
| Layer | Name | Description |
|---|---|---|
| L10 | Audit & Compliance | Immutable evidence trail |
| L9 | Observability | Metrics, tracing, alerting |
| L8 | Cost Management | Budget enforcement & metering |
| L7 | Human Oversight | Approval gates & escalation |
| L6 | Rate Limiting | Throughput control per agent |
| L5 | Privacy | PII detection & redaction |
| L4 | Content Safety | Toxicity & harm filtering |
| L3 | Context | Memory & conversation state |
| L2 | Capability | Tool & resource permissions |
| L1 | Policy | Organisational rules engine |
| L0 | Identity | Authentication & agent identity |
Every agent action traverses all 11 layers, bottom to top.
VOLT: the evidence chain
The Verifiable Operations Ledger & Trace defines a cryptographic hash-chain for recording agent operations. Each entry contains a SHA-256 hash of its payload, a chain hash linking it to the previous entry, and structured metadata about the operation that occurred.
The critical property is tamper evidence. If any entry in the chain is modified, deleted, or reordered, the hash chain breaks, and the tampering is detectable by any verifier with access to the chain. This is not blockchain; there is no consensus mechanism or distributed ledger. It is a simple, fast, local hash chain that provides mathematical proof of integrity.
// VOLT chain entry — tamper-evident by construction
{
seq: 42,
operation: "tool_execution",
payload_hash: "sha256:a9f3c1...",
chain_hash: "sha256:e7b2d0...",
prev_hash: "sha256:c4a8f6...",
timestamp: "2026-02-28T14:32:01Z"
}How they bind together
The three protocols are not independent documents. They are designed to interlock via a shared correlation identifier. When an AEE envelope is created, its correlation_id propagates through AOCL governance decisions and into VOLT evidence entries. A single correlation ID lets you trace from the original message, through every governance check it passed or failed, to the final evidence record.
Correlation flow (all three protocols share one correlation_id, e.g. CORR_20260228_A1B2):
- AEE envelope created:
envelope_id→correlation_idassigned - AOCL pipeline (L0 to L10): each layer decision references
correlation_id - VOLT evidence recorded: hash-chain entry keyed by
correlation_id
One ID threads message → governance → evidence.
Why the IETF
We could have published these as standalone whitepapers or GitHub READMEs. We submitted them to the Internet Engineering Task Force instead because the IETF is where internet protocols become standards. HTTP, TLS, DNS, WebSocket, JSON, OAuth: the infrastructure the internet runs on was standardised through the IETF process.
AI agent protocols will need the same treatment. When regulated industries deploy autonomous agents, they will need interoperable, independently reviewed standards for messaging, governance, and evidence. Not vendor documentation. Not a blog post. An RFC.
The Internet-Draft stage is the beginning of that process. It means the documents are now in the IETF system, available for community review, and eligible for progression toward a working group and eventually a published standard.
The path to a standard
Updated August 2026, twice: first to record the withdrawal, then to record the 31 August refiling. The February 2026 filing stands as written.
- 28 Feb 2026Submission
AEE, AOCL, and VOLT filed as IETF Internet-Drafts.
Done - Aug 2026Withdrawal
All three submissions withdrawn ahead of the Quox launch. WARD's draft was written but never filed.
Done - 31 Aug 2026Resubmission
All four specifications refiled together, including WARD as a first-time submission. Live on the datatracker as draft-cowles-aee-01, draft-cowles-aocl-01, draft-cowles-volt-01 and draft-cowles-ward-00, current to 4 March 2027.
Done - TBDCommunity Review
Specifications are open for anyone to read, file issues, suggest changes, or implement independently on GitHub in the meantime.
Future - TBDWorking Group
Formal IETF working group formation, date to be determined.
Future - TBDStandard
Published RFC standard, date to be determined.
Future
The NIST context
The timing was not accidental. In January 2026, NIST published a Request for Information on AI agent governance, seeking input on frameworks for managing autonomous AI systems in regulated environments. We submitted a response referencing all three protocol specifications, demonstrating that protocol-level governance is not only possible but already implemented.
The NIST submission and the IETF filings are part of the same thesis: AI agent governance needs to happen at the protocol layer, not the application layer. Policy documents and best-practice guides are necessary but insufficient. What regulated industries actually need is wire-level standards that any implementation can conform to and any auditor can verify.
What happens next
Updated twice in August 2026: first when the three drafts were withdrawn ahead of launch, then on 31 August, when all four protocols were filed together. AEE, AOCL and VOLT are live at their -01 revisions and WARD at -00, current to 4 March 2027.
The specifications remain published and open for community review. Anyone can read them, file issues, suggest changes, or implement them independently from the specification repositories on GitHub.
A fourth protocol, WARD (Write-once Append-only Receipt Digests), was drafted for submission at the same time, though that filing never happened. WARD adds content-free hash-chain witnessing on top of VOLT, providing an independent proof layer that survives even if the primary evidence store is compromised. All four will be submitted together post-launch.
The goal is not to own these protocols. It is to get them reviewed, improved, and adopted. If another platform implements AEE envelopes, AOCL governance, and VOLT evidence chains, that is a success. Interoperability is the point.
Read, review, participate
Updated August 2026: the Datatracker links below pointed at the withdrawn filing, so they now point at the specification repositories, which are current.
All three specifications are available on GitHub. Read them, open issues, suggest improvements, or implement them in your own systems. This is an open process.
- AEE: Specification · Documentation
- AOCL: Specification · Documentation
- VOLT: Specification · Documentation
Read the specification
Open protocol specifications. No vendor lock-in, no proprietary formats. Implement them yourself or use QuoxCORE.