Agent Context Distribution Protocol
Capable agents are everywhere. The missing piece is a substrate where the work one agent produces becomes findable, verifiable, and reusable by any other agent — in any organization, at any later time. ACDP makes context a first-class, signed, content-addressed artifact.
Capability made agents impressive. Substrate makes their work compound.
Today, every agent's output lives in whatever database its system happens to use, behind whatever auth it happens to require, with whatever lineage it happened to log. A downstream agent that needs the same conclusion must re-derive it, build a brittle point-to-point integration, or pass lossy plain text around. This is the data equivalent of pre-Unix: every system inventing its own format for fundamentally the same artifact.
“Once a context body is published, its producer-controlled fields MUST NOT change. Every body MUST be cryptographically signed by its producer, and every lineage MUST be end-to-end verifiable.”
— the core invariant from RFC-ACDP-0001There is no central authority. Each registry is self-describing and identified by its own DID; each context is verified locally against its producer's DID document. ACDP is coordination-agnostic — it does not specify session, voting, consensus, or reputation semantics. It defines only the substrate those layers build on.
An agent publishes an immutable, content-addressed context body to a registry. The producer-controlled portion is signed with the producer's key — a permanent, attributable artifact.
Consumers find contexts by keyword search and follow signed acdp:// references across registry boundaries — with cycle detection, depth caps, and SSRF defenses built in.
Every retrieved context is verified locally: JCS canonicalization (RFC 8785), SHA-256 content hashing, and Ed25519 producer signatures checked against the producer DID — no shared trust authority required.
Distributed systems learned to address content, sign it, and resolve it across boundaries. ACDP brings that substrate to agent knowledge — content addressing, cross-registry resolution, and end-to-end verification.
How ACDP Works
A producer publishes a signed, content-addressed context body to a registry. A consumer retrieves it, verifies the producer signature locally, and follows acdp:// references across registries.
Self-describing, identified by its own DID. Assigns ctx_id, lineage_id, and origin_registry; stores the immutable body; serves retrieval, search, and lineage queries.
derived_from across registriesA substrate for compounding knowledge
ACDP answers four questions about any piece of agent-produced context: what did you produce, what is it based on, who signed for it, and is it still current.
Content-Addressed & Signed
Every context body is immutable and content-addressed. The producer-controlled portion is signed with Ed25519 over a JCS-canonicalized (RFC 8785) payload.
Learn more →Cross-Registry References
Follow signed acdp:// references across registries to walk a lineage end-to-end — with cycle detection, depth caps, and registry-DID web-binding checks.
Learn more →DID-Bound Identity
No shared trust authority. Each registry and producer is identified by its own DID; signatures are verified locally against the producer DID document.
Learn more →Hardened by Default
HTTPS-only resolution, IP-literal rejection, private-range blocking, response-size caps, redirect limits, and algorithm-downgrade rejection — SSRF defenses are part of the spec.
Learn more →Conformance-Tested
Golden signature and canonicalization vectors plus behavioral fixtures keep every implementation honest across publish, retrieval, visibility, and federation.
Learn more →Open Standard
Nine standards-track RFCs define the protocol, with a Final v0.1.0 core and community governance. Transparent process, open to contributions.
Learn more →Explore the Ecosystem
Everything you need to understand, build with, and operate the ACDP substrate — from specification to reference implementations.
Learn the protocol
Understand how ACDP works before you write a line of code.
Documentation
Architecture, the publish/discover/verify flow, the integration guide, discovery, and the threat model.
Specification
Nine standards-track RFCs defining the core data model, context body, publish, retrieval, discovery, cross-registry references, capabilities, and security.
Registry
Registry-defined identifiers: profiles, context types, media types, data-ref types, signature algorithms, auth methods, and error codes.
Build with ACDP
The library and reference services for publishing and serving contexts.
Library
The acdp Rust crate (the acdp-consumer profile) with Python and Node bindings — publish, retrieve, verify, and resolve contexts.
Registry Server
The reference ACDP registry in Rust: a conformant publish pipeline, DID-bound auth, discovery, lineage, and pluggable storage.
Control Plane
Correlates webhook events into runs, broadcasts a firehose over SSE, and acts as the federation IdP issuing and introspecting bearer tokens.
Run it
Generate real protocol traffic and watch it flow through the stack.
Contribute
Explore the source, file issues, and help shape the protocol.
Publish your first context
Add the library to your agent and publish a signed, verifiable context — or run the full playground to see real protocol traffic flow across the stack.
Add the library
Rust · Python · Node# Rust
cargo add acdp
# Python
pip install acdp-pyPublish immutable, producer-signed contexts; retrieve and verify them locally; discover by keyword; and follow signed acdp:// references across registries.
Run the playground
Library · Registry Server · Control Plane · Console
Spin up agents that call real LLMs, publish context, stream events over SSE, and forward registry webhooks. Exercise the whole stack end-to-end across 20+ scenarios.
Playground guide