Agent Offer Network (AON) FAQ

Agent Offer Network (AON) is the offer network for AI-native commerce. It can connect an AI product with eligible structured merchant offers and preserve attribution from user intent to a later reported outcome.

The AI product controls whether and how to present an offer. The merchant remains responsible for current price, checkout, payment, order acceptance, and fulfillment. A reported outcome must satisfy attribution, validation, and the applicable commercial terms before commission is payable.

No. Agent Offer Network (AON), at aon.pro, is not affiliated with Aon plc, AION, AEON, or other organizations that use similar names.

The name was chosen to describe its role in AI-native commerce directly: Agent refers to AI agents and apps, Offer to structured Merchant Offers, and Network to the Publishers, Merchants, Advertisers, and Partners connected through offer discovery and attribution.

Agent Offer Network (AON) is not a general marketplace for AI services or a payment rail. It does not sell arbitrary APIs, execute merchant checkout, hold payment credentials, authorize transactions, or fulfill orders.

AON connects AI products to structured merchant offers and preserves evidence for attribution after a tracked interaction. Merchants and their commerce systems remain responsible for current terms, checkout, payment, order acceptance, and fulfillment.

AON is closer to AI commerce infrastructure than a classic ad network.

It can support affiliate-like outcome monetization, but it is designed around AI product workflows: intent matching, structured offer data, native rendering, and attribution. That makes it different from inventory-led ad networks and from manually placed affiliate links.

AON is built for AI product workflows where offers need to match live user intent and appear inside the product's own experience.

Traditional affiliate networks can work well for websites, content pages, tracked links, feeds, and program relationships. AON focuses on a different use case: retrieving structured offers for AI surfaces, letting the publisher render them natively, and preserving attribution through AON tracking and postback flows.

See details in AON tracking docs.

Use AON when the offer should be selected from the user's current AI task rather than inserted as a fixed link or visual ad slot.

Affiliate links can work for static content, and display ads can work for inventory-based placements. AON is a better fit when recommendations need intent matching, structured offer data, native presentation, and outcome attribution.

AI products need a different monetization layer because the user experience is dynamic, conversational, and often has no fixed ad slot.

AON is designed to match offers to the user's current task, return those offers as structured data, and let the AI product render them in a way that fits the workflow instead of forcing a generic ad placement.

AON is mainly for AI product builders, publishers, app developers, agent teams, and advertisers working around high-intent user tasks.

It is most relevant when an AI product already helps users compare, choose, book, buy, subscribe, or take another commercial next step. These are common agentic commerce workflows.

AON is probably not the right fit when the product has no clear commercial intent or when an offer would interrupt the user's task.

It works best when a recommendation can genuinely help the user move forward. If the goal is only to fill empty space with ads, AON is the wrong framing.

You can monetize an AI product with AON when a user continues through a documented Offer action and the Merchant or Partner reports a qualifying outcome.

The product requests relevant Offers, decides whether to render one natively, preserves the documented attribution path, and checks the reported outcome against the Offer's Goal and applicable commercial terms. A click or referral alone is not a guaranteed payout.

Once your AI product is configured to present a relevant AON offer, it preserves the documented attributed action when the user continues to the seller. The seller or supply partner later reports the qualifying sale, signup, booking, or other Goal through the configured path.

AON evaluates the attribution evidence, Goal match, validation, and commercial terms before the outcome can become payable commission. A click or referral alone is not a guaranteed payout.

It depends on the qualifying event that the merchant or supply partner defines for the offer. A click or referral does not have one universal commission treatment.

A referral can earn commission when it is explicitly defined as the payable event in the applicable commercial terms and it passes attribution and validation. If the offer instead requires an order, purchase, booking, signup, or another downstream outcome, the click or referral preserves attribution but does not qualify on its own. The defined outcome must still be reported and pass the applicable validation and commercial-term checks.

Yes, AON is designed for AI-native products such as chatbots, agents, assistants, and workflow tools.

AON fits best when the product can understand what the user is trying to do, request relevant offers, and present them as a natural part of the answer or workflow.

No. AON does not require a minimum traffic level to join.

You can integrate AON while your audience is still growing. Starting early gives your team time to learn which user requests indicate purchase, booking, or signup intent, test where an offer genuinely helps, and refine the experience before traffic scales.

Offer availability and commission still depend on eligible supply and the qualifying outcomes defined for each offer.

