Skip to main content
Interchange does not own your identity. You publish it — at your own domain, signed with your own keys, on your own clock — and we read it. The Agentic Advertising Organization (AAO) registry fills the gap until you’ve published, and computes a few things you don’t publish yourself. That’s the whole model: owners publish; the registry is a fallback and a compute layer; we read and trust what’s there. This page is the canonical answer to “what are all these documents, and which ones actually stop me from selling?” The short version: authorization blocks; compliance informs.

​
The three documents (and the one that isn’t)

Three identity documents matter, each owned and published by a different party, plus one legacy bridge. The AAO registry is not one of them — see below.
DocumentWho owns itWhere it livesWhat it answers
adagents.jsonThe publisherhttps://<publisher>/.well-known/adagents.jsonTwo things: which agents are authorized to sell my inventory (and over which properties), and what inventory I have — my collections, placements, and creative formats
brand.jsonThe brand / operatorhttps://<operator>/.well-known/brand.jsonWhich agents I own and run (by role), where their signing keys live, and my corporate hierarchy (house / parent brand)
Agent card (get_adcp_capabilities)The agent itselfthe agent’s own endpointWhat the agent claims it can do — the AdCP capabilities it supports
The ads.txt managerdomain entry is a legacy one-hop bridge: a network-managed publisher that hosts no adagents.json of its own (for example, a Raptive/CafeMedia-managed domain) delegates to its manager’s file. Resolution handles this automatically — see Discover agents.

​
The AAO registry is not a document

The registry is a source and compute layer over those documents, not a document anyone owns. It does three things:
  1. Computes compliance. It grades an agent’s self-declared capabilities against AAO test storyboards and publishes a verdict (passing, pending, degraded, or failing). The agent doesn’t publish this — the registry computes it.
  2. Hosts a community mirror of a publisher’s adagents.json so an unpublished publisher is still discoverable. A community mirror lists no authorized agents — it exists to be found, never to authorize. An empty mirror is not a denial.
  3. Carries discovery metadata (discovery_method, hosting.mode) describing whether a record is owner-published or a community fallback.
A self-published document always supersedes the community fallback, and the registry resolves that internally. We trust whatever the registry returns.

​
Blocks vs. informs

This is the distinction that matters, and the one most worth getting right: an agent being AAO-compliant (“did it pass the test suite?”) is a different question from an agent being authorized to sell a publisher’s inventory (“does that publisher’s adagents.json list it?”). Different owners, different documents, different consequences. Two things block. Everything else informs.

Authorization — blocks

A sales agent must be registered with AAO to be connected as an inventory source. And to actually traffic a publisher’s inventory, that publisher’s adagents.json must authorize the agent for those properties. Authorization is enforced.

AAO compliance — informs

The registry’s compliance verdict (passing, pending, degraded, or failing) is advisory. A non-passing verdict is surfaced as a prominent warning, but it does not block your storefront from going live and transacting. You can sell while compliance is still pending.
Concretely, across the storefront lifecycle:
MomentWhat’s checkedBlocks?
Connect a sourcethe agent is registered with AAOYes — an unregistered agent can’t be connected (a registry that’s unreachable is a “try again,” not a “no”)
Go liveAAO compliance verdictNo — informational. A non-passing verdict shows as a warning; it never holds back go-live
Traffic a media buythe publisher’s adagents.json authorizes this agent for the inventoryYes — authorization is enforced per publisher, per property, at traffic time
So if you hear “your AAO compliance is pending,” that is not “you can’t go live.” It’s an advisory you can act on (or ignore) on your own schedule. The only hard authorization gates are agent registration (to connect) and publisher authorization (to traffic).

​
Why we ask for AAO, and what we do with it

We read the registry to (1) confirm an agent you connect is a real, registered participant, (2) show you its compliance verdict as a signal, and (3) discover the publishers and brands tied to your domain. We don’t use it as a Scope3 allowlist — the registry is the source of truth, and we surface what it says rather than deciding for ourselves.

​
What we’ll publish for you — and what we never will

If your publisher isn’t in the registry yet, we can help you get discoverable: publish or sync your inventory identity (your formats, placements, collections) to the community registry on your behalf. We will never touch your authorization. We do not mint or edit your adagents.json authorized_agents[] for you — granting an agent the right to sell your inventory is always your act, made in your own document.
Identity we help you publish; authorization we only ever reference.
Today the supported path is you publish upstream, we pick it up — host your own adagents.json / brand.json and we read it live (with a manual re-resolve when you update). An OAuth-connected “manage my identity on my behalf” path is on the roadmap. Your brand’s corporate hierarchy (house / keller_type / parent_brand) is read and displayed today; using it to drive business rules such as rate cards across a brand family is also roadmap, not yet live.
If a brand lookup comes back empty during onboarding, see what to do when your brand isn’t found.