Buyer agents vs sales agents in agentic buying

Key takeaways

A buyer agent plans and buys for an advertiser or agency; a sales agent describes and sells a publisher's inventory and turns buys into ad server line items.
AdCP also defines signal, creative, governance and brand agents with their own required tasks; AAMP's reference code centres on a buyer SDK and a seller SDK, with audiences in a separate Agentic Audiences project.
Under AdCP the buyer side owns the plan and its governance checks, and the seller verifies a signed governance context before executing.
Humans stay in the loop through async approval states: AdCP buys can sit in submitted for days, and AAMP's seller SDK pauses flows at approval gates until an operator decides.
To run the publisher side you need a product catalogue, an ad server mapping, published authorisation, per-buyer credentials, approval rules and reconciled reporting.

In agentic buying, a buyer agent works for the advertiser or agency and a sales agent works for the publisher. Signals, creative and governance agents plug in around that pair, and people still approve the buys that matter. This post sets out how AdCP (now at 3.2.8) and IAB Tech Lab’s AAMP define each role, how the agents talk, where humans stay in the loop, and what a publisher needs to run its side.

Who are the agents in an agentic buy?

Role	Works for	AdCP	AAMP reference code
Buyer agent	Advertiser, agency or trading desk	“Orchestrator (buyer)” that calls sales agent tasks	Buyer Agent SDK
Sales agent	Publisher, SSP or sales house	MCP or A2A server exposing products and buys	Seller Agent SDK
Signal agent	Data provider or buyer	`get_signals`, `activate_signal`	Agentic Audiences project
Creative agent	Brand, agency or creative platform	`build_creative`, `preview_creative`, `sync_creatives`	No dedicated repository
Governance agent	Buyer	`sync_plans`, `check_governance`	No dedicated repository

AdCP also defines a brand agent, which serves get_brand_identity and brand rights tasks. AAMP’s hub repository lists seven projects: Agentic Direct, the buyer and seller agents, OpenProposal, a registry agent example, ARTF and Agentic Audiences.

What does a buyer agent do?

A buyer agent turns a brief into a plan, finds sellers, asks for products or proposals, books, sends creatives and tracks delivery.

In AdCP, the conformance rules call the buyer side an orchestrator, and say orchestrators “are not MCP/A2A servers”: they are clients that call sales agent tasks. A conformant orchestrator must authenticate with each sales agent, send the required fields, handle async statuses (submitted, working, input-required) and webhook deliveries, use the returned media_buy_id for every later call, and respect the seller’s creative_deadline. The buyer side also owns the campaign plan. It records the plan with its governance agent, checks intent before asking a seller to execute, and attaches the signed governance context to the seller request.

In AAMP, the Buyer Agent SDK is a Python reference implementation built on CrewAI. A brief goes to a Portfolio Manager agent, which hands work to channel specialists (Branding, CTV, Mobile, Performance, Deals) and then to functional agents (Research, Execution, Reporting, Audience). It reaches sellers through three clients: a media kit client to browse inventory, a negotiation client for multi-turn deals and an OpenDirect client to book orders, over MCP, A2A or REST. An optional vendor gate checks each seller against the IAB Diligence Platform and fails closed.

What does a sales agent do?

A sales agent answers questions about your inventory in structured terms, accepts buys you are willing to take, and turns them into something your ad server can deliver.

In AdCP, a sales agent must implement get_adcp_capabilities, get_products, create_media_buy, update_media_buy, get_media_buys, get_media_buy_delivery and provide_performance_feedback, plus sync_creatives if it hosts a creative library. AdCP’s seller guide splits the publisher’s job into four parts: publish an adagents.json authorising your agent, publish operator identity, expose inventory as products, and accept and fulfil buys. On that last part the guide is explicit that your platform processes a buy “according to your normal workflow”, whether that is instant activation, internal review or an approval queue.

In AAMP, the Seller Agent SDK uses a three-level hierarchy: an Inventory Manager, channel specialists (Display, Video, CTV, Mobile App, Native, Linear TV) and functional agents (Pricing, Availability, Proposal Review, Upsell, Audience). It prices by buyer identity across four tiers (public, seat, agency, advertiser), and caps the tier by the buyer agent’s trust status, so an unknown agent sees public pricing and a blocked one gets a 403. It connects to Google Ad Manager and FreeWheel and can distribute deals through SSP connectors.

For the catalogue work behind either kind of sales agent, see How to make your inventory agent-ready for AdCP.

Where do signals, creative and governance agents fit?

These roles are spelled out in AdCP; AAMP’s reference code folds most of this logic into the buyer and seller SDKs.

Signal agents discover audience and contextual segments and activate them on decisioning platforms. They must enforce access control for private signals, and data providers authorise them through the signals section of their own adagents.json.
Creative agents build or transform a creative, preview it, collect human approval where the agent or publisher requires it, and sync the approved version.
Governance agents work for the buyer. They hold the plan (sync_plans), approve or deny actions against it (check_governance), and keep the audit trail. The buyer registers its governance agent with the seller through sync_governance, and the seller can call it during the buy. The seller’s main job is narrower: verify the signed governance context before executing, reject a missing, expired, replayed or mismatched one with PERMISSION_DENIED, and report what actually delivered. It does not reinterpret the buyer’s policy.

In AAMP, audience work sits in the separate Agentic Audiences project. The AAMP 3.0 release says the SDKs are hardening “deterministic guardrails governing pricing, ad packages, orders and media buy details”, which puts those controls inside the agents rather than in a separate governance role.

How do buyer and sales agents talk to each other?