Before an offer can be returned in an AON integration, it must meet the structured-data and serving requirements for its supply path. AON applies the eligibility and targeting rules supported by the active integration; an offer that does not meet those requirements is not eligible to be returned.

This does not make AON a general safety or compliance certification. Merchants remain responsible for product information, current terms, checkout, and fulfillment.

See details in AON Partner offer fetch docs and AON Offer Query docs.

Available merchants and offers vary by request. We do not currently provide a public directory or one network-wide count because eligibility can change by market, category, partner status, environment, and the request itself.

If you have enabled production access, send an AON Offer Query to see the offers currently eligible for a specific request, including the merchant information returned with each offer. To inspect the response format before production access, use the Public Test Sandbox. It returns fixed test data and does not show live production supply.

See details in Offer Query docs and Public Test Sandbox.

Offers can appear wherever they naturally support the user's task.

Common surfaces include inline recommendations, merchant cards, actionable banners, comparison modules, booking widgets, product grids, and custom UI that matches the publisher's product design.

No, AON does not require one fixed ad unit.

AON returns structured offer data so publishers can choose the presentation surface. The integration still needs to preserve required tracking, disclosure, and merchant rules.

See details in Structured offer schema and Offer Query docs.

After a user follows an AON Offer action, they continue to the Merchant or Partner destination. The agentic checkout or other transaction flow runs in that destination, which handles checkout, payment, order acceptance, and fulfillment.

AON preserves the tracking context from the AI product. The Merchant or Partner can later report a qualifying outcome; AON then evaluates attribution, Goal matching, validation, and the applicable commercial terms before commission is payable.

The product should continue gracefully when there is no matching offer.

A good integration can show nothing, keep the original answer flow, use a neutral fallback, or ask for more context. It should not force a low-relevance recommendation just because an offer slot exists.

Use AON only when the offer is relevant to the user's current intent and useful as a next step.

Publishers should avoid over-inserting offers, disclose commercial recommendations where required, and keep answer quality ahead of monetization density.

Show a clear label close to the offer, link, card, or other recommendation surface so users can understand the commercial relationship before they act. The AON SDK includes a disclosure by default when it formats a recommendation, using Sponsored as the default text; publishers can customize that label for their surface.

Disclosure requirements vary by market and product context. Publishers remain responsible for making sure the wording and placement meet their own legal and policy obligations.

AON can return eligible offers with relevance signals or ordering under the selected integration contract. Your app retains the product decision about whether to show a returned offer, where it appears, and how it is presented.

A returned offer is not a mandatory placement or a guarantee that it is the universally best choice for every user.

No. AON does not require your product to show a returned offer or replace a better answer.

Your product should show an AON-powered offer only when it is relevant to the user's stated intent, appropriate for the surface, and clearly disclosed where required. You retain control over whether an offer appears and how it fits the answer.

No. An AON Offer Query returns discovery-time information from the active supply path; it does not guarantee that a price, inventory status, eligibility condition, or promotion will remain unchanged.

Query again when freshness matters, and do not describe returned values as guaranteed or real-time unless the active supply path expressly supports that claim. The merchant or checkout system remains the authority for the current price, availability, transaction eligibility, and binding terms.

See details in Offer Query docs.

A typical AON flow starts with an AI product sending user intent and context, then using agentic offer discovery to receive structured offers, render one or more offers, and preserve attribution for clicks or downstream outcomes.

The exact implementation can use SDKs, direct API calls, or platform adapter paths depending on the product architecture.

See details in Offer Query docs and Tracking docs.

A Developer integration uses AON inside an AI product to query, present, and attribute offers. A Partner integration supplies eligible offer inventory to AON and reports downstream outcomes.

The two paths use different portals, credentials, contracts, and operational responsibilities.

See details in Developer Quick Start and Partner integration.

You can start a basic prototype with the Quick Start and mock mode.

The time needed for production depends on your integration path, offer-surface design, disclosure, analytics, account enablement, and testing.

See details in Quick Start docs.

No, AON is not only an API-only concept, but direct API integration is one supported path.

Teams can use SDKs, REST endpoints, mock mode, and platform adapter paths depending on where the offer decision needs to happen.

See details in SDK docs.

Yes. You can test AON in mock mode without live production credentials. You can also use the Public Test Sandbox to inspect a shared, fixed Offer Query without registration or an application-owned key.

