adagents.json is a file a publisher hosts on its own domain to declare which properties it owns and which AI sales agents are authorised to sell them. It is part of AdCP, the Ad Context Protocol, published by AgenticAdvertising.org. A buyer agent reads the file before it buys; if the selling agent is not listed, the offer has no publisher backing. The idea comes from ads.txt, with more precision: an authorisation can be scoped to particular properties, placements, countries and dates.

TL;DR. According to the AdCP documentation, adagents.json lives at /.well-known/adagents.json on the publisher's domain and lists each authorised agent by its exact endpoint URL. Each entry states what the agent may sell, and can record whether the path is direct, delegated or through an ad network. Buyer agents check the file against the seller's own brand.json declaration, a two-sided check modelled on the way ads.txt and sellers.json work together. The AgenticAdvertising.org registry indexes publisher files for lookups. The file proves who may sell, not who operates the agent or whether the inventory will deliver.

What is adagents.json?

adagents.json is the publisher-side authorisation record in AdCP. The AdCP documentation, at version 3.2 (build 3.2.3) as of October 2026, describes it as the foundation of property governance: it defines what properties exist and who can sell them.

The file must be valid JSON, served over HTTPS with a 200 response and an application/json content type, at the well-known path defined by RFC 8615. Only someone who controls the domain can change it, so domain control stands in for proof that the publisher made the declaration.

What does a publisher declare in adagents.json?

A publisher declares its properties, each with identifiers such as a domain or app store ID, and its authorised agents. The authorized_agents array is required. Each entry carries three required fields, according to the AdCP documentation: the agent's url, a human-readable authorized_for description, and an authorization_type naming how the covered inventory is selected.

Optional qualifiers narrow the grant. delegation_type records the commercial path as direct, delegated or ad_network. placement_ids and placement_tags limit the grant to named placements. countries takes ISO two-letter country codes. effective_from and effective_until set a time window, and exclusive marks an agent as the sole authorised path for that slice of inventory.

In a hypothetical example, a news publisher could authorise its own sales agent, exclusively and as direct, for homepage sponsorships in the UK, while authorising an ad network's agent for programmatic placements in other countries. A buyer agent can tell the two paths apart; a flat seller list cannot.

How does a buyer agent check adagents.json?

A buyer agent checks adagents.json by matching the agent it is talking to against the publisher's list. According to the AdCP documentation, the buyer asks the sales agent for its portfolio through get_adcp_capabilities, fetches and caches adagents.json from each publisher domain the agent claims, then confirms that every property in a product returned by get_products is covered by an entry for that agent. The check should run before create_media_buy, and again periodically on long-running campaigns.

Matching is canonical but strict on the path: https://agent.example.com does not match https://agent.example.com/mcp. An agent serving MCP and A2A at different URLs needs an entry for each.

Publishers can also pin signing_keys, the public keys an agent may sign with. They must do so for any agent allowed to perform tasks that change state on the publisher's behalf, such as create_media_buy or update_media_buy, and verifiers must reject a signature made with a key outside the pinned set. A compromised agent domain then cannot silently swap in new keys.

How does adagents.json relate to ads.txt and sellers.json?

adagents.json does for agents what ads.txt, introduced in 2017, did for programmatic sellers: it puts the authorisation on the publisher's domain where buyers can read it. The AdCP documentation's comparison is that ads.txt answers a narrower question, whether a seller is listed as direct or reseller, without saying which property, placement, country or time window is covered.

sellers.json, introduced in 2019, is the other half of the programmatic check: the exchange declares which publishers it represents. In AdCP, that half is carried by the operator's brand.json file, which lists its sales agents and the properties it sells, each with a relationship value. For direct, delegated and network paths, that value must match the publisher's delegation_type. One-sided claims do not count: if a seller's brand.json claims a publisher that does not list the agent, the documentation says not to treat it as authorisation, because any domain can claim any publisher.

ads.txt and sellers.json remain in everyday use for programmatic trading, and adagents.json is designed to sit alongside them: it has a contact.seller_id field for a sellers.json seller ID, and validators may use an ads.txt MANAGERDOMAIN entry as a legacy fallback.

What does the AgenticAdvertising.org registry do?

The AgenticAdvertising.org registry is a public REST API for discovering agents and checking authorisation. Its publisher lookup, GET /api/registry/publisher?domain=X, returns a publisher's properties and the agents its adagents.json authorises. Other endpoints validate a domain's file, search agents by channel, market and property type, and queue a re-crawl after a publisher updates its file.

According to the AdCP documentation, the agent catalog contains only agents that AgenticAdvertising.org members have enrolled. Agents named in crawled adagents.json files feed the authorisation lookups but do not create catalog entries. A listing is not an authorisation, and an authorisation is not a listing.

What should a publisher check before publishing adagents.json?

A practical checklist, drawn from the AdCP documentation:

Host the file at https://yourdomain/.well-known/adagents.json, and if the domain redirects to www, serve it at the final URL too.
Copy each agent's endpoint URL exactly as the operator supplies it, path included, with one entry per URL.
Grant the narrowest scope that fits the deal: specific properties, placements, countries and dates.
Set delegation_type and confirm it matches the relationship the operator declares in its brand.json.
Pin signing_keys for any agent allowed to create or change buys, and carry old and new keys together during a rotation.
Fill in contact, including the sellers.json seller ID where one exists.
Validate the file with the registry's validator or the AdAgents.json Builder, then request a re-crawl.
Remove an agent's entry promptly when a relationship ends. The documentation names revocation as the remedy for a misbehaving authorised seller.

What does adagents.json not prove?

adagents.json proves that a publisher authorised an agent. The AdCP documentation lists what the chain does not prove: who the legal entity behind the agent is, whether the quoted avails and prices will hold at delivery, and whether the hosting behind the files, such as DNS, CDN and registrar, can be trusted. Delivery truth sits with measurement and billing reconciliation.

Publishers working across standards should also note that IAB Tech Lab's AAMP framework handles agent discovery through the IAB Tech Lab Agent Registry, where companies list the agents they bring to market, so keeping both listings current avoids gaps. Alkimi's marketplace is neutral and works within IAB Tech Lab's AAMP framework today, and it is being built to be AdCP compatible; terms agreed there are recorded on a shared DealSheet both parties hold, with humans keeping approval rights at the deal level.

Frequently asked questions

Where does adagents.json go?

At /.well-known/adagents.json on the publisher's domain, served over HTTPS as valid JSON with a 200 response, according to the AdCP documentation.

Is adagents.json the same as ads.txt?

No. Both are publisher-hosted authorisation files, but adagents.json names agents by endpoint URL and can scope each grant by property, placement, country and time window.

What is the sellers.json equivalent in AdCP?

The operator's brand.json, which declares its sales agents and the properties it sells with a relationship value. Buyers check that value against the publisher's delegation_type in adagents.json.

Who runs the AdCP registry?

AgenticAdvertising.org, which publishes and governs AdCP. The registry indexes publisher adagents.json files and keeps a separate catalog of member-enrolled agents.

Does adagents.json verify the company operating an agent?

No. The AdCP documentation states that the authorisation chain does not establish the legal entity behind an agent. Buyers still need their own checks on a new counterparty.

What Is adagents.json and How Do Publishers Authorise Seller Agents Under AdCP?