RTBlintAlpha

Blog · Agentic

The agentic protocols shipped a version handshake. A bid request still has nowhere to say which OpenRTB it is.

· RTBlint

The agentic layer spent the last ten days doing something the bid stream has never done: arguing about versions in public, on the wire, at request time. AdCP 3.1 requires a version on every message and returns a typed error when the two sides disagree. AAMP 2.3 put trust verification on the paths that move price. Meanwhile OpenRTB is ten dated snapshots into 2.6 and still has no field anywhere in a bid request that says which of them the payload conforms to. That asymmetry stops being academic the moment an agent sits between the publisher and the bidder.

What actually shipped

AAMP 2.3 went out July 30. The headline items are operational rather than protocol surface: the IAB Diligence Platform and SafeGuard Privacy embedded as approval gates inside the Buyer Agent, deterministic negotiation guardrails, server-side trust verification on price-moving paths, deployment targets on Amazon Bedrock AgentCore and Databricks, and Agentic Audiences v1.0 declared ready for transactions. The Agentic RTB Framework, the piece that actually touches the auction, continues under the Agentic Task Force rather than landing finished in this release.

AdCP has been shipping continuously through the same window. 3.1 is additive over 3.0 and the patch line has not stopped: v3.1.9 on August 3, v3.1.10 on August 4, v3.1.11 on August 7, v3.1.12 on August 8. The release notes describe 3.1 as production-hardening for real agent operations, which is a polite way of saying the gaps were found by running buys against real publishers.

And the sell side opened the auction itself. In the first week of August, Magnite described two routes for partner AI models to operate inside its SSP auction, PubMatic shipped guardrails that block agents from buying unapproved inventory, and Prebid.js landed a DevTools MCP module that lets an agent read live auction data. Three different answers to the same question, which is where a model gets to sit relative to the request.

The handshake AdCP 3.1 built

Read the 3.1 wire rules next to OpenRTB and the contrast is hard to miss. Four mechanisms, none of which have an equivalent in the bid stream:

MechanismWhat it doesOpenRTB equivalent
adcp_version on every request and responseBuyer states the release it wrote against; seller echoes the release it actually served, at release precision, so "3.1" is on the wire and "3.1.2" is not.None. A bid request carries no version field at all.
supported_versions on capabilitiesDiscovery: a caller can ask what a counterparty speaks before speaking it.An onboarding PDF and a shared assumption.
Typed VERSION_UNSUPPORTEDA mismatch produces a specific error with structured data naming the versions that would work.A field the receiver does not recognise, dropped without a signal. See what happens on a mismatch.
idempotency_key required on every task requestReads and writes alike, with staged enforcement: 3.1 sellers should reject reads that omit it, 3.2 will mandate rejection.BidRequest.id, which is a correlation id, not a replay guard.

There is a fifth item worth reading if you implement an AdCP surface, because it inverts a habit: 3.1 flattened the MCP envelope so envelope and body fields are siblings at the root, and it requires servers to tolerate envelope fields they do not know. Strict validation is explicitly non-conformant. The release notes name the offenders directly: FastMCP strict modes, Pydantic .strict(), OpenAPI codegen that emits additionalProperties: false. If you generated a client from a schema and turned strictness on because that is what careful people do, you built a non-conformant client.

Why OpenRTB never needed one, and why that changed

The bid stream got away without version negotiation for a good reason: the population of counterparties was small, the integrations were bilateral, and both sides had a human relationship before they had traffic. You agreed on 2.5 in a kickoff call, you built to it, and a mismatch surfaced as a support thread. The protocol did not need to carry the answer because the answer lived in a contract.

Dated snapshots broke the last part of that. There are ten dated 2.6 releases now, and 2.6-202204, 2.6-202501, 2.6-202505 and 2.6-202606 are all correctly described as "OpenRTB 2.6" while carrying different field sets. Two systems can agree on the version in writing, both be telling the truth, and still disagree about whether a field exists. We wrote about the mechanics in how OpenRTB ships now and the June snapshot specifically in the 202606 field-by-field.

Now add an agent. ARTF has agents mutating a live payload in the auction path with a typed intent, an operation and a path, which we walked through in the mutations post. The mutation vocabulary is precise. The thing it is mutating is a document whose version was agreed somewhere the agent cannot read. An agent that adds a field introduced in the June snapshot to a request destined for a bidder pinned to the January one has produced a payload that is valid against a spec and unparseable by its recipient, and nothing in the exchange between them will say so.

The failure is quiet by design. Unknown fields are ignored, that is the extensibility contract, and it is the right contract for a protocol that has to evolve without flag days. It is a bad contract for a system where the writer is a model that will happily produce a plausible field name and receive no feedback that it invented one.

What a pinned snapshot looks like in practice

You cannot add a version field to OpenRTB from your side of an integration, but you can stop treating the version as tribal knowledge. Three things, in order of how much they buy you:

  • Pin a snapshot per counterparty, in configuration. Not in a wiki, not in the head of the person who ran the integration. If your validator can be pointed at a version, the pin becomes an artifact you can diff when a partner upgrades.
  • Validate at every boundary that can rewrite the payload. Publisher emit, wrapper exit, agent mutation, exchange forward. Each of those is a place where a field can appear that the next hop does not know, and the cost of finding out later is a spend line nobody can explain.
  • Log what you dropped. A receiver that silently ignores unknown fields is conformant. A receiver that ignores them and counts them is conformant and debuggable, and the count is the closest thing to a version mismatch alarm that OpenRTB permits today.

For agents specifically, the useful move is to give the model the check rather than the documentation. An agent with a validator available as a tool can verify its own mutation against the snapshot the host actually runs, before the response goes back. That is one call to the MCP server, or the CLI in the same container, or the tester when a human is debugging what an agent produced.

The part worth borrowing

None of this is an argument that AdCP is the better protocol or that OpenRTB should adopt its release cadence. They solve different problems and the bid stream's constraints, single-digit millisecond budgets and enormous fan-out, are exactly the constraints that make a negotiation round trip expensive.

But the design decision underneath the AdCP handshake transfers cleanly, and it costs nothing at runtime: make the version an explicit, machine-readable part of the exchange rather than an assumption held by both parties. Even one field on the envelope, stating the snapshot the sender built against, would convert a class of silent field-dropping into a loud error at integration time. Until something like that exists, the pin lives in your config and the check lives in your pipeline, and the only alternative is finding out from a revenue report. Field-level context on the standards around this is in IAB Tech Lab's agentic standards and the AdCP to OpenRTB mapping.

Sources