Transport-Neutral by Design

Transport-neutral means a DCP message travels inside a transport envelope — a mesh frame, a queue payload, an HTTP body, a file — but stays independent of it and remains independently readable and validatable on its own. Moving a DCP message from one transport to another is a transport swap, not a rewrite: the DCP body is never rewritten at the boundary.

Two envelopes, two jobs

DCP’s layering invariant (SPEC §2) draws one line and asks you never to cross it:

Transport-layer envelope = transport / trust / routing. DCP envelope = semantics / validation / correlation.

Every DCP message sits inside some outer envelope supplied by whatever moves it — that outer envelope carries delivery concerns: who sent it, whether the channel is authenticated, where it’s routed, whether it was acknowledged. The DcpMessage envelope inside it carries only meaning: which entity changed, what changed, and how this message relates to a prior one. Neither envelope substitutes for the other, and a conformant consumer keeps them separate.

This is why a DCP message is untrusted data carried by a transport: the transport earns trust through authentication and access control, and DCP earns nothing — it only describes.

Why the fields overlap, and why that’s not a contradiction

Both layers have identifier-shaped fields, and that’s intentional, not sloppy. message_id and correlation_id exist in the DCP envelope for audit and correlation — linking one recorded change to another in project terms. A transport has its own delivery ID, session token, or routing key for an entirely different purpose: getting bytes to the right place exactly once (or at least once, or best-effort, depending on the transport).

The overlap in shape is permitted only because the purpose differs. A consumer MUST NOT treat a DCP field as a transport guarantee — message_id gives you no deduplication, correlation_id gives you no delivery ordering, and dcp_version gives you no session state. Reading transport semantics into a DCP field, or vice versa, is exactly the mistake this invariant exists to prevent. See the envelope reference for the full field table and requirement levels.

One example transport among many

AgentixMesh is one transport DCP can ride — a secure mesh handling identity, permissions, discovery, and message wake-up. It is deliberately one example, not a dependency: the same DcpMessage JSON is equally valid dropped into a message queue, posted to an HTTP endpoint, written as a line in a file, or stored as a database row. DCP has no import, no client library requirement, and no protocol handshake with any of them. A validator checking a DCP message against the schemas at https://schemas.devcopro.org/v1/ never needs to know which of these carried it.

That is the practical payoff of transport-neutrality: a review council producing a finding.raised event and a human editing the same JSON by hand produce structurally identical, equally valid DCP messages, regardless of what moved the bytes.

What this rules out

Because the transport and DCP stay layered, a few things are explicitly out of scope for DCP:

• DCP does not sign, encrypt, or authenticate anything — that’s the transport’s job.
• DCP does not guarantee delivery, ordering, retries, or acknowledgement.
• A transport MUST NOT route, authorize, or trust decisions based on message_type — it’s a denormalized convenience copy of <entity_type>.<verb> for human readability, and the body is the normative source (SPEC §4.1).
• Extensions (x-agentixmesh-* and similar reserved-looking keys) carry no transport authority even when their names suggest they might.

If you’re evaluating DCP against transport-coupled alternatives, DCP vs. webhooks walks through a concrete comparison where the transport-coupling difference matters most: a webhook’s shape is inseparable from HTTP, while a DCP message is not.

Why it’s designed this way

A coordination vocabulary that’s welded to one transport can only be adopted by systems using that transport. DCP’s reason for existing as a shared vocabulary is to let independently built agents and tools agree on what a task.completed or decision.recorded event means, without agreeing on how it moved. Keeping the two envelopes strictly separate is what makes that portability possible — you can change transports, mix transports, or add a new one, and every existing DCP message and validator keeps working unchanged. Try it yourself in the quickstart, which validates a message with nothing but a JSON Schema validator and no transport at all.

By InterIP Networks · Last updated 2026-07-01.