Published: 17 September 2026

TL;DR: AdCP (Agent Communication Protocol, published by AgenticAdvertising.org) defines how a buy-side agent and a sell-side agent communicate to reach a bilateral deal. It operates across four layers: identity, proposal format, negotiation sequence, and deal record. For buyers, the practical significance of AdCP compliance is portability. An AdCP-compliant buy-side agent can negotiate with any AdCP-compliant sell-side agent, on any compliant marketplace, without bespoke integration. This is the same portability that OpenRTB created for auction-based programmatic, applied to bilateral deal negotiation.

When a buy-side agent and a sell-side agent negotiate an advertising deal, they need to speak the same language. Not a human language, but a protocol: a defined format for proposals, a defined set of message types, a defined structure for the deal record that results from a successful negotiation.

Without a shared protocol, every bilateral deal negotiation requires bespoke integration between the two agents involved. A buyer whose buy-side agent is built on Platform A cannot negotiate with a publisher whose sell-side agent is built on Platform B without a custom integration between the two platforms. That is not a scalable model.

AdCP (Agent Communication Protocol) is the IAB Tech Lab standard that solves this problem. It defines the protocol that all compliant agents use to negotiate with each other, regardless of which platform built them.

Layer One: Identity

Before any proposal is submitted, both agents verify who they represent. The buy-side agent presents credentials that confirm it is authorised to negotiate on behalf of the buying organisation. The sell-side agent presents credentials that confirm it represents the publisher.

This verification happens through the marketplace infrastructure, which confirms the credentials against the registered identity of both organisations. An agent without valid credentials cannot begin a negotiation through an AdCP-compliant marketplace.

Why this matters: Identity verification means that when a buy-side agent receives a proposal acceptance from a sell-side agent, it can trust that the acceptance comes from an agent that has been verified as representing the publisher. Without identity verification, the bilateral deal model would be susceptible to impersonation: a bad actor could deploy a sell-side agent claiming to represent a premium broadcaster and collect deal commitments from buyers who had no way to verify the claim.

Layer Two: Proposal Format

A deal proposal in AdCP has a defined schema. It specifies the inventory being offered, the proposed CPM, the content category, the deal duration, the audience conditions, and any other terms relevant to the specific deal type.

Both the buy-side agent and the sell-side agent can parse a proposal written in the AdCP schema, regardless of which platform built them. The proposal format is the shared language. A buy-side agent submits a proposal in the AdCP format. The sell-side agent reads it. No translation between proprietary formats is required.

Why this matters for buyers: A buy-side agent that is AdCP-compliant does not need to know which platform built the sell-side agent it is negotiating with. The proposal it submits will be readable. The counter-proposal it receives will be in a format it can parse. The common schema is what makes cross-platform negotiation possible without bespoke integration.

Layer Three: Negotiation Sequence

AdCP defines the valid sequence of messages in a negotiation. The buy-side agent submits a proposal. The sell-side agent can respond with an acceptance, a counter-proposal, or a rejection. If the sell-side agent counter-proposes, the buy-side agent can accept, counter-propose further, or withdraw.

The defined message types mean both agents know what to expect at each stage. An acceptance means the deal is agreed. A rejection means the negotiation is over. A counter-proposal means a new set of terms is being offered, in the same proposal schema format, with the same fields.

Why this matters: Without a defined negotiation sequence, agents built by different platforms would not share an understanding of what each message type means. An acceptance message in one platform's proprietary format might look like a counter-proposal to an agent built by a different platform. The defined sequence eliminates that ambiguity.

Layer Four: Deal Record

When two agents reach agreement, the agreed terms are written to a DealSheet in the AdCP-specified format. The DealSheet contains all the terms agreed during the negotiation: the CPM, the inventory parameters, the content category, the deal duration, the identities of both parties, and the timestamp of agreement.

The DealSheet format is the same regardless of which platform built the agents or which marketplace hosted the negotiation. A buyer who retrieves a DealSheet from Alkimi receives a document in the same format they would retrieve from any AdCP-compliant marketplace. The standard format makes the record portable and independently readable.

The Portability Benefit

The practical benefit of AdCP compliance is portability, and it operates in two directions.

For buyers: An AdCP-compliant buy-side agent can negotiate with any AdCP-compliant sell-side agent. The buyer is not restricted to publishers whose sell-side agents were built on the same platform as their buy-side agent, or who have negotiated a direct integration. Any AdCP-compliant sell-side agent is a potential counterparty. The standard creates an open bilateral deal market rather than a collection of closed bilateral integrations.

For publishers: An AdCP-compliant sell-side agent can receive proposals from any AdCP-compliant buy-side agent. The publisher is not restricted to buyers who use the same platform or have negotiated direct access. Any AdCP-compliant buy-side agent operating under a valid mandate is a potential buyer.

This portability is the agent-to-agent equivalent of what OpenRTB created for auction-based programmatic. Before OpenRTB, connecting a DSP to an SSP required bespoke integration. After OpenRTB, any OpenRTB-compliant DSP could transact with any OpenRTB-compliant SSP. AdCP creates the same outcome for bilateral deal negotiation: any compliant buy-side agent can negotiate with any compliant sell-side agent, through any compliant marketplace, without bespoke integration.

The standard is the infrastructure that makes the market scalable. Without it, bilateral deal negotiation remains a collection of point-to-point integrations. With it, it becomes a market.