AdCP
AdCP (the Ad Context Protocol) is an active, open, versioned protocol for agentic advertising. It is evolving — not a finished universal standard — but it defines a shared vocabulary and interaction model that buyer agents and seller agents can implement today. AdCP sits at the advertising-specific layer of the stack: the protocol through which demand-side and supply-side agents discover each other, evaluate fit, negotiate terms, and report outcomes in structured formats both parties can interpret without custom integration for every pairing.
Why Advertising Agents Need a Protocol
In AI-native advertising, buyer agents and seller agents operate continuously and at scale. A buyer agent may evaluate hundreds of supply opportunities in the time a human buyer would review one. A seller agent may field demand signals from many buyers simultaneously. Each exchange requires both sides to express intent, constraints, and supply characteristics in forms the other party can parse and act on.
Without a shared protocol, every buyer-seller pair needs a bespoke integration: custom field names, custom validation rules, custom error handling. That model does not scale as the number of agents and publishers grows. A protocol layer solves the scaling problem by standardizing what gets said and how — so agents that implement compatible versions can interoperate even when they were built by different vendors.
The need is structural, not cosmetic. Agents are interpretive systems: they reason about campaign briefs, evaluate supply descriptors, and decide whether a placement meets principal-defined constraints. They require semantically rich, typed messages — not minimal REST payloads designed for deterministic callers. AdCP is designed for that class of client.
What AdCP Standardizes
AdCP governs how buyer and seller agents interact across the full campaign lifecycle:
Discovery — finding supply that matches campaign intent
Planning — evaluating fit, suitability, and reach before committing budget
Buying and selling — negotiating and executing placement terms
Measurement — reporting outcomes against agreed definitions
Within each phase, AdCP standardizes the message shapes agents use to express constraints, propose terms, attach supporting data, and record commitments. Supply descriptors and provenance records travel inside these messages, but AdCP is not a supply-description format alone. It is the protocol through which the full agent handoff happens.
AdCP implementations share three design commitments:
Declarative. Agents express supply properties, campaign requirements, and negotiation terms as structured fields rather than free text that each party must parse independently.
Extensible. The protocol accommodates additional fields and metadata across versions without breaking existing implementations on core message types.
Provenance-aware. AdCP includes formats for attaching chain-of-custody information to supply claims, so buyer agents can evaluate the reliability of assertions alongside the assertions themselves.
These commitments align AdCP with the broader shift toward agentic protocols — semantically rich interfaces designed for interpretive clients operating on behalf of principals with auditable constraints.
How AdCP Relates to MCP and A2A
AdCP operates at a different layer than general agentic infrastructure protocols.
MCP (the Model Context Protocol) standardizes how an AI model accesses external tools and data sources. A buyer agent might use MCP to retrieve a campaign brief from a planning tool or to query a supply intelligence database. MCP is the agent-to-tool layer; it is not advertising-specific.
A2A (Agent-to-Agent) standardizes communication between autonomous AI agents — how they announce capabilities, exchange structured requests and responses, and maintain context across multi-turn exchanges. A2A addresses general agent coordination; it is not scoped to advertising workflows.
AdCP applies similar protocol principles to the advertising domain: discovery, planning, buying, selling, and measurement between buyer and seller agents. In a typical stack, a buyer agent might use MCP to assemble inputs and AdCP to conduct the advertising-specific negotiation. The layers compose; they do not compete.
Foundations Unit 8 covers this multi-protocol landscape in overview. This page focuses on the AdCP layer only.
Where Supply Descriptors Fit
A supply descriptor is the structured record through which a publisher describes inventory to machine buyers. AdCP does not replace the concept of a supply descriptor — Foundations Units 4 and 5 cover what descriptors contain and why they matter — but it standardizes how descriptors are referenced, versioned, and enriched in agent exchanges.
In discovery, seller agents (or supply intelligence systems acting on their behalf) return descriptors that match a buyer agent's eligibility query. In planning, buyer agents request additional detail on specific descriptors before advancing candidates to negotiation. In buying and selling, commitment records reference the descriptor version that was evaluated — so later disputes or measurement reconciliation can trace back to the exact claims both parties agreed on.
Supply descriptors and provenance travel together in AdCP messages. A buyer agent evaluating a suitability claim can inspect provenance for that claim specifically — who asserted it, when, and on what basis — rather than accepting or rejecting the entire descriptor as a unit. This granular trust evaluation is part of what makes machine-mediated buying auditable at scale.
What AdCP Does Not Do
Clarity about scope prevents misaligned expectations:
AdCP is not a finished universal standard. It is actively evolving. Implementations declare supported versions; semantics for core fields continue to mature as adoption grows.
AdCP is not campaign execution for human principals. It defines how agents communicate; principals still set goals, budgets, and policy. Agents operate within those constraints — they do not replace strategic decision-making.
AdCP is not a user-tracking or audience-data protocol. It carries supply and demand signals structured for agent evaluation. It does not define how publishers collect or share personal data.
AdCP is not an auction or real-time bidding protocol. Agent negotiation under AdCP is structured exchange — proposals, counteroffers, and commitments — not a simultaneous sealed-bid auction. Legacy programmatic systems may coexist in the same organization; AdCP addresses a different interaction model.
AdCP is not owned by any single company or vendor. It is an open protocol. Multiple organizations can implement compatible agents and infrastructure. No implementor defines the category by virtue of participating in the protocol.
Why This Matters
For publishers, implementing AdCP-compatible seller agent infrastructure means visibility to any buyer agent that speaks the same protocol — without negotiating a custom integration for each demand source.
For advertisers and agencies, AdCP-compatible buyer agents can evaluate supply from multiple publishers through a shared vocabulary, with provenance and versioning discipline that makes automated decisions auditable.
For builders, AdCP provides a stable target for the advertising-specific layer while MCP and A2A handle general agentic infrastructure. Protocol agnosticism — building systems that can adapt across protocol versions and interoperate through adapters — is a reasonable engineering posture while the landscape remains early.
In practice
A media agency operates a buyer agent connected to several publisher seller agents, all implementing compatible AdCP versions. The buyer agent queries for supply matching a campaign brief, receives structured descriptors with provenance attestations, evaluates fit in a planning phase, and converges on placement terms over a short negotiation exchange. The commitment record references the descriptor version evaluated. Two weeks later, measurement reporting references the same commitment. Neither the agency nor the publishers built custom connectors for each pairing — they implemented the shared protocol.
The glossary provides L0 and L1 definitions for every term used on this page. Foundations Unit 8 provides the multi-protocol landscape. When a published normative specification exists on the Open Source surface, it is the authoritative L3 detail beneath this treatment.