AdCP v2 Dies August 1: Is Your adagents.json Ready for v3?

On August 1, 2026, AdCP schema v2 is deprecated. adagents.json is to agents what ads.txt once was to ad exchanges — break the file and you silently vanish from discovery. We migrated to v3.1.4 ten days ahead of the cutoff. Technical details, traps, and a checklist for anyone running their own discovery file.

On August 1, 2026 (UTC), schema v2 of the Ad Context Protocol (AdCP) is fully deprecated. Any /.well-known/adagents.json — the discovery file a buyer agent reads to learn which MCP or REST endpoints a domain has authorized for agentic commerce — that still points at /schemas/v2/ will be rejected as invalid by any v3-validating agent from that date on. adagents.json is to agents what ads.txt once was to ad exchanges: a machine-readable, domain-hosted authorization list. Nobody runs a central registry that checks this for you — every buyer agent validates against the current schema itself. If your file breaks on the cutoff date, you disappear from discovery for every schema-strict agent, with no error message, no bounce, no retry. Nexbid migrated on July 21 — ten days ahead of the cutoff. The rest of this post is the technical walkthrough so you don't have to re-derive it. Why v3 Is Not a URL Swap The naive move is to change $schema from.../schemas/v2/adagents.json to.../schemas/v3/adagents.json and call it done. That doesn't validate. v3 introduces two structural required fields that v2 never had: properties — a non-empty array describing every property (domain, app, etc.) you're authorizing agents for. Each property needs a property_id, a property_type, a name, and at least one identifier (in our case: type: domain, value: nexbid.dev ). authorization_type per agent inside authorized_agents — a discriminator that states what the authorization applies to. In our case, property_ids, referencing the property defined above. Without the properties array, a v3 file fails validation — even if $schema, url, and authorized_for are otherwise correct and unchanged. The Version Trap: v3 Is Not /v3/ The second trap: there is no floating /v3/ URL to pin against. We pinned to release-precise 3.1.4, not a floating major version. Reason: 3.1.3 was withdrawn by the protocol maintainer because it introduced a new required field (a stable, referenceable schema field) in a patch release — a semver-hygiene break that was subsequently reverted. Anyone floating on /v3/ or /3.1/ at the moment of withdrawal would have had a different schema version under their feet overnight, with no commit, no review. Takeaway: for an evolving external schema standard, pin release-precise, don't trust major or minor floats. The cost is a manual update per patch release; the payoff is reproducibility. Verification Before Merge Before shipping, we validated the new file against the real v3.1.4 schema graph — with remote $ref resolution (the …

Author

Nexbid Engineering

Published

2026-07-28

Topics

Protocol Commerce, Agent Discovery, Open Source, Verification