AAMP 影片交易與 OpenRTB 出價請求：SDK 完成交易，不代表交易所讀得到交易條款

Public comment on AAMP 3.0 and OpenProposal closes October 22, 2026. The draft standardizes how seller agents describe products and how buyer agents score them against a brief. Execution did not wait for the comment period to end. AAMP 2.x buyer and seller SDKs already transact programmatic guaranteed, preferred deals, PMP lines, and open marketplace video over the same rails you operate today.

The planning object and the auction object are not the same contract. An agent can record a successful video buy in the Deals Library while the OpenRTB bid request on the wire still looks like a generic open-market imp. Both sides can pass JSON Schema. The exchange still has no deal to match, or it matches the wrong shape.

What the AAMP side treats as done

IAB Tech Lab's Agentic Advertising Management Protocols (AAMP) extend OpenDirect, the Deals API, AdCOM, OpenRTB, and VAST under agent interfaces. For programmatic video, the buyer agent SDK negotiates terms, writes the outcome to Agentic Deals, and may hand off to Agentic RTB or your existing bidder integration.

Success in that layer means the seller agent accepted the line, trust checks on price-moving paths cleared (AAMP 2.3), and the task status returned to your orchestrator. The artifact names a format, a budget band, often a deal identifier, and sometimes a VAST endpoint for guaranteed delivery. None of that is guaranteed to be copied into the next OpenRTB forward unchanged.

OpenProposal, the AAMP 3.0 object in public comment, adds structured RFP-to-proposal matching on AdCOM-shaped fields. We already covered the gap where OpenProposal ranks briefs but OpenRTB has no proposal handle. This post is the sibling problem on the execution hop: even when you skip OpenProposal and close a deal through Agentic Deals alone, the bid request template your forwarder uses may never have read the deal terms.

What the exchange actually reads

The exchange, SSP, or in-app mediation stack still parses OpenRTB. For video it reads imp.video: minduration, maxduration, protocols, plcmt or legacy placement fields, skip, podid, and the PMP container when the buy was private.

Suppose the agentic buy committed a fifteen-second CTV pod on deal PG-8842. The forwarder emits:

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

There is no pmp.deals entry. maxduration still reflects a default template from before the agent existed. A DSP bidding sixty-second creative into that imp is doing what the JSON allows, not what the human-readable deal memo says.

AdCOM made the placement story stricter. OpenRTB 2.6 expects plcmt with AdCOM semantics, not a copied 2.5 placement integer. An agent that "knows" the buy was in-stream can still forward plcmt: 4 (accompanying content) because the integration never mapped Agentic Deals fields into imp.video. Buyers filter on plcmt. Your line never enters the auction they thought they bought.

When the path wins, many stacks still deliver VAST inside bid.adm or fetch a tag URL from the ad server. That is a third object again: XML with <Duration>, <MediaFiles>, and on SSAI paths often a mezzanine the OpenRTB layer never mentioned.

Same flight, two verdicts

The agentic buying and OpenRTB guide walks the stack map. The will agents replace OpenRTB post states the invariant: negotiation moved up; the bid stream did not go away.

When the win still has to become VAST

Programmatic video that clears through RTB often ends with VAST in the response or a redirect the player follows. Guaranteed and preferred paths may skip the open auction but still serve through an ad server that returns XML.

A buy that specified HTTPS-only media can win an imp with secure: 1 while the adm carries http:// in a MediaFile. A buy that excluded interactive delivery can still win VPAID in the creative because nobody opened the tag after the auction. SSAI paths add mezzanine and codec expectations the OpenRTB object never carried; the SSAI readiness notes are about that environment, not about Agentic Deals JSON.

Publishers auditing advertiser tags hit the same wall from the other direction: the checklist for reviewing a partner VAST tag assumes you fetch and walk the chain, not that an upstream agent did it for you.

How you catch it

Split validation the way the stack splits objects.

OpenRTB hop: Run the forwarded request through rtblint (cargo install rtblint, npm install rtblint-core, MCP rtblint-mcp) against the dated snapshot your exchange partner enforces. Diff imp.pmp.deals, duration bounds, and AdCOM video enums against the deal record the AAMP task wrote. An LLM implementing the forwarder can emit plausible JSON and still get an OK from a stub validator.

Creative hop: Paste the live tag URL or adm XML into the VAST tag tester for fetch, preview, and tracking URLs. Run the same URL through the VAST inspector to resolve wrapper hops through to the InLine. vastlint (cargo install vastlint, npm install vastlint, MCP on vastlint.org) owns that envelope.

These packages are deterministic checks on the wire payloads. They are independent of IAB Tech Lab and of AAO; the specs do not require them. Agentic tooling that lets a model emit OpenRTB or VAST still needs something that reads the bytes the player and exchange will see.

Wire both into the agent loop where possible: validate the bid request before forward, validate the tag before you mark the flight live. The agentic integration guide shows MCP placement for AAMP buyer agents alongside the creative check.

Where to go next

• Will agents replace OpenRTB? for why the bid stream stays the execution layer under AAMP.
• Publisher checks on an advertiser VAST tag when the agent handoff lands on your ad ops queue.
• VPAID on CTV paths when the win carries deprecated interactive flags.
• Wrapper clickthrough rules when the adm is hop one of a chain, not the creative.

AAMP 3.0 may add explicit bridges from OpenProposal into execution in a later revision. Production traffic already splits planning success from auction shape. Treat the forwarded bid request and the fetched tag as separate contracts and validate them that way.