What Is ACP (IETF Agentproto)? The Beginner's Guide to the SIP-Style Wire Format for Agent Dialogs

CodexFuse Team · 2026-11-05T16:35:55.848Z · 25 min read min read

What Is ACP (IETF Agentproto)? The Beginner's Guide to the SIP-Style Wire Format for Agent Dialogs

What Is ACP (IETF Agentproto)?

ACP is the IETF's Agent Communication Protocol, a SIP-style wire format for long-lived dialogs between a principal and an AI agent. The draft that defines it is draft-liu-agentproto-acp-00, written by Dapeng Liu of Alibaba and published on November 2, 2026. Searchers asking what is ACP IETF want exactly this draft, and this guide explains it in plain English.

The draft is 52 pages long and three days old at the time of writing. It is an Internet-Draft with an intended status of Standards Track, which means it is a proposal working toward becoming a standard, not a standard yet. It expires on May 6, 2027, unless a new revision replaces it first.

Three different protocols share the letters ACP, so say which one you mean. This guide is about the ACP SIP style protocol from the IETF agentproto working group, the one that carries agent dialogs. It is not the Agent Client Protocol that connects code editors to coding agents, and it is not RFC 8994, the Autonomic Control Plane for network devices.

A SHA-256 hash generator shows the same idea ACP relies on: a short digest can prove a file's contents without sending the file anywhere. ACP applies that idea to a whole conversation, one entry at a time. If your agent runs on a remote machine, VPS hosting is the usual way to keep that work separate from your laptop, and an ACP dialog is the session that survives when the connection to that machine drops.

No independent explainer, how-to, or review of the IETF ACP exists anywhere else as of November 5, 2026. Everything below comes from the draft text itself, its Datatracker record, and the sibling drafts it references, all fetched on November 5, 2026.

Why Do Agent Dialogs Need a Wire Format at All?

An agent dialog is not a web request. It can run for hours or days, go quiet for long stretches, move between hosts, and survive the loss of whatever connection was carrying it.

The problem ACP solves is not reliability, because QUIC already delivers a stream without gaps. The problem is the interval between connections: an agent may finish work while its principal is offline, an acknowledgement may never arrive, and a server may crash having lost its last few entries.

Each side then holds a plausible history, with no shared clock and no shared connection to arbitrate between them. ACP answers with a hash chain, so the two sides can compare digests and agree on exactly which entries both hold.

The agentproto architecture draft names Agentic Dialog Management as a building block and requires an identifier that outlives the transport. It leaves the wire format out of scope, and ACP is the draft that fills that gap.

ACP is deliberately narrow. It is not an identity mechanism, not an authorization mechanism, and it introduces no new cryptographic construction. It takes the identity and authorization model from the architecture draft and states where it rides.

How Does an ACP Message Look?

Every ACP message has one shape: a start line, a block of text header fields, a blank line, and an optional body. A request line reads as a method, a space, a request URI, a space, and the version marker ACP/1.0. A response line reads as ACP/1.0, a space, a status code, a space, and a reason phrase.

The request URI is an https URI naming the agent service, and it is the same in every request of a dialog. Its userinfo, query, and fragment components must not be used. The https scheme does not mean ACP runs inside HTTP: how the URI is reached is a property of the binding.

The body is an opaque octet string whose extent is given by Content-Length, and no transfer encoding is defined. Field names are case-insensitive, and a field must not appear more than once unless its definition says otherwise. A recipient must ignore a header field it does not recognize unless the method marks it required, which is what lets a field be added without a version change.

The draft chose text over a structured data format for two reasons. A text start line and text headers can be read by a human in a log and generated by a shell script, and the body is carried as raw octets with no field ordering to normalize. That means the digest of an entry is the digest of a byte string both endpoints already hold verbatim, which a format that serializes differently across implementations cannot offer.