Mock mode is for local prototypes and integration testing. The Public Test Sandbox is non-billable test traffic; neither path proves production offer availability or supplies MCP access, application credentials, or attributable traffic.

See details in Quick Start docs, Public Test Sandbox and Production Access & API Keys.

AON provides TypeScript and Python SDKs, and teams can also integrate directly through REST.

Choose the path that best fits your stack; the SDK documentation has the installation and usage details.

See details in TypeScript SDK reference and Python SDK reference.

Yes. AON works at the application layer, so it can support AI products built with different model providers.

Available integration paths depend on the product surface and environment. AON currently provides a documented Custom GPT Action path for ChatGPT and authenticated MCP access for compatible, enabled hosts. The same zero-code integration is not available for every model or MCP client.

Yes. AON provides an authenticated MCP integration for compatible, enabled hosts, alongside SDK, REST, and platform-specific paths.

MCP clients should use the active server's tools/list response as the authority for currently available tools and input schemas.

See details in Integration guides and Claude integration.

AgentOffer Protocol defines the portable Query, Offer, control, and MCP tool behavior that AON-compatible systems share. MCP is the interface an AI client uses to discover and call an AON deployment's tools.

The protocol defines how compatible tools and data behave. Each deployment separately determines endpoint availability, account access, and the live tools exposed through tools/list.

See details in AON MCP docs and AgentOffer Protocol.

Yes. MCP is the host-to-tool integration path; it does not itself grant a live AON account, offer access, or API credentials. A compatible, enabled host still needs the credentials and endpoint configuration required for its AON environment.

Use the active server's tools/list response for available tools and schemas, and the integration guide for the supported authentication setup.

Your product should send only the current text or image intent and the fields expressly supported by its active integration.

That can include documented constraints or bounded context. Omit optional values when they are unknown, and never infer personal or eligibility attributes. The active integration documentation or tool schema defines the exact fields.

See details in Offer Query docs.

Do not invent missing user details or treat guesses as hard eligibility facts. Your app can ask a focused follow-up question, omit optional context, or continue with a broader request when the active contract supports it.

If the missing detail is required for a safe or valid next step, the product should wait for the user rather than force an offer result.

No. Creating an account, reading the public protocol, or completing a test request does not automatically enable production access.

SDK mock mode runs locally with sample data. The Public Test Sandbox uses shared, fixed, non-billable test data. Neither path creates an Application identity, provides live inventory, or enables attributable production traffic.

Production access requires a serviceable Application and an application-owned Live Key for the applicable environment. Hosted MCP, Reporting, and other authenticated routes require the access and credentials documented for those routes.

See details in Get an API key and AgentOffer Protocol.

AON uses attribution to connect an offer interaction to the AI product and publisher surface that generated it.

AON preserves tracking context through the tracked action, destination, click reporting, conversion event, and partner postback. It then evaluates the reported outcome against that context, so credit does not depend on manual reconciliation alone.

See details in Tracking docs.

The AI product preserves the documented tracked action when the user continues to a merchant or partner destination. The merchant or supply partner later reports the qualified downstream event through its configured server-to-server path, allowing AON to evaluate it against the original offer interaction.

The merchant remains authoritative for checkout and order confirmation. A reported event still needs attribution, Goal matching, validation, and settlement checks before it becomes payable commission.

AON does not require a user's name, email address, ChatGPT identity, or AON account for its normal Offer-attribution path. It uses tracking context such as the Offer interaction and anonymous click identifiers to connect a later reported outcome with the originating AI product.

The AON Privacy Policy explains the additional technical data involved when a user follows an Offer. AON Shopping records the click with the user's IP address and user-agent, forwards standard request headers to the destination, and may provide a derived pseudonymous visitor identifier when the Partner destination requests one. That identifier is not derived from or linked to the user's name, email address, or account. Direct API, SDK, and Partner integrations should send only the fields required by their active integration and follow the applicable data-processing terms.

See details in Privacy Policy and Tracking docs.

AON integrations should send only the intent and context needed to return relevant, eligible offers.

Use only the fields documented for the active integration. Omit optional values when they are unknown, and do not infer personal, location, or eligibility attributes from free text.

AON is designed to collect the minimum information needed to return relevant results and operate the partner network reliably.

See details in Privacy Policy and Offer Query docs.

No. AON does not request, store, or attempt to access conversation history outside the request sent to AON. Publishers should send only the text, image, or context needed for Offer matching and eligibility.

