AdCP / Advertising Context Protocol.
A practical guide to the open protocol layer for agentic advertising workflows: discovery, planning, buying, creative, signals, governance, accounts, and measurement.
AdCP gives advertising agents a shared task and schema layer. It helps buyers, sellers, platforms, data providers, and creative systems communicate through standardized advertising actions rather than bespoke dashboard workflows and one-off integrations.
AdCP is not a replacement for OpenRTB, clean rooms, or human judgment. It is a protocol layer for making advertising work discoverable, executable, governable, and auditable by agents.
- AdCP 3.1 GA · v3.1.8 · Jul 2026
- AdCP 3.0 prior line · wire-compatible
- v2 deprecates Aug 1, 2026
- Sponsored Intelligence experimental
Fast read
- What it is
- An open agentic advertising protocol that defines domain-specific tasks and schemas for advertising agents.
- What it does
- Helps agents discover inventory, set up accounts, buy media, manage creative, activate signals, apply governance, and report results through standardized calls.
- What it is not
- Not a media exchange, identity graph, DSP, SSP, clean room, or replacement for OpenRTB.
- Why it matters
- Agentic workflows need repeatable, machine-readable actions. Without a shared protocol, every agent has to learn every platform separately.
- Current state
- AdCP 3.1 is the current general-availability line; the latest tagged release is v3.1.8 (GitHub, July 28, 2026 — wire-negotiation pin stays "3.1"). It is additive over 3.0 — a 3.0 integration keeps working with no code change. v3.1.3 was withdrawn days after shipping (see the version-watch section below); official docs still point implementers to v3.1.2. Validate implementation details against current official docs.
- Best next step
- Understand the domains, then decide which workflow your company should expose or consume first.
What AdCP is.
AdCP is a shared advertising task layer for AI agents. It defines what agents can ask for, what systems should return, and how actions move through the advertising workflow.
| Layer | Job | Example |
|---|---|---|
| Transport | Carries messages | MCP / A2A |
| AdCP | Defines advertising tasks and schemas | get_products, create_media_buy, get_signals, activate_signal |
| Execution system | Performs the action | publisher, SSP, DSP, creative system, data provider |
| Governance | Controls authority and audit | approvals, signatures, idempotency, audit logs |
| Existing ad standards | Power underlying objects and transactions | OpenRTB, AdCOM, OpenDirect, Deals API |
Why AdCP exists.
Fragmented workflows
Media buying, creative, data activation, accounts, and reporting still live across disconnected systems and dashboards.
Agents need actions, not screens
An agent cannot scale by clicking through every platform UI. It needs task-level interfaces.
Common schemas reduce ambiguity
Natural-language briefs need to resolve into structured, auditable requests.
Human oversight needs architecture
Agentic buying requires approvals, limits, audit logs, and accountability built into the flow.
Platform participation needs standards
Publishers, data providers, creative systems, and ad platforms need a shared way to expose what agents are allowed to do.
What’s new in AdCP 3.1.
AdCP 3.1 is now the current general-availability line (latest tag v3.1.8; official docs point implementers to v3.1.2), additive over 3.0. Separate what shipped from the obligations adoption brings and what to watch next.
Confirmed — AdCP 3.1 (GA · v3.1.8)
- AdCP 3.1 is the current general-availability line — GA at GitHub tag v3.1.0 (June 18, 2026), patched through v3.1.2 (June 30 – July 8, 2026; protocol-only fixes and spec clarifications). v3.1.3 (July 13) was withdrawn days later — official notice: it added a stable protocol schema field in a patch release, violating the 3.1.x versioning contract, plus a publisher-domain filter bug accepting a plural selector shape the schema rejects; official docs still point implementers to v3.1.2 as the confirmed target. Further patches followed at v3.1.4 (July 19) through v3.1.8 (July 28, the latest tag); v3.1.6–v3.1.8’s GitHub release bodies are version-only, with no documented content beyond the version bump. The wire-negotiation pin is the string "3.1"; SDKs normalize "3.1.x" → "3.1". v2 is fully deprecated on August 1, 2026 (UTC).
- Additive over 3.0 at the wire level: no required field was removed and no shape broke, so a 3.0-conformant integration keeps working with no code change.
- A production-hardening release: release-precision version negotiation (supported_versions[]), distributed and cryptographically signed brand trust (self-published brand.json + signed verify_brand_claim), canonical creative formats plus a transformers catalog, and vendor-attested measurement goals.
- Operational guarantees: idempotency_key now required on every task request; dependency-impact / media-buy health signals, buyer-side webhook observability, and reporting finality + reach-window semantics.
- Feature detail is sourced from the official "What’s New in 3.1" and 3.0→3.1 migration docs plus the SDK notes — the GitHub release records only the version and date.
Obligations when you claim 3.1
- Advertise supported_versions in get_adcp_capabilities and echo the served version at the envelope root; transports must tolerate unknown envelope-root fields.
- Brand agents implementing verify_brand_claim(s) must return a signed (JWS) response.
- Move creative metadata to canonical format_kind + list_transformers, and pass the 3.1 compliance storyboard bundle to earn the 3.1 badge.
- Schema tightening can surface as errors: trademarks[].status is now a typed enum and trademarks[].countries must be ISO 3166-1 alpha-2 (former free-text values fail); cache_scope is schema-required on get_products / get_signals.
- The Go SDK (adcp-go) has breaking type changes — plan the upgrade; it is not a drop-in.
Watch next (3.2 / 4.0)
- Scheduled removals: legacy top-level media-buy status → media_buy_status (slated for 3.2); a 4.0 deprecation set (Format.pricing_options, legacy SignalId / flat signal targeting, inline brands[], data_provider_signals).
- Flagged experimental in 3.1, not yet stable: the measurement-vendor catalog (measurement.core) and the responsive_creative / sponsored_placement / agent_placement format kinds.
- A proposed pre-GA rename of body-level status discriminators (e.g. check_governance) was discussed (#4897) but is unconfirmed in the final tag — validate before relying on it.
- AdCP Verified independent auditing, signals-protocol maturity, registry adoption, SDKs, and reference implementations.
Migrating 3.0 → 3.1 — the checklist
A 3.0 integration keeps working untouched — 3.1 is additive at the wire. “Migrating” means claiming 3.1, and each step below is a real obligation (per the 3.0→3.1 migration guide), not optional polish. Backward compatibility is “mostly”: 3.0 clients are not broken, but adoption plus the Go SDK upgrade impose real changes — plan it.
- Advertise versions — Return supported_versions[] from get_adcp_capabilities and echo the served version at the envelope root; make transports tolerate unknown envelope-root fields (this replaces prior reject-on-unknown validation).
- Sign brand verification — If you implement verify_brand_claim(s), return a signed (JWS) response bound to the task, resolved tenant, agent URL, and freshness window.
- Adopt canonical creative — Move creative metadata to the canonical format_kind set and discover build units through the new list_transformers catalog; format-attached pricing moves to the transformer.
- Fix typed fields — trademarks[].status must be a typed enum and trademarks[].countries ISO 3166-1 alpha-2 — former free-text values now error; add the now-required cache_scope on get_products and get_signals.
- Require idempotency — Send idempotency_key on every task request (sellers may reject missing keys); treat IDEMPOTENCY_IN_FLIGHT as transient rather than minting a fresh key.
- Upgrade the SDK, then certify — The Go SDK (adcp-go) has breaking type changes — re-decode against the new shapes; it is not a drop-in. Then pass the 3.1 compliance storyboard bundle to earn the 3.1 badge.
Contributions to the protocol.
This page is written from inside the work: No Fluff Advisory builds and operates a live AdCP signals agent (listed in the AAO registry) with all-pass conformance runs across the AdCP 3.0 and 3.1.0 GA suites, and contributes upstream in the Signals & Measurement working group. For the live state of the registry itself — every registered agent, its actual tool catalog, and real request/response captures — see the AdCP Ecosystem Tracker.
Merged into the protocol & tooling
- last_updated on signal-definition — schema field for verifiable signal-record freshness (#5248 → PR #5249, in the 3.1.0 line since rc.7).
- Compliance-grader fix — all-pass single-protocol runs rendered “Degraded” by a rollup regression; root-caused to the introducing commit, filed (#5429, triaged P0) and fixed (PR #5444, merged).
- RFC 9421 webhook-signing default — the inventory (#4270) and draft PRs (#4273/#4275, closed in favor of the maintainer implementation) that drove the 3.0.9 realignment away from the deprecated HMAC framing.
Conformance suite, hardened
- Signals-only agents now skip non-applicable media-buy gating and gained dedicated error-handling / schema-validation storyboards (#2916, #3350, #4009 — fixed in the 3.1.0 suite; earlier #2535, #3999, #4065).
- Shaped in review — the signal-definition epistemic / provenance layer (#5017, maintainer-authored): contributed the implementer wire-size data (88 KB for 5 signals vs the 64 KB probe ceiling) that drove the progressive-disclosure design, plus field-level schema review.
Open proposals
- Geo cell interoperability — conversion (#6013) and cell-grain delivery reporting (#6014) companions to the geo_cells RFC (#5969), with Nathan Woodman.
- Runtime attestations RFC — verifier-signed signal-quality evidence on check_governance (#5418; issue titled for 3.1, the posted RFC proposes it as a 3.2 candidate).
- revoke_activation revocation primitive (#4203) · Measurement Feedback Signal (#4296).
- RFC 9421 migration coordination (#4205) · JWKS adoption baseline (#4206).
Contribution statuses validated June 2026 against the public AdCP repository; open proposals are point-in-time and may merge, change, or close. Maintainer-authored work is credited as review influence, not authorship.
Protocol domains.
AdCP organizes work into domain-specific tasks and schemas. Task names below are drawn from current official documentation.
-
Media Buy
Inventory discovery, campaign creation, delivery reporting.
get_products · create_media_buy · get_media_buy_delivery -
Creative
Creative format discovery, building, preview, distribution.
build_creative · preview_creative · list_creative_formats -
Signals
Audience and contextual data discovery and activation.
get_signals · activate_signal -
Accounts
Commercial identity, billing, and usage reporting.
list_accounts · sync_accounts · report_usage -
Governance
Brand suitability, approval, policy, audit, content standards.
create_content_standards · calibrate_content -
Brand
Machine-readable brand identity and authorized agents via brand.json.
brand.json discovery -
Sponsored Intelligence
Conversational brand experiences on AI platforms.
Experimental surface in AdCP 3.0 -
Curation
Media inventory curation.
Listed "coming soon" — not a current domain
From brief to governed execution.
- Discover authorized agents — adagents.json, brand.json, registry
- Set up account context — commercial identity, billing, advertiser / operator relationship
- Discover inventory and products — natural-language brief into structured product responses
- Build or sync creative — formats, assets, brand identity, approvals
- Add signals — audiences, suppression, contextual signals, signal activation
- Check governance — budget, brand safety, targeting rules, approvals
- Execute, report, and audit — media buy, delivery, events, audit logs
Discovery starts from two machine-readable files — a publisher's adagents.json (who may sell its inventory) and a brand's brand.json (who may act for the brand, and how):
{
"publisher": "example-publisher.com",
"authorized_agents": [
{
"url": "https://sales-agent.example-ssp.com",
"role": "seller",
"properties": ["news", "sports"]
}
],
"signing_keys": [
{ "kid": "2026-key-1", "alg": "Ed25519" }
]
}{
"brand": "example-brand.com",
"display_name": "Example Brand",
"authorized_agents": [
{ "url": "https://agent.example-buyer.com", "role": "buyer" }
],
"identity": {
"logos": ["/brand/logo.svg"],
"colors": ["#1a1a1a", "var(--accent)"],
"tone": "confident, plain-spoken"
},
"policy": { "restricted_categories": ["gambling", "politics"] }
}Signals: where AdCP meets signal containerization.
The signals layer is where AdCP becomes especially important for agentic advertising. Agents need to discover signals, understand what they mean, check provenance and policy, activate them, and monitor status. That is the same operating problem behind signal containerization — turning audience logic into a governed, executable object.
Discover
What signals exist and what do they mean?
Inspect
Where did the signal come from, how fresh is it, and what policy applies?
Activate
Where can the signal run: seller, platform, identity path, contextual path, or measurement layer?
Monitor
What is the activation status and what outcome did it improve?
An agent discovers signals with a natural-language brief, then activates the chosen signal to a destination — a single get_signals call rather than a taxonomy lookup:
{
"tool": "get_signals",
"arguments": {
"brief": "in-market for premium CTV, US households, privacy-safe",
"deliver_to": { "platform": "dsp", "account": "acct_123" },
"max_results": 10
}
}One open question now sits under this layer. The vectors agents exchange today are text-family embeddings — they encode the words that describe an audience or a brief, and text models famously lose numbers, geography, and time. A second family, spatiotemporal embeddings, encodes the place and hour themselves. A text space and a place-time space do not share a geometry: similarity across the two is undefined until someone defines it — a signals-standards question, exactly the kind of definition a signals working group exists to produce, not an integration ticket.
Governance is the trust layer.
Agentic advertising only works if actions are accountable. A protocol needs to know who called a tool, what authority they had, what was approved, what conditions applied, and what actually ran.
- Human-in-the-loop approvals (a three-party separation of duties)
- Idempotency keys on every mutating request
- Request signing (RFC 9421 HTTP Message Signatures)
- Correlated audit logs
- Governance checks and signed governance tokens
- Brand-safety and content-standard enforcement
- Budget thresholds and authority / role boundaries
The principle
Human judgment is embedded in the system design, not bolted on afterward — the human stays the locus of accountability.
Where AdCP fits with IAB Tech Lab standards.
AdCP is best understood as an agentic management and workflow layer. IAB Tech Lab's AAMP work extends existing standards with agentic foundations, protocols, and trust infrastructure; ARTF focuses on containerized real-time execution; Agentic Audiences on embedding-based signal exchange. These layers can be complementary with clear boundaries. See the IAB Agentic Standards guide. The protocol's sell side already has a shipping open-source implementation — Prebid.org took stewardship of AdCP's sell-side reference code in January 2026, dissected in The Prebid Sales Agent — and landing inside the publisher execution layer documented in Prebid & Header Bidding Infrastructure.
| Initiative | Role | Best question |
|---|---|---|
| AdCP | Agent task / workflow language | What should the agent ask or do? |
| AAMP | IAB Tech Lab umbrella for agentic advertising standards | How do agentic foundations, protocols, and trust fit into existing standards? |
| ARTF | Containerized real-time execution framework | How can service agents run inside host infrastructure with low latency and controlled mutation? |
| Agentic Audiences | Embedding-based signal exchange | How do agents exchange identity, contextual, and reinforcement signals? |
| OpenRTB / AdCOM / Deals API / OpenDirect | Existing transaction and object standards | What underlying objects and transaction models should agentic systems reference? |
Implementation lens by company type.
Pick your company type to see what to expose or consume — and the AdCP domains it touches first.
Authorized agents, inventory products, packages, account setup, governance, reporting.
Partner discovery, product discovery, creative formats, media buy, governance, reporting.
Signal catalog, provenance, activation paths, pricing, policy, status.
Seller agents, deals, signals, governance, a real-time execution bridge, reporting.
Buyer agents, media buys, creative, signal activation, governance, measurement.
Formats, asset generation, preview, brand identity, approval workflow.
Delivery, event logging, attribution, audit, lift, governed outputs.
A protocol defines the task. It does not replace judgment.
The industry should avoid treating AdCP as a magic layer that makes agents safe by default. The protocol can define the task. It cannot replace commercial judgment, governance design, data rights, measurement discipline, or operating ownership.
- Start with one workflow, not every workflow.
- Expose the safest useful task first.
- Design governance before spend movement.
- Treat signals as governed objects, not just segment IDs.
- Build audit and status from day one.
- Connect protocol work to business outcomes, not demos.
Where this fits in the full standards stack.
The layer map
AdCP defines the agent workflow layer. It still needs transaction rails, privacy constraints, measurement trust, and evidence discipline around it.
Building around AdCP or agentic advertising standards?
Use the playbooks to map the workflow, governance, signal model, implementation path, and commercial productization before building against the spec.