Skip to main content
If your product creates advertising content and also needs to buy media, it can bring a finished creative from its own pipeline or, when available, use a connected creative engine to build one. Both paths should meet at the same handoff: durable assets, a creative manifest, an exact approved version, and the campaign that will use it. Connect the application—or a buyer agent it operates—to Interchange for the buying loop. Interchange is the multi-seller transaction layer; it is not necessary to build and maintain a separate adapter for every seller. This page describes ways to compose a buying workflow. It does not treat every MCP client as a buyer agent. Claude or ChatGPT can call the same tools in an authorized user’s interactive session without becoming software installed in the buyer organization.

​
An MCP client is not automatically a buyer agent

Registration is about durable software identity and governance, not which V3 calls the software makes or how intelligent it is. If a user tells Claude what to buy and Claude calls V3 under that user’s connection, they are using an agent-assisted Interchange workflow. They have not built or installed a buyer agent. Register an external buyer agent only when the software needs an identity, authority, and lifecycle separate from a human’s interactive session. “Light” and “heavy” are useful implementation descriptions, not product identity classes. A light agent may keep only durable workflow checkpoints and Interchange object/report references; a heavier runtime may also orchestrate creative pipelines and external data tools. Either becomes a buyer agent only through the registered-principal boundary above. Your MCP client, application, or registered buyer agent should call the single Interchange V3 MCP endpoint. It should not call each seller independently or recreate seller-specific commercial, authorization, execution, and reporting adapters underneath Interchange.

​
Two creative paths, one handoff

Design the workflow so the creative pipeline is replaceable. A customer should not have to adopt an orchestrated generation experience to use Interchange for assets, creative manifests, validation, buying, and delivery. The managed path can add value through format-aware planning, provenance, evaluation, rendition preparation, approval checkpoints, and consistent cost and usage records. Those conveniences must remain optional. The portable contract is the asset plus creative manifest—not the pipeline that produced them. In a future v3 surface, creative engines can be discoverable counterparties in the same way sellers are discoverable today. That does not imply every engine must be called through Interchange. A buyer-controlled agent may call a provider’s API or MCP tools directly and then register the result through the portable handoff.

​
What is available now

v3 is MCP-only. If your server requires REST rather than acting as an MCP client, use the stable v2 REST API against the same Interchange account data.

​
Application, agent, or both?

For a production product today, use a hybrid architecture:
  1. Let an application-controlled durable store own IDs, idempotency keys, retries, customer approvals, workflow checkpoints, and immutable Interchange report references. A buyer agent may drive those checkpoints, but one model turn should not be their only record. Keep canonical delivery facts, aggregation, and reporting results in Interchange instead of building a second reporting warehouse in the orchestrator.
  2. Use an agent for judgment-heavy steps such as turning a goal into a brief, comparing proposals, explaining tradeoffs, and suggesting an allocation.
  3. Require an explicit application-controlled confirmation before the save_campaign call that makes a campaign active.
Pure application orchestration is a good fit when every transition is deterministic. An interactive Claude or ChatGPT connection is a good fit for a human-guided workflow and requires no buyer-agent registration. A registered, customer-operated external buyer agent is appropriate when the software must continue independently with its own identity, grants, lifecycle, and machine notifications. All three use the same V3 buying tools; Interchange remains the execution layer. Do not rely on one long model turn to own the workflow. Proposal requests, creative reviews, and delivery happen asynchronously. Persist the returned advertiser, asset, creative, campaign, proposal, product-query, media-buy, and revision identifiers in an application or agent control plane, then resume from fresh get and search results. A future hosted buyer agent can provide that control plane without becoming a second reporting warehouse.

​
Example: AI-created radio spot to media buy

The following workflow works even though Interchange does not currently generate the radio creative. A user can drive it interactively from Claude, an application can encode it deterministically, or a registered external buyer agent can run it under its own grants. The buying calls are the same; identity, durability, and governance are not.
  1. Choose the creative path. Today, create the spot outside Interchange: your application or agent calls its chosen audio-generation provider and stores the master asset and provenance. A future managed creative pipeline should produce the same handoff without changing the remaining buying steps.
  2. Collect customer content approval. Record who approved which immutable creative version. This is your product’s approval and does not replace a seller or ad-server creative review.
  3. Open the buying workspace. Call get_status, create or select the advertiser, and use save_campaign to create a draft with the brief, flight, and budget.
  4. Discover suitable inventory. Call request_proposals, poll the same execution to a terminal result, follow every result cursor, and present the returned proposals or products. Preserve qualified IDs exactly.
  5. Prepare the delivery-ready rendition. Check the selected product’s accepted formats. If the approved master does not already satisfy them, create a compliant rendition outside Interchange and approve that exact version. Attach its HTTPS URL or supported inline data URL with save_creative, using assetType: "AUDIO".
  6. Stage the buy. Call save_media_buy with the selected qualified proposal or product identities and allocation. This creates draft buying state; it does not spend or launch.
  7. Review readiness. Use get on the campaign and media buys, including creative detail where offered, or open open_campaign_receipt in an MCP Apps host. Resolve format, creative-review, funding, or seller-readiness blockers before launch.
  8. Confirm and launch. Preview save_campaign with desiredPhase: "active" and an idempotency key, show the returned budget, flight, and staged buys to the authorized user, then send a second call with confirmLaunch: true, the returned revision, and its own idempotency key.
  9. Report. Query get_delivery for explicit date ranges, metrics, and dimensions. This is seller-reported delivery; it is not independent buyer measurement or proof of billing finality.
If the product insists on creating and approving the finished spot before inventory selection, treat that file as a master. Inventory can impose a different duration, codec, bitrate, channel layout, or other format constraint, so the workflow may still need a destination-ready rendition and a second approval before attachment.

​
Keep the approvals separate

Never infer one decision from another. In particular, a customer-approved spot can still fail destination format validation or seller review, and a staged media buy is not evidence that the campaign has launched.