The request itself is subject to the retention rules in the AON Privacy Policy. Search queries and tool-invocation metadata have a default seven-day retention window in the primary database, and a copy is exported to the analytics warehouse where it is not covered by that purge. Operational logs are typically retained for no longer than 30 days. Click records used for attribution reconciliation and settlement history do not currently have a scheduled deletion job, apart from automated cleanup of test-generated records.

See details in Privacy Policy.

AON Offer Goals use CPA or CPS pricing. One Offer can declare multiple explicit Goals, such as a qualified action under CPA and a confirmed sale under CPS, to form a hybrid commercial arrangement; hybrid is not a separate pricing value in the current Offer contract.

Each Offer identifies the qualifying Goal and its applicable commercial terms. Rates, payout timing, fees, and settlement terms depend on the Offer, onboarding, and the applicable commercial terms.

See details in Commission model definition.

Choose the commission model that matches the value the Merchant can verify. CPA can fit a qualified lead, signup, install, or booking; CPS fits a confirmed sale. A hybrid arrangement combines multiple explicit CPA and/or CPS Goals and is not a separate pricing value in the current Offer contract.

The decision should reflect the Merchant's economics, the events it can report reliably, and the validation needed before revenue is payable. CPC is a common advertising model, but it is not a current AON Goal-pricing model.

No. A click or reported conversion provides evidence for attribution; it is not automatically a final payout.

The reported event must match the served Offer's Goal and pass the applicable attribution, validation, deduplication, risk, refund or cancellation, reconciliation, and commercial-term checks before it can become payable. Rates, fee splits, payout timing, any thresholds, and settlement schedules depend on the applicable offer, account, and commercial terms. Estimated earnings shown in reporting are not finalized settlement amounts.

See details in Reporting API and Commission settlement.

Enabled Developer accounts can use AON's application-scoped reporting API to retrieve clicks, conversions, and estimated earnings for supported offer references.

Estimated earnings are not finalized settlement amounts. Reporting availability depends on the authenticated application and available coverage.

See details in API reference.

Merchants and Advertisers can advertise through AON by making structured Offers available, defining qualifying outcomes, and agreeing commercial terms so compatible AI products can consider eligible Offers for relevant user requests. The Advertiser owns the Offer program and commercial terms; the Merchant owns the product or service, transaction destination, and fulfillment. One business can perform both roles, or a supply Partner can connect the Offer to AON and report downstream outcomes.

The AI product decides whether an Offer helps the user's current task and controls its presentation. AON does not guarantee placement, recommendation, or conversion.

Not always. The Merchant owns the product or service and destination experience, while the Advertiser owns the Offer program and commercial terms; the same business can perform both roles. An approved supply Partner may expose Offers from one or more Merchants to AON and report downstream outcomes.

The required setup depends on the approved supply path. A Merchant does not generally need to build an MCP server, provide an agentic checkout API, add Schema.org markup, or send its catalogue directly to AON unless the selected integration requires it. Merchants remain responsible for current Offer information, price, availability, checkout, payment, and fulfillment.

See details in Partner integration.

AON needs structured offer data that can be queried, ranked, rendered, tracked, and attributed safely.

At a minimum, a partner should provide clear offer content, merchant identity and destination, supported eligibility conditions, the applicable Goal and commercial terms, and postback responsibility for qualified outcomes. AON uses only targeting inputs supported by the active integration. Submitting offer data does not guarantee delivery, presentation, current availability, or conversion.

See details in OfferProvider API.

Yes. AON supports outcome-based commercial arrangements in which a merchant defines a qualifying event and pays only after it is attributed and validated. A sale can use CPS terms; a qualified lead, signup, booking, or install can use CPA terms.

The merchant or supply partner must be able to report the defined outcome reliably, and the applicable commercial terms determine final settlement.

Advertisers can define supported offer conditions in their supply setup, but they do not directly control an AI product's presentation decision.

AON and the active deployment apply those conditions using the request inputs they support. The AI product still decides whether a returned offer helps the user's task, and merchant checkout remains responsible for final transaction eligibility.

See details in Category taxonomy and Location targeting.

AON supports recommendation quality by making offers structured, attributable, and tied to user intent rather than generic ad inventory.

Publishers should still control when offers appear, avoid irrelevant placements, disclose commercial recommendations where required, and prefer no offer over a low-quality recommendation.