rtblintAlpha

Guides

The Ad Context Protocol (AdCP), explained

The Ad Context Protocol is the industry's most visible attempt at agent-to-agent media trading, and it is backed by a different coalition than IAB Tech Lab. This is what it actually is: who governs it, how the pieces fit, and where a negotiated AdCP buy ends up touching OpenRTB. For the IAB alternative, see the AAMP explainer.

Who is behind it

AdCP launched on October 15, 2025 with six founding members: Yahoo, Optable, PubMatic, Scope3, Swivel, and Triton Digital, alongside a longer list of launch partners including Magnite, Raptive, and The Weather Company. It is governed by AgenticAdvertising.org (AAO), a trade organization formed in 2025 specifically to steward the protocol. That governance split matters: AAO owns the specification, and the reference sell-side software moved to Prebid.org in January 2026 as the Prebid Sales Agent, so Prebid maintains the code while AAO keeps the protocol. The spec sits on a 3.0 release line under an Apache 2.0 license.

How it is built

AdCP is built on Anthropic's Model Context Protocol (MCP), the same protocol many AI agents already speak, with Agent2Agent (A2A) as a second transport. On top of that it defines tasks for the major jobs in a media buy:

  • Media buying: an agent discovers inventory and negotiates terms with a seller's agent.
  • Creative: handling and describing the assets to be served.
  • Signals: the contextual and measurement inputs a buyer reasons over.
  • Audience activation: turning an audience definition into something a seller can act on.

The protocol splits into two layers, and the distinction is the key to understanding it:

  • A negotiation layer, where agents discover inventory and agree on terms at planning time. This is where most of AdCP's activity happens, and it is well above the real-time auction.
  • Trusted Match, a serve-time layer for impression-level decisions, the part that has to line up with what happens inside the auction.

adagents.json: the trust artifact to watch

The one genuinely new file AdCP introduces to the public web is adagents.json, served at /.well-known/adagents.json. It is a publisher's declaration of which sales agents may represent its inventory, with scoped authorization that goes well beyond ads.txt: placement IDs, country restrictions, date windows, and signing keys. It sits naturally beside ads.txt, sellers.json, and schain, and buyers will eventually reconcile all four to decide whether an agent-sourced deal is legitimate.

Where AdCP meets OpenRTB

AdCP mostly lives above the bid stream. A media buy is negotiated between agents over MCP or A2A, and what comes out the other end executes through the pipes that already exist: a deal ID in imp.pmp.deals, a programmatic guaranteed line, or a direct tag. If your job is parsing OpenRTB, AdCP demand arrives looking like any other deal. Nothing new appears in the bid request; the novelty is entirely upstream in how the deal was struck. That is the opposite design choice from IAB's ARTF, which puts agents inside the auction path. The practical consequence is covered in agentic buying and OpenRTB: whatever the agents agree, it still has to come out as a valid bid request.

What to do now

  • Treat AdCP demand as deals. It shows up in imp.pmp.deals and PG lines, so no parser change is required today.
  • If you already publish or consume ads.txt and sellers.json, start tracking adagents.json; it is where agentic authorization is accumulating.
  • If you are building an AdCP agent, wire OpenRTB validation in as a tool so the deal you negotiate resolves to a valid bid request. Start with the tester, then automate with the CLI.

Sources

rtblint is independent and not affiliated with AgenticAdvertising.org or IAB Tech Lab. Membership and structure below are drawn from AAO and partner announcements; the analysis is our own.