AAMP Explained: How a Video Buy Becomes OpenRTB and VAST on the Wire

On 23 October 2026, IAB Tech Lab extended public comment on AAMP 3.0 and its OpenProposal object to 10 November 2026.

Commenters are not debating whether agents will buy video. They are filing field-level feedback on how a closed proposal is supposed to land on execution rails that already exist: OpenDirect, the Deals API, and OpenRTB 2.6 for auction paths, with VAST still carrying the creative after many of those paths clear.

If you operate bid streams or ad servers, that split is the job. The buyer agent can return success in the AAMP layer while nothing on the wire changed.

The explainer below walks the hop in order: what the agent negotiates, which rail transaction_mechanism selects, what must appear on imp.video, and where VAST re-enters the story.

What the buyer agent actually closes

AAMP 3.0 centers on OpenProposal: a machine-readable description of what is being bought, built so a buyer agent can score it against a brief without a spreadsheet.

For video, a line item names a channel (video, CTV, and related values in the draft), optional formats such as produced :30 or a host-read upgrade, commercial terms, and a transaction_mechanism that tells the integration which downstream standard owns fulfillment.

The draft is explicit that OpenProposal does not replace execution specs. Each line item "lands in the one its transaction_mechanism maps to."

That sentence is the whole architecture for practitioners: negotiation is upstream; fulfillment is still OpenDirect, a deal sync container, an OpenRTB auction, or a direct ad-server handoff that returns XML.

A worked video line in comment threads often includes duration bounds, a deal or package reference, and sometimes a VAST endpoint for guaranteed delivery. Those fields live in the proposal object. They are not automatically copied into the next hop. Your forwarder, SSP adapter, or seller agent still has to translate them.

How transaction_mechanism picks the execution rail

Think of transaction_mechanism as the router between planning and plumbing.

When it points at OpenRTB 2.6, the seller or exchange integration must emit a bid request whose imp objects reflect the committed line: private marketplace flags, deal ids, duration windows, and AdCOM video semantics where the partner runs 2.6.

When it points at the Deals API or OpenDirect 2.1, the first object may be a deal record or order line, but programmatic video often still fans out into RTB for delivery or into an ad server that answers with a VAST URL.

Early November industry coverage noted buyer agents already reaching new supply through existing SSP pipes once inventory is exposed programmatically. The mechanism field is what is supposed to keep those agent successes from skipping the object the exchange already parses.

If the mechanism says OpenRTB and the integration only updates an internal deals library, the auction never sees the buy. The agentic buying stack map on rtblint labels these layers. AAMP sits above OpenRTB; it does not delete the bid stream.

What has to exist on imp.video in OpenRTB

Once the path is OpenRTB, the exchange reads JSON, not the proposal PDF. For video that means imp.video and, when the buy was private, imp.pmp.

• Duration and formats. A line that committed to a fifteen-second CTV pod needs minduration and maxduration that match, plus mimes and protocols the creative will use. A default template left over from before the agent existed is a common failure mode: the proposal says :15, the forwarder still sends maxduration: 120.
• Placement. OpenRTB 2.6 expects AdCOM placement via plcmt. An agent that "knows" in-stream video can still forward a value that means accompanying content if the mapping from the proposal never ran. Buyers filter on plcmt; the line never enters the auction they thought they purchased.
• Deals. Programmatic guaranteed and PMP lines need pmp.deals with the id the seller committed to. Missing pmp entirely turns a closed private buy into open market traffic.

One illustrative fragment after a bad forward (the problem is the absence of deal and duration discipline, not the example id):

{ "imp" : [{ "id" : "1" , "video" : { "mimes" : [ "video/mp4" ], "maxduration" : 120 , "protocols" : [ 2 , 3 , 5 , 6 ] } }] }

There is no pmp. Nothing in the JSON admits a fifteen-second PG line on deal PG-8842, even if the AAMP task status is complete.

Run that object through rtblint against the dated OpenRTB snapshot your partner enforces before you treat the agent output as shippable.

After clearance: VAST as the delivery contract

Winning the auction or clearing guaranteed delivery is still not playout. Programmatic video typically ends with VAST inside bid.adm, a redirect the player follows, or a tag URL your ad server returns to SSAI. That XML is a third contract.

<Duration> must fit the break. MediaFile URLs must be HTTPS when the imp required secure: 1. SSAI paths may require a mezzanine the OpenRTB layer never mentioned. Wrapper chains can hide the InLine where the actual MP4 lives.

The proposal's formats and specs fields point at format registry entries in the draft. Public comment has highlighted gaps for some channels; even when the registry is thin, the VAST on the wire must still be servable in the environment that was bought.

How you catch it

Split checks the way the stack splits objects.

Bid hop: Use rtblint (cargo install rtblint, npm install rtblint-core, MCP rtblint-mcp) on the forwarded OpenRTB request. Diff imp.pmp.deals, duration bounds, and AdCOM video fields against the proposal line the AAMP task recorded. An LLM implementing the forwarder can emit plausible JSON and still get an OK from a stub.

Creative hop: Paste the live tag URL or adm XML into the VAST tag tester for fetch, preview, and tracking URLs. Walk wrapper hops in the VAST inspector before you mark the flight live. vastlint (cargo install vastlint, npm install vastlint) owns that envelope.

An implementation that lets a model emit OpenRTB or VAST still has to verify the bytes the exchange and player will see. These packages are that deterministic check. They are independent of IAB Tech Lab and of AAO; the specs do not require them.

Wire both into the agent loop where you can: validate the bid request before forward, validate the tag before delivery. The agentic integration notes on vastlint show MCP placement alongside creative checks.

Where to go next

• Why agentic buying still needs a harness for the gap between agent success and wire payloads.
• IAB VAST validator guide when you need version-aware rules on the creative leg.
• Validate VAST XML for CLI and CI on the tag that follows the win.
• Agentic buying and OpenRTB for the full execution map under AAMP.

Comment on OpenProposal before 10 November 2026 if your video forwarder maps transaction_mechanism differently than your exchange expects. The execution rails are not waiting for ratification.