Both standards run over MCP and A2A. A2A is the agent-to-agent protocol Google created and donated to the Linux Foundation. Sharing transports does not make the standards compatible: AdCP’s FAQ says they are “not wire-compatible merely because both support MCP and A2A”. Our AAMP vs AdCP comparison covers the differences.

An AdCP buy runs like this:

The buyer reads the publisher’s adagents.json to find authorised sales agents, then calls get_adcp_capabilities.
It asks for products with a brief (get_products, or list_products and request_proposals in 3.2).
If it uses governance, it checks intent with its governance agent.
It books with create_media_buy (or buy_products and accept_proposal in 3.2). The seller can answer completed, input-required or submitted.
It uploads creatives with sync_creatives before the deadline.
It adjusts the buy in flight and pulls delivery with get_media_buy_delivery.

The same tasks work over MCP tool calls or A2A messages, and AdCP keeps one status system across both.

An AAMP buy leans on IAB Tech Lab’s existing standards. The buyer browses a seller’s media kit, where unauthenticated callers see price ranges and authenticated ones see exact pricing. It negotiates in rounds and books through OpenDirect 2.1 orders or Deals API deal IDs. The seller SDK serves MCP today; its A2A interface is documented as “designed, not implemented”. AAMP 3.0 adds OpenProposal, a draft spec for the RFP-to-proposal step (publish, discover, compare, qualify, negotiate, bind and execute, report), whose public comment period IAB Tech Lab extended to 10 November 2026. Buyers can find sellers in the IAB Tech Lab Agent Registry, which lists MCP and A2A agents and ties each company to its GPP ID.

Where do humans stay in the loop?

Neither standard assumes an agent signs a guaranteed IO alone.

AdCP’s security model names five places for human judgment: setting intent, setting boundaries, handling exceptions, overriding live buys, and auditing afterwards. In practice:

Approval is an async state. A buy that needs sign-off returns submitted, and the orchestrator design guide expects operations to take “seconds, hours, or even days”.
Exceptions escalate. When a governance agent returns conditions or a denial, the decision goes to a person by design.
Some categories always need review. If a plan’s policy categories include fair housing, fair lending, fair employment or pharmaceutical advertising, human_review_required: true is a schema requirement, and buyers cannot opt out.
Seller defaults are conservative. The Prebid Sales Agent defaults guaranteed products to manual approval and non-guaranteed products to confirmation_required.

AAMP’s seller SDK has approval gates you switch on with APPROVAL_GATE_ENABLED=true. When a gated flow reaches a decision, the API returns pending_approval to the buyer and the flow pauses. An operator lists pending approvals, decides to approve, reject or counter, and resumes the flow. APPROVAL_TIMEOUT_HOURS sets when an unanswered request expires.

What does a publisher need to run its side?

A product catalogue agents can read. Your rate card as structured products, not ad unit paths. This is most of the work.
An ad server mapping. Each product tied to line item templates, ad units and targeting your ad server can actually execute.
Published authorisation. An adagents.json for AdCP; a registry entry with your GPP ID for AAMP. Keep ads.txt and sellers.json as they are.
Credentials per buyer. Separate buyer and operator access, so buyer agents never see your approval or rate card tools.
Approval rules per product. Start with everything manual or confirmation-required and loosen product by product.
Governance verification. If buyers send signed governance context, your agent must verify it and refuse mismatches.
Reporting that reconciles. Delivery reported to agents should match your ad server report for the same buy and timezone.
A standard to start with. The two are not wire-compatible, so supporting both means two agent interfaces over one catalogue. Start with the one your buyers use.

What to do next

Pull last year’s IOs and list the products you would let an agent buy.
Decide which of them can book without a person, which need confirmation and which stay manual.
Ask any vendor whose sales agent you are evaluating which roles and tasks it implements, and which standard version.
For why direct-sold is the place to start, read Agents aren’t coming for the auction.

BidCliq builds header bidding and agentic tools for publishers, and our sales agent is verified by AgenticAdvertising.org against AdCP 3.1.

Frequently asked questions

What is the difference between a buyer agent and a sales agent?

A buyer agent acts for an advertiser, agency or trading desk: it turns a brief into a plan and buys media. A sales agent acts for a publisher or sales house: it exposes products, accepts buys and maps them to the ad server.

What is an orchestrator in AdCP?

AdCP's conformance rules call the buyer side an orchestrator. Orchestrators are not MCP or A2A servers; they call sales agent tasks, handle async statuses and webhooks, and use the returned media_buy_id for every later operation.

Who runs the governance agent in AdCP?

The buyer side. The buyer agent calls its governance agent to check intent and execution against the plan, then attaches a signed governance context that the seller verifies before executing.

Can an agent book a guaranteed campaign without a person approving it?

Only if the publisher allows it. AdCP buys can return submitted and wait for approval, the Prebid Sales Agent defaults guaranteed products to manual approval, and AAMP's seller SDK can pause deals at approval gates.

Do I need to support both AdCP and AAMP?

Not necessarily. They are not wire-compatible, so supporting both means two agent interfaces over one product catalogue. Pick based on which standard your buyers use.

About the author

Sharad Yadav

Founder, BidCliq

Sharad Yadav is the founder of BidCliq, a publisher-first ad monetization platform that helps publishers and ad ops teams run header bidding, Prebid and programmatic across display, video, app and CTV. Before BidCliq, he led AdTech and product at GeeksforGeeks, where he built an in-house ads product that doubled programmatic revenue within nine months and an anti-adblock solution that lifted ad yield by 10%. He is a founding member of AdCP.