INITIATE https://agent.example.com/travel ACP/1.0
CSeq: 1 INITIATE
ADID: 9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d
From: spiffe://example.org/ns/agent/client-1
To: spiffe://example.com/ns/agent/travel
Authorization: Bearer <token>
Supported-Modalities: text/plain, image/*, audio/opus
Session-TTL: 259200
Content-Length: 0

ACP/1.0 200 OK
CSeq: 1 INITIATE
ADID: 9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d
Session-TTL: 259200
Tail-Seq: 0
Tail-Hash: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Min-Seq: 1
Content-Length: 0

The exchange above is the draft's own worked example, not a real deployment. The ADID, the SPIFFE identities, and the service URI are illustrative values from the draft. An unparseable start line earns a 400 response, and an unsupported method earns a 501.

What Is an ADID, and Why Does a Dialog Need One?

A dialog is named by an Agentic Dialog Identifier, or ADID. The ACP ADID dialog identifier is a version 4 UUID: 122 bits from a cryptographically secure random source, written as 36 lowercase hexadecimal digits in five hyphen-separated groups, so it can be compared verbatim.

The client generates the ADID and sends it in INITIATE, and the server echoes it in the final response. It must not be chosen or influenced by a peer of the generator, and it must not be reused, including for an INITIATE that went unanswered. Collisions are negligible, so no registration is needed.

The ADID identifies the dialog, not the connection. A dialog that moves to a new connection keeps its ADID and its log position, which is the whole point: the dialog survives any number of connections, while transport state survives nothing.

An ADID is not a credential. It is opaque and non-self-certifying, and it reveals nothing about the dialog, so knowledge of an ADID is not authority to use it. Because it appears in every message, it will end up in logs, proxies, and error reports, and a deployment should treat a leaked ADID as a reason to terminate and re-initiate.

How Does the Hash-Chained Log Keep a Dialog Honest?

A dialog's durable state is its log: an ordered, append-only sequence of entries. Each entry occupies exactly one Sequence number, starting at 1 with no gaps, and both participants hold a replica. The server is the ordering authority in this version, so its replica is authoritative.

Each entry carries a digest called Entry-Hash. It is the string sha256- followed by 43 unpadded base64url characters, computed over six field values joined by line feeds, followed by the body octets. The first entry's previous hash is the constant GENESIS, which is sha256- followed by 43 letter A characters, the base64url form of 32 zero octets.

A digest proves two replicas hold the same bytes. It is not a signature, and it does not prove who produced the bytes, because per-entry signatures are deferred to a later revision. Anyone able to write to the authoritative replica can set the Author string inside a digest.

An entry closes exactly one complete event: one turn, one tool call with its result, or one accepted utterance. Half a turn must not become an entry, which is what makes the chain cheap under streaming: fragments flow unhashed, and when generation ends, the completed event is gathered into one body and appended as one entry. There are five entry types: input, output, meta, abort, and system.

An APPEND sent but not finally answered leaves its entry pending, not committed. Its author must not report it as the tail, must not use its hash as the next previous hash, must retain it until alignment settles it, and must not present it to the application as history without marking it unconfirmed. Alignment settles pending entries by digest comparison, so nothing is lost and nothing is duplicated.

A checkpoint is itself an entry of type system, with a four-line body that commits to a log prefix. After both participants record it durably, entries below it may be discarded and Min-Seq advances, but sequence numbers are never reset. A dialog checkpointed a hundred times still has one continuous numbering.

Alignment runs on RESUME. The client names its last committed entry with Tail-Seq and Tail-Hash, and one exchange decides the outcome: equal tails earn a 200, a server that is ahead answers 206 with an instruction to replay from a given sequence, and a disagreement earns a 409 with an instruction to probe. A client below the server's Min-Seq earns a 412 and must resync from the checkpoint.

PROBE carries a ladder of proof pairs at powers-of-two steps below the tail, at most 16 in total. A 16-pair ladder reaches 32,768 entries below the tail, according to the draft. The highest matching position is the common ancestor: the client rolls back above it, accepts a replay, and renumbers and resubmits its own pending entries.

What Are ACP's 8 Methods, 26 Headers, and 17 Status Codes?

ACP defines 8 methods, 26 header fields, and 17 status codes. The methods cover the whole life of a dialog, from creation to termination, and the codes borrow their shape from SIP and HTTP while meaning something specific to dialogs.

Control requests and responses are matched by CSeq, which is a sequence number, a space, and the method. Each participant keeps one counter per dialog starting at 1, independent of log Sequence numbers, and a response echoes it verbatim. A repeated CSeq is discarded, which makes requests safe to repeat after a connection is replaced.

At most one APPEND may be outstanding per dialog.

The 26 header fields are ADID, CSeq, From, To, Sequence, Prev-Hash, Entry-Hash, Entry-Type, Author, Timestamp, Event-Cursor, Tail-Seq, Tail-Hash, Min-Seq, CP-Seq, CP-Hash, Replay-From, Action, Proof, Session-TTL, Supported-Modalities, Target-Seq, Reason, Authorization, Content-Type, and Content-Length. Most of them exist to carry the log's bookkeeping: where an entry sits, what came before it, and what its digest is.

Two codes deserve a warning. The 206 and 412 responses are not HTTP byte-range responses: they report alignment outcomes, replay and resync. Class 1xx is reserved with nothing defined, and class 3xx is undefined in this version.

Two timers bound the waiting. T1 is 5 seconds, the bound on waiting for a final response, and on expiry the transaction fails locally and the participant must align before relying on it. T2 is 60 seconds, the bound on completing a replay announced by a 206, which is 12 times T1.

There is no retransmission timer and no hop-by-hop acknowledgement, because every channel ACP uses is reliable and ordered within a connection.

How Does a Dialog Live, Sleep, and Resume?

A dialog has six states: IDLE, INITIATING, ACTIVE, SUSPENDED, ALIGNING, and TERMINATED. Dialog state is a property of the ADID and survives any number of connections. Transport state is a property of the connection and survives nothing.

Where QUIC connection migration works, a path change keeps the dialog ACTIVE with no ACP message at all. The dialog is keyed to the ADID and log position, never to a socket.

Session-TTL is measured from the moment the dialog was suspended, not from creation. The default is 259,200 delta-seconds, which is 72 hours, and the clock restarts on each successful APPEND, RESUME, or CHECKPOINT. On expiry the dialog is terminated and its state may be purged, and a later RESUME fails with a 404.

CANCEL does not change dialog state. It stops work caused by an entry already in the log, the entry stays, and an abort entry records the cancellation.

The draft's worked example shows the whole life in one exchange. The client sends INITIATE with an ADID, From, To, and Supported-Modalities, and the server answers 200 with the same ADID, a Session-TTL, and Tail-Seq 0. Two APPENDs commit entries at Sequence 1 and 2, media and progress flow on their own channels, and then the connection dies and both sides are SUSPENDED.

The client sends RESUME with Tail-Seq 2 and Tail-Hash, the server answers 206 with an instruction to replay from Sequence 3, the missed entries are replayed, and both sides are ACTIVE again.

How Does ACP Travel Over MoQ and WebTransport?

ACP semantics are transport-independent, and revision -00 binds them to two transports. A binding must provide a reliable ordered bidirectional control channel, a reliable ordered log channel that does not share a head-of-line queue with control, a way to carry asset octets without blocking either, and a signal when the connection is lost. It should also provide an unreliable low-latency channel for progress traffic and connection migration.

Every stream a binding opens begins with a preamble: the text ACP/1.0, a space, and a channel name, followed by a line ending. The channel names are control, log, and asset, plus any token a binding defines.

In the MoQ binding, a dialog occupies one track namespace made of the authority, the string acp, and the ADID. The authoritative log is the track named log, published only by the ordering authority, with one committed entry per object: the group is the Sequence number and the object is 0. One object per entry, not split per MIME part, so verification is a single pass over what arrived.

Replay after resumption is a SUBSCRIBE to the log starting at the group after Tail-Seq, so recovery becomes a subscription, served by whatever cache can serve it. Relay caching is an optimization, not a store: the ordering authority must be able to serve the whole retained range itself. Use this binding where a dialog should be relayable and cacheable by MoQ-aware infrastructure.

In the WebTransport over HTTP/3 binding, the client opens a WebTransport session to the https request target with an extended CONNECT, and one session may carry more than one dialog. The control plane is the first bidirectional stream the client opens, one log entry is one unidirectional stream opened by the entry's author and closed when the entry is complete, and one asset is one unidirectional stream at lower priority than the log.

Progress traffic rides QUIC datagrams, and a change of network path is handled by QUIC connection migration while the dialog stays ACTIVE. Use this binding where one endpoint is a browser or another environment that offers WebTransport but not a general QUIC stack.

The same transport is being adopted next door: MCP over MoQ defines how the Model Context Protocol runs on MoQ, so the application protocol that would run inside or alongside an ACP dialog shares the same plumbing.

The ACP MoQ WebTransport bindings are the two concrete transports in revision -00, and the draft says more bindings can follow. The semantics stay the same whichever binding carries them.

ACP vs PACE vs A-SIP: Where Does ACP Sit?

The ACP agent communication protocol draft is not the only candidate for the agentproto dialog layer, and it is not the settled one. The working group has sibling drafts that cover neighboring problems, and one direct rival for the same slot. The ACP vs PACE comparison is the most useful starting point, because the two drafts answer different questions.

PACE, the Protocol for Agent Communication Exchange, is a 62-page draft from November 1, 2026, which is 10 pages longer than the ACP draft. It defines a transport-independent dialog context and control operations to establish, modify, and terminate dialogs, with a binding to MoQ. Application protocols such as A2A, MCP, and AutoGen keep their own message formats and carry the dialog context through their own extension points.

PACE manages dialog context and lets existing protocols keep their formats; ACP defines the wire format itself, with SIP-style messages and a hash-chained log. PACE binds to MoQ only, while ACP binds to MoQ and WebTransport.

A-SIP is the direct rival. The Agentic Session Initiation Protocol, drafted by Rosenberg in November 2026, defines a protocol that can play the role of the Agent Communications Protocol. It is built on HTTP/3, WebTransport, and MoQ, but it is explicitly not yet a fully fleshed out protocol and is meant to solicit feedback.

Despite the name, it states it has no technical relationship with SIP, which is the opposite design choice from draft-liu ACP. A-SIP is the name to watch if the working group debates which wire format wins.

Two more siblings cover different layers. AACP, the Agent Action Confirmation Protocol, is about confirming side-effecting agent actions with signed, verifiable evidence, so a human's confirmation cannot be fabricated by an intermediate agent. It rides on existing agent protocols and does not define dialog wire format.

The Agent-Human Interaction Overlay is a design note, not a protocol: it separates the responsible Participant from the authenticated Actor and records human interactions, and it specifies no wire protocol of its own.

Around the family, the AGNTCY messaging overview positions SLIM as a transport layer below ACP, handling secure routing and group messaging so protocol implementations can focus on agent semantics. AGTP Communication is real-time media on a separate AGTP substrate, not a dialog wire format. Agent Schema Interfaces standardizes skill schemas for network-management agents on top of A2A, and I2ICF is a domain framework for software-defined vehicles that uses A2A.

None of them rivals ACP; they sit above, below, or beside it.

The parent document is the agentproto architecture draft, published October 30, 2026, six days before this article. It is 31 pages long, which is 21 pages shorter than the ACP draft, and it defines the terminology and the three functional blocks: agentic dialog management, authorization and delegation, and identity management. ACP fills the dialog-management block with a wire format; the other blocks are still open work.

What Does ACP Deliberately Leave Out?

Revision -00 leaves five things out on purpose. How a client learns the https URI of the agent service, delegation between dialogs, per-entry signatures, concurrent access from several devices, and the media negotiation body are all stated as out of scope. A reader who expects any of them in the draft will not find them.

ACP defines no key exchange, no authentication mechanism, and no confidentiality mechanism of its own. It assumes a channel where the peer is authenticated, the channel is confidential and integrity-protected, and messages are not delivered to anyone else. Both bindings provide these through QUIC, which mandates TLS 1.3, and ACP must not be used over a transport that does not provide them.

Each participant holds a WIMSE workload identity, expressed as a SPIFFE ID and carried as the subject claim of a Workload Identity Token binding a public key. A recipient must check that the Author of an APPEND and the From of any other request equals the workload identity the channel authenticated, and must reject the message with a 403 if they do not. A participant must not accept dialog traffic on a channel that does not authenticate its sender.

Establishing a dialog uses existing OAuth mechanisms, not a new one. Within a trust domain the client presents a Transaction Token obtained from its workload identity, with narrow scope and short lifetime, per request. Across trust domains, OAuth 2.0 Token Exchange applies.

The channel-authenticated identity, the From of the request, and the identity the token authorizes must all name the same participant, or the server answers 403.

A server answers 403 to a sender it recognizes but has not authorized, and 404 to one it does not recognize, which deliberately reveals the dialog exists. A client recovering on a new device needs to know whether to resume or start over. A server may answer 404 to every unauthorized sender instead, at the cost of making recovery from a lost credential indistinguishable from a lost dialog.

Channel authentication proves who sent a message on the connection that carried it, and it does not survive the connection. A committed entry is attributed by an Author string inside a digest, which anyone able to write to the authoritative replica can set. Media is carried by reference, never as bytes the chain must digest: a MIME part may carry an Asset-Ref and an Asset-Size plus a Content-Location URL, while the asset's octets travel separately.

A log can be fully aligned and every digest verified while an asset is still missing, and that is intended.

The draft asks IANA to create an ACP Parameters registry group with six registries: methods, status codes, header fields, entry types, hash algorithms, and channel names. Their registration procedures and initial contents will be specified in a later revision. Token windows, scratch memory, and tool bindings belong to the application, not to ACP: the draft states plainly that it neither carries nor reconstructs model context, and losing it is not an ACP failure.

Who Should Watch ACP, and Who Should Wait?

ACP is three days old, a first revision, and an individual submission that the working group has not adopted. Nobody should build a production system on it today and expect the wire format to stay still. The right audience right now is protocol engineers, agent-infrastructure builders, and anyone implementing MoQ or WebTransport for agents.

The draft is worth reading in full if you build agent infrastructure, because it names the exact problem every long-lived agent session hits: two sides with plausible histories and no shared clock. The hash-chained log is the answer on the table, and the MoQ binding shows how recovery can become a subscription instead of a custom sync protocol.

Wait if you need a stable wire format, an implementation to test against, or a guarantee that the working group will pick this draft over A-SIP. Watch the Datatracker page for a -01 revision, which is the trigger that the draft is being revised rather than left to expire. The draft lapses on May 6, 2027, which is 182 days from today, unless a new revision is posted.

How Can You Trace an ACP Dialog in Five Steps?

You can trace a whole dialog by following the draft's own worked example. These five steps use the values from Figure 1 of the draft, and they show every mechanism in this guide in one exchange.

1. Open the draft and find the INITIATE exchange. The client sends INITIATE with an ADID, From, To, and Supported-Modalities, and the server answers 200 with the same ADID, a Session-TTL of 259,200 seconds, and Tail-Seq 0.
2. Follow the first APPENDs. Two entries commit at Sequence 1 and 2, each with a Prev-Hash pointing at the entry before it and an Entry-Hash proving the bytes. Media and progress flow on their own channels while the log grows.
3. Watch the connection die. Both sides move to SUSPENDED, the dialog keeps its ADID, and the Session-TTL clock starts from the moment of suspension, not from creation.
4. Send RESUME with the tail. The client names Tail-Seq 2 and its Tail-Hash, and the server answers 206 with an instruction to replay from Sequence 3.
5. Verify the replay. The missed entries arrive on the log channel, their digests chain from the tail the client already holds, and both sides return to ACTIVE with one continuous numbering.

That is the whole protocol in miniature: a name that outlives the connection, a log that proves its own history, and a resume that costs one exchange. Everything else in the draft is the detail that makes those three ideas hold up under real networks.

Sources

Every fact in this guide was fetched on November 5, 2026. The draft is the primary source for nearly all of it, and the sibling drafts are listed where they are named.

1. The Agent Communication Protocol (ACP), draft-liu-agentproto-acp-00 — https://www.ietf.org/archive/id/draft-liu-agentproto-acp-00.html

2. ACP draft, Datatracker record — https://datatracker.ietf.org/doc/draft-liu-agentproto-acp/

3. ACP draft, bibliographic record — https://datatracker.ietf.org/doc/draft-liu-agentproto-acp/00/bibtex/

4. Agentproto working group documents — https://datatracker.ietf.org/wg/agentproto/documents/

5. Architecture for AI Agent Communications on the Internet, draft-manyfolks-agentproto-arch-00 — https://www.ietf.org/archive/id/draft-manyfolks-agentproto-arch-00.html

6. An Overview of Messaging Systems and Their Applicability to Agentic AI, draft-mpsb-agntcy-messaging-03 — https://datatracker.ietf.org/doc/html/draft-mpsb-agntcy-messaging-03

7. AGTP Communication Protocol, draft-hood-agtp-communication-01 — https://www.ietf.org/archive/id/draft-hood-agtp-communication-01.html

8. The Agentic Session Initiation Protocol (A-SIP), draft-rosenberg-agentproto-asip-00 — https://www.ietf.org/archive/id/draft-rosenberg-agentproto-asip-00.html

9. Protocol for Agent Communication Exchange (PACE), draft-nandakumar-agentproto-moq-pace-00 — https://www.ietf.org/archive/id/draft-nandakumar-agentproto-moq-pace-00.html

10. Agent Action Confirmation Protocol (AACP), draft-liu-agent-action-confirmation-00 — https://datatracker.ietf.org/doc/html/draft-liu-agent-action-confirmation-00

11. Agent-Human Interaction Overlay, draft-okutomi-agent-human-interaction-01 — https://datatracker.ietf.org/doc/html/draft-okutomi-agent-human-interaction-01

12. Agent Schema Interfaces, draft-huang-ainetops-agent-schema-interfaces-00 — https://datatracker.ietf.org/doc/html/draft-huang-ainetops-agent-schema-interfaces-00

13. Model Context Protocol and Agent Skills over Media over QUIC Transport, draft-jennings-agentproto-mcp-over-moqt-01 — https://datatracker.ietf.org/doc/html/draft-jennings-agentproto-mcp-over-moqt-01

14. Agent Client Protocol, official site — https://agentclientprotocol.com/

15. Autonomic Control Plane, RFC 8994 — https://www.ietf.org/ietf-ftp/rfc/rfc8994.html

Frequently Asked Questions

Is ACP an official IETF standard?

No. ACP is revision -00 of an Internet-Draft published on November 2, 2026, an individual submission with an intended status of Standards Track that the working group has not adopted. It expires on May 6, 2027, unless a new revision replaces it.

What is the difference between the IETF ACP and the Agent Client Protocol?

They share only three letters. The IETF ACP is a SIP-style wire format for long-lived agent dialogs over MoQ and WebTransport, while the Agent Client Protocol is a JSON-RPC protocol over stdio that connects code editors such as Zed to coding agents. Different problem, different layer, different venue.

What is an ADID in ACP?

The Agentic Dialog Identifier is a version 4 UUID with 122 bits of randomness, written as 36 lowercase hexadecimal digits in five hyphen-separated groups. It names the dialog, not the connection, so a dialog keeps its ADID when it moves to a new connection. It is not a credential: knowing an ADID gives no authority to use the dialog.

How does ACP recover a dialog after the connection drops?

The client sends RESUME with its last committed Tail-Seq and Tail-Hash. Equal tails earn a 200, a server that is ahead answers 206 with a replay instruction, and a disagreement earns a 409 with a probe instruction. A PROBE ladder of at most 16 proofs locates the common ancestor, and the client rolls back above it and accepts the replay.

Should I build on ACP today?

Not for production. The draft is three days old, a first revision, and a rival candidate called A-SIP competes for the same slot, so read it, prototype against it, and watch the Datatracker page for a -01 revision. Build on it when the working group adopts a revision and implementations appear.