Brand Agent

A brand agent is the AdCP agent that answers questions about a brand: who owns it, what it looks like, and whose likeness or voice may be generated on its behalf. AdCP’s architecture module describes the role as: “Manages brand identity and guidelines via brand.json”.

Four different things go by the name. This entry covers the first.

The term is not in AdCP’s own glossary, which defines Agent, Sales Agent and Signal Agent, and uses “brand agent” only inside other terms’ definitions.

What a brand agent answers

Creative agents are the main callers, and they call before generation rather than during a buy. From AdCP’s brand specialist guide: “A creative agent fetches brand.json (or calls get_brand_identity authorized), then pulls the wordmark, applies the exact palette and type scale, adopts the tone of voice, and obeys the restrictions.” The rights-licensing walkthrough has a buyer agent calling it too.

Answers come in two tiers. Any caller gets the public baseline unauthenticated: house, names, description, industries, keller_type (the brand-architecture classification), basic logos, tagline. Assets, voice synthesis, tone, restrictions and rights availability need a linked account, set up once by calling sync_accounts. Until then the response lists the withheld sections in available_fields, so a caller can tell an unauthorised response from an incomplete file.

How a brand agent is declared

A brand agent is declared in one file, brand.json, fetched from https://example.com/.well-known/brand.json under RFC 8615. There is no registry to join. Two shapes declare one: a standalone brand agent document, or a type: "brand" entry in the agents[] array of a fuller file, either a house portfolio or a brand’s canonical document. AdCP’s brand.json reference treats the two routes as equivalent, and all five file variants are laid out on discovery files.

In dist/schemas/3.1.13/brand.json, properties.brand_agent carries "deprecated": true and this note:

Deprecated: use agents array with type ‘brand’ instead. Brand agent that provides dynamic brand data via MCP.

rights_agent goes the same way. The replacement is an agents[] entry whose type comes from an eight-value enum titled “Brand Agent Type”.

Both sales and buying appear in the same enum, so an entry records only that the brand declared the agent, not which side of the trade it sits on. The sales agent entry sets out the same collision in AdCP’s role names.

Mechanically the change is a rename with a discriminator added: {"url": ..., "id": ...} under brand_agent becomes {"type": "brand", "url": ..., "id": ...} inside agents[]. type, url and id are required, everything else is optional, and an unset jwks_uri defaults to /.well-known/jwks.json on the origin of url.

AdCP’s brand-json.mdx reference still tables brand_agent as an ordinary optional object, agents has no row in that table, and the file’s one deprecation note is about rights_agent. The schema says deprecated rather than removed and names no removal version, so both shapes stay readable: a producer writing new files uses agents[], and a consumer has to accept either.

Operations and conformance

Six AdCP operations are registered to the brand agent. The four Sponsored Intelligence operations are registered separately and are not in this table.

The conformance table and the registered operations do not line up in either direction. creative_approval is listed Conditional, “required when the agent reviews AI-generated content”, with no operation of that name behind it; it is the payload a buyer submits to the approval_webhook from acquire_rights. verify_brand_claim and verify_brand_claims are the reverse case: both are callable, and neither appears in the conformance table, so nothing in 3.1.13 says whether they have to ship. The one hard requirement stated is that brand agents MUST declare brand in supported_protocols.

The rights half is flagged experimental

acquire_rights can issue scoped generation_credentials, bounded by a rights_constraint on uses, countries and an impression cap, after which generation stops. AdCP’s brand specialist guide names Midjourney for likeness and ElevenLabs for voice as providers that verify those credentials at generation time. Both names appear in documentation, not in the schemas.

All of it sits in the brand.rights_lifecycle experimental cluster under a strict declaration rule: any implementation of a task in it MUST declare the cluster id. “Partial implementation is allowed; silent implementation is not.” AdCP gives its reason for the flag as a “Legal-construct surface added late in the 3.0 cycle” whose first deployments will expose edge cases in partial rights, sublicensing and revocation.

Brand agent in AAMP

AAMP defines no brand agent. Three artifacts in the IAB Tech Lab repositories use the word, and none is a callable brand service.

The first row is the one a search surfaces, and it is a persona inside the buyer agent rather than a service anyone can call. The nearest thing AAMP has to brand identity on the wire is the advertiser_brand_id string.

The buy-side sense

Scope3’s published definition is the buy-side one: “an AI buying agent that acts on behalf of a brand — translating objectives, budgets, and brand standards into advertising decisions”. That is type: "buying", another value in the same Brand Agent Type enum. AdCP’s own decision-maker material reaches for the buy-side reading too, calling a brand agent “a personal shopper”. AdCP’s schemas implement the identity sense.

The well-known path is contested as well. Brand Context Protocol v0.7, published by Encoded Brands and dated 2026-07-05, serves /.well-known/brand.md. Its specification says the brand.json output projects into AdCP’s “brand_agent/get_brand_identity contract”, which is the field AdCP deprecated, and neither corpus acknowledges the other. A document can be valid BCP output and still carry the shape AdCP is retiring.