30 Oct 2026 · 9 min read
AdCP and OpenRTB: How the Two Fit Together
AdCP and OpenRTB work at different layers of the same buy, so they complement each other rather than compete. AdCP, the Ad Context Protocol, standardises how AI agents discover inventory, create media buys and report on delivery over seconds to days, while OpenRTB, maintained by IAB Tech Lab, standardises the bid request and bid response that settle a single impression in milliseconds. According to the AdCP documentation, a platform "can (and often will) implement both".
TL;DR. AdCP sits at the campaign workflow layer, above the auction, and OpenRTB sits at the impression layer underneath it. The two meet in three places: the deal agreed between agents, the deal ID that carries that deal into OpenRTB bid requests, and the delivery data that flows back to the buyer agent. Neither standard requires the other, and where both run, the work that matters is keeping the terms agreed upstream identical to the terms configured downstream.
What does OpenRTB do?
OpenRTB is IAB Tech Lab's protocol for real-time bidding. A seller's platform sends a bid request describing one impression opportunity, and each buyer's platform answers with a bid or no bid within a tight time limit. The 2.x specification is maintained in IAB Tech Lab's openrtb2.x repository, which notes that from version 2.6-202211 the version number is only incremented on breaking changes, and OpenRTB 3.0 sits in a separate repository.
Deals already exist inside OpenRTB. In the OpenRTB 2.6 specification, the Pmp object is "the private marketplace container for direct deals between buyers and sellers", holding one or more Deal objects, each with a required id, optional buyer seat and advertiser domain allow lists, an auction type and a guar flag for guaranteed deals. When a bid answers a deal, the bid response carries dealid, a reference to the deal.id from the request.
What does AdCP do?
AdCP is an open protocol, published and governed by AgenticAdvertising.org, that defines how AI agents buy media, generate creatives, activate audiences and enforce governance across platforms. It launched on 15 October 2025, as AdExchanger and Digiday reported that day, and the AdCP release notes record version 3.2 as generally available from 30 September 2026, with 3.3 in beta. AdCP tasks travel over MCP or A2A and are asynchronous, so a single operation can take minutes or days.
The core buying sequence is short. A buyer agent calls get_products to see what a seller offers against a brief, create_media_buy to commit budget, targeting and schedule, and get_media_buy_delivery to check how the buy is running. AdCP also serves sellers that never run an auction, such as direct-sold, sponsorship and broadcast businesses, which is covered in Can AdCP buy beyond programmatic?
A concrete example of a layer that sits above both: Alkimi is neutral on standards, so it can work with agents built on AdCP or AAMP, with or without a DSP. Whatever protocol the agents use to agree terms, a programmatic deal still ends up as an identifier that a seller's platform places in OpenRTB bid requests. The agent conversation and the auction therefore have to describe the same deal.
How do AdCP and OpenRTB compare?
OpenRTB | AdCP | |
|---|---|---|
Maintained by | IAB Tech Lab | AgenticAdvertising.org |
Layer | Impression-level transaction | Campaign-level agent workflow |
Core exchange | Bid request and bid response | Tasks such as get_products, create_media_buy and get_media_buy_delivery |
Timing | Milliseconds, synchronous HTTP | Seconds to days, asynchronous |
Participants | DSPs and SSPs | AI agents and advertising platforms, including DSPs and SSPs |
Data model | Impressions, bids and deals | Products, media buys, creative formats, audience signals and governance rules |
Works without the other | Yes | Yes, a seller can implement AdCP with no OpenRTB integration |
The table draws on the AdCP and OpenRTB comparison in the AdCP documentation and the OpenRTB 2.6 specification. The AdCP page frames the split as two questions: OpenRTB asks "Should I bid on this impression, and how much?", while AdCP asks "What inventory is available? Execute this campaign with this budget and targeting." It adds that a single create_media_buy task "might result in thousands of OpenRTB bid requests over the campaign's lifetime."
Where do AdCP and OpenRTB meet?
There are three join points between the standards: the deal, the deal ID and delivery. Each is a place where something agreed in an agent conversation has to show up correctly in the auction, or the reverse.
The deal: agreed through AdCP, fulfilled however the seller chooses
AdCP does not dictate how a seller delivers a media buy. According to the AdCP FAQ, a publisher's AdCP agent might accept a create_media_buy task "then use OpenRTB internally to execute the impression-level delivery", and the comparison page lists OpenRTB auctions, direct insertion orders and private marketplace deals among the routes a seller can use. The FAQ puts the division of labour in one line: "AdCP handles the workflow; OpenRTB handles the auction."
The deal ID: the identifier that carries the agreement into the bid request
Where a seller fulfils through a private marketplace or a guaranteed deal, the agreement has to become an OpenRTB Deal object with an id the buyer's DSP recognises. That object carries only a small slice of the agreement: an identifier, a floor or fixed price signal, an auction type, seat and advertiser allow lists and a guaranteed flag. Flight dates, volumes, creative approvals and make-good terms live in the platforms on each side, which is why the deal ID is the join most worth checking in an agent-negotiated deal.
Delivery: impressions in OpenRTB, campaign view in AdCP
OpenRTB records what happens impression by impression, through bids, win notices and billing events. AdCP rolls that up for the agent, which calls get_media_buy_delivery to monitor overall performance against what was agreed. For real-time decisions that need data from several publishers, such as cross-publisher frequency caps, AdCP 3.2 documents the Trusted Match Protocol, which brings AdCP to impression-time decisions "without turning AdCP itself into an auction protocol".
Why are AdCP and OpenRTB complementary rather than competing?
The two standards answer different questions on different clocks. At launch, a spokesperson for the AdCP consortium told Digiday that AdCP "is a parallel protocol to OpenRTB" and that "Publishers and platforms can run both OpenRTB and AdCP simultaneously".
AdCP also reuses OpenRTB vocabulary where it already works. The AdCP FAQ lists OpenRTB and AdCOM placement classifications and OpenRTB Native creative assets among the IAB Tech Lab standards it maps, while defining its own task model "rather than adopting OpenRTB's auction wire protocol". The get_products reference, for example, declares video placement types using the OpenRTB 2.6 video.plcmt definitions.
The practical result is that adopting AdCP does not mean replacing an OpenRTB stack. A seller can put an AdCP agent in front of the systems it already runs and keep OpenRTB for delivery, and a buyer can let an agent handle discovery and setup while the auction carries on as before.
Where does AAMP fit alongside AdCP and OpenRTB?
IAB Tech Lab, which maintains OpenRTB, leads its own agentic programme, AAMP (Agentic Advertising Management Protocols). Its Agentic Real Time Framework (ARTF) reference implementation describes a specification "for agent-driven containers in OpenRTB", with functions that include activating, suppressing and adjusting deals. The AdCP FAQ describes AAMP as a separate initiative with "some overlapping workflow concepts", and the deal-level comparison with the auction is covered in How does AAMP compare to OpenRTB?
What should teams check when AdCP and OpenRTB run together?
A short checklist for the join between an agent-agreed buy and the auction:
The deal ID created for the buy carries the buyer seats, advertiser domains and guaranteed setting that the agents agreed.
The auction type on the
Dealobject reflects whether the agents agreed a fixed price or a floor.Flight dates, volumes and creative approvals agreed through AdCP are configured in the seller's platform, since OpenRTB does not carry them.
Delivery reported through
get_media_buy_deliveryreconciles with the DSP's own impression and win records.A named person approves any deal above an agreed size before it goes live.
Where do people stay in charge?
Agents suit the repetitive parts of media buying that few people enjoy: answering briefs, assembling packages, setting up deal IDs and chasing delivery numbers. People keep the judgement and approve the deals that matter. At the AdCP launch, Scope3's Anne Coghlan told AdExchanger "Where we are right now, there is always a human in the loop."
The protocol allows for that. The create_media_buy reference notes that when a guaranteed buy goes to a seller requiring insertion order approval, "the human-approval handshake cannot complete inside the response", so the result arrives later. A sensible way to stage autonomy is earned autonomy: agents move from observe, to recommend, to draft, to human-approved action and only then to bounded automatic action, one deal type at a time.
Frequently asked questions
Does AdCP replace OpenRTB?
No. The AdCP documentation describes the two as complementary standards at different layers, and a platform can implement both.
Do you need OpenRTB to use AdCP?
No. According to the AdCP documentation, a direct-sold publisher, broadcast seller or commerce media network can implement AdCP without any OpenRTB integration.
Can an AdCP media buy run through OpenRTB?
Yes. The seller can fulfil an AdCP media buy through OpenRTB auctions, private marketplace deals, insertion orders or other internal routes.
Where do deal IDs fit between the two?
Deal IDs live in OpenRTB's Pmp and Deal objects, and a bid on a deal returns the dealid. When agents agree a programmatic deal through AdCP, that agreement still has to be set up as a deal ID the buyer's DSP recognises.
Is AgenticAdvertising.org part of IAB Tech Lab?
No. The AdCP documentation describes AgenticAdvertising.org as an independent organisation, and states that AdCP is designed to be compatible with IAB standards.
Where does a standard-neutral approach fit?
Alkimi is neutral on standards: it can work with agents built on AdCP or AAMP, with or without a DSP. Concourse benchmarks any buying agent without asking which standard it uses, and in Concourse Bench v1, 95 of 110 signed contracts promised a viewability floor below 70%, the kind of term that is easy to lose between an agent's agreement and a deal ID. The Gym lets buyers and sellers build their own agents, set the rules they work to and spar against counterparty agents before real money moves, while the neutral Marketplace records each agreed deal in a DealSheet held by both sides, with people keeping approval rights at the deal level.