Guides

Agentic buying and OpenRTB: how AI ad agents meet the bid stream

"Agentic advertising" is the year's loudest phrase, and most explainers stop at the announcements. This one answers the question a bid-stream engineer actually has: when an AI agent buys media, what reaches the bidder, and how do you check it? The short version is that agents mostly negotiate above OpenRTB, and what they agree on still executes as an ordinary bid request. For a point-in-time take on the standards politics, see the news analysis; this is the durable how-it-fits.

What "agentic buying" actually means

In the traditional flow, a human sets up a campaign in a DSP UI and the DSP bids into exchanges over OpenRTB. In the agentic flow, software agents do the negotiating: a buyer's agent describes an objective in natural language and structured constraints, a seller's agent offers inventory and terms, and the two settle a deal by talking to each other over an agent protocol. The transport underneath is usually Anthropic's Model Context Protocol (MCP) or Agent2Agent (A2A). The important part for OpenRTB: this conversation happens at planning and negotiation time, not inside the microsecond auction.

Two stacks, two theories of where agents belong

There are two competing efforts, and they disagree about where an agent sits relative to the auction.

Ad Context Protocol (AdCP), launched October 2025 and governed by AgenticAdvertising.org (AAO). Built on MCP with A2A as a second transport, it defines tasks for media buying, creative, signals, and audience activation. It is split into a negotiation layer (agents discovering inventory and agreeing terms at planning time) and a serve-time layer called Trusted Match. The reference sell-side implementation lives at Prebid.org as the Prebid Sales Agent.
Agentic Advertising Management Protocols (AAMP) from IAB Tech Lab, v1.0 in January 2026. Its stated approach is to extend OpenRTB, AdCOM, VAST, and GPP rather than introduce new standards. Under its umbrella, the Agentic RTB Framework (ARTF) takes the opposite bet from AdCP: it puts agent services inside the auction path, co-located with an exchange or DSP, enriching and modifying bid requests mid-flight over gRPC.

So one camp keeps agents above the bid stream and lets the deal execute through existing pipes; the other wants agents rewriting the request as it flows. That distinction is the whole story for anyone who validates OpenRTB.

Where each one touches the bid request

Above the stream (AdCP). An AdCP media buy is negotiated between agents, 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, agentic demand arrives looking like any other deal. Nothing new appears in the JSON; the novelty is upstream, in how the deal was struck.

Inside the auction (ARTF). Here the request that reaches a bidder may have been enriched or rewritten by a third-party container between the publisher and the auction. The fields still have to be valid OpenRTB, but their provenance becomes a live question: which agent touched imp, device, or the supply chain, and how is that audited. Validation stops being a one-time gate at the edge and becomes something you want after each stage that can mutate the request.

Either way, the invariant holds: whatever the agents agree, the transaction still has to come out as a valid bid request on the wire. Agents changed who decides; they did not replace the protocol the decision executes on.

The trust stack agents are adding to

Agentic buying introduces one genuinely new artifact worth tracking now: 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 (placement IDs, country restrictions, date windows, signing keys) that goes well beyond what ads.txt can express. It does not replace anything; it joins the stack a careful buyer already reconciles:

ads.txt / app-ads.txt   which sellers may sell this inventory
sellers.json            who each seller ID actually is
source.schain           the hop-by-hop path of this specific request
adagents.json           which agents may represent this inventory (new)

The first three are pure OpenRTB-adjacent supply-chain checks rtblint already covers through schain validation. adagents.json is the agentic addition, and buyers will eventually want to verify all four line up.

Why validation matters more, not less

When a human built a campaign, a mistake in the request was a human error you could trace to a config screen. When an agent assembles or rewrites the request, the output is generated, and generated OpenRTB drifts in the same ways any generated JSON does: a plausible-looking field in the wrong path, a consent string left in ext, an enum value that used to be valid. None of it throws; it just costs bids or breaks compliance. An agent that can construct a bid request should be able to check it against the spec before it ships one, the same way a developer runs a linter.

rtblint is built for exactly that. The validator runs client-side in the tester and as a CLI for pipelines, and it also runs as an MCP server at rtblint.org/mcp. Because it speaks MCP, the same protocol AdCP and many agent frameworks are built on, an AI buying or selling agent can call it as a tool and validate its own OpenRTB output inline. The server exposes three tools:

validate_bid_request: pass a bid request payload (and an optional OpenRTB version) and get back the issues, with rule IDs and JSON paths.
validate_bid_response: the same for a bid response.
list_openrtb_versions: the versions the validator supports, so an agent can pin the snapshot it validates against.

An agent negotiating an AdCP deal can confirm the resulting bid request is valid before it enters the auction; an ARTF-style host can revalidate after a container rewrites a request. Same spec, same rule IDs, whether a human or an agent is holding the JSON.

What to do now

Treat agentic demand as deals. If you parse OpenRTB, AdCP inventory shows up in imp.pmp.deals and PG lines; no parser change is required today.
Start watching adagents.json if you already reconcile ads.txt and sellers.json. It is where agentic authorization is accumulating.
If any stage in your path can rewrite a request (an ARTF-style agent, an enrichment service), validate after it, not just at the edge.
If you are building an agent, wire OpenRTB validation in as a tool so it checks its own output. Start with the tester to see the issue shape, then the CLI or the MCP endpoint for automation.

Whichever agentic stack wins, the transactions still resolve to OpenRTB on the wire. The protocol is the stable layer under all the agent news, which is exactly why it is worth validating.