# Agent-Native Sponsored Discovery ## Thesis Build an **agent-readable sponsored-offer layer**, not prompt injection. Merchants publish typed, verifiable commercial offers. Agents may consider them as paid candidates, but sponsorship can never become an instruction or outrank the human's stated constraints. The near-term business is not an ad network. It is **merchant feed infrastructure + trust + measurement**. An exchange becomes possible only after enough merchants and agent surfaces use the format. ## Product principles 1. **Data, never instructions.** Offers are parsed into a strict schema. Advertiser text never enters the privileged instruction context. 2. **Disclosure survives the whole chain.** Every candidate carries `paid_placement=true`, sponsor identity, and compensation model. If surfaced, the agent tells the human it is sponsored. 3. **User alignment beats bid.** An offer is eligible only after hard user constraints, safety checks, availability, and quality thresholds pass. Bid may rank only among eligible sponsored candidates. 4. **Independent comparison.** An agent should compare a sponsored candidate against organic alternatives. Sponsorship earns consideration, not endorsement. 5. **No transcript targeting.** The exchange receives a coarse intent taxonomy and necessary constraints, not the human's raw conversation or sensitive traits. 6. **Verifiable claims.** Price, availability, terms, cancellation rules, location, and evidence URLs have timestamps and expirations. 7. **Easy refusal.** Agents and humans can disable sponsored candidates globally or by category. ## Protocol v0.1 ### Discovery A merchant exposes: - `/.well-known/sponsored-offers.json` - An HTML `` - An HTTP `Link` header with `rel="sponsored-offers"` Use existing `schema.org/Product` and `schema.org/Offer` for product facts. The sponsored envelope adds fields that ordinary structured data lacks: sponsor identity, paid-placement disclosure, compensation model, evidence, targeting taxonomy, attribution limits, agent-handling policy, expiry, and signature. `llms.txt` can point agents to documentation but should not carry the offer itself; it is a proposal/convention, not an ad or trust standard. MCP/A2A can transport offers later, but neither should be required for the web MVP. ### Exchange request An agent sends only coarse, consented intent: ```json { "intent": "travel.activity", "destination": "Austin, TX", "dates": {"start": "2026-11-07", "end": "2026-11-09"}, "party_size": 2, "constraints": {"max_price_usd": 150, "accessible": true}, "sponsored_candidates_allowed": true } ``` Do not send names, raw prompts, persistent IDs, inbox content, or sensitive attributes. Use an ephemeral request ID. ### Agent decision pipeline 1. Apply the human's hard constraints. 2. Reject expired, unsigned, unverifiable, unsafe, or mismatched offers. 3. Fetch live price and availability from the merchant. 4. Calculate quality/relevance independent of bid. 5. Keep only offers above a minimum utility threshold. 6. Let bid rank only within this eligible sponsored set. 7. Compare the best sponsored offer against organic candidates. 8. Surface at most one sponsored option in a short list, clearly labeled. 9. Require the human's confirmation before purchase. Recommended wording: **“Sponsored option from X — it matches your dates and budget; I also compared it with Y and Z.”** ## Threat model - **Prompt injection in descriptions:** strict typed fields, length limits, HTML removal, never concatenate advertiser content into system/developer messages. - **False claims:** domain verification, evidence URLs, live price checks, expiry, advertiser liability, audits. - **Bid overwhelms relevance:** two-stage ranking; bid is invisible until eligibility and quality pass. - **Tracking abuse:** no transcript, fingerprint, or sensitive-trait fields; short-lived tokens; aggregate reporting. - **Fake agents/click fraud:** signed requests, rate limits, conversion reconciliation, anomaly detection, advertiser/publisher reputation. - **Disclosure stripping:** cryptographically bind disclosure to the offer; agent integration contract requires user-visible labeling. - **Malicious landing pages:** safe-browsing scans, domain allowlists, redirect-chain limits, and human confirmation before action. - **Price baiting:** compare advertised vs checkout price and automatically suspend merchants with excessive deltas. ## Business model ### Phase 1 — Agent commerce readiness SaaS Sell merchants a tool that: - turns catalog/booking data into compliant agent-readable offer feeds; - verifies price, availability, terms, and evidence; - publishes the well-known endpoint and schema markup; - shows agent crawl, consideration, referral, and conversion analytics; - provides test prompts and an agent-readiness score. Indicative pricing: - Starter: $99/month, one domain, limited offers. - Growth: $499/month, live inventory, analytics, experiments. - Enterprise: $2,500+/month, multiple catalogs, SLA, policy controls. This works without agent-platform deals: merchants gain better machine-readable data and can test against browser agents today. ### Phase 2 — Curated sponsored marketplace Start with **travel activities and local experiences**, not flights or general retail. The category is high-intent, fragmented, has clear inventory and conversion events, and lets a local publisher/concierge agent add genuine value. Pricing: - Pilot: fixed monthly sponsorship to remove attribution arguments. - Then: cost per qualified consideration/referral plus CPA on completed bookings. - Avoid CPM. Agents do not create meaningful impressions like webpages do. - Avoid charging for mere ingestion. Payment is for eligible consideration or attributable outcomes. Take rate target: 20–30% of media/CPA revenue after merchant payouts and fraud reserves. Treat this only as a hypothesis until pilots establish conversion and support costs. ### Phase 3 — Exchange/API Offer agent platforms a free, policy-controlled candidate API and share revenue. Platforms choose categories, disclosure UI, maximum sponsored density, privacy mode, and quality threshold. The exchange never gets authority to purchase. ## Go-to-market ### Initial customer Independent tour operators, attractions, boutique lodging/experience providers, and destination publishers with bookable inventory but weak structured feeds. ### 90-day pilot 1. Recruit 10 Austin travel/activity merchants. 2. Normalize 100–500 live offers. 3. Publish signed offer endpoints and a public conformance tester. 4. Build one reference travel-planning agent that mixes organic and sponsored results. 5. Run fixed evaluation prompts covering dates, budget, accessibility, family needs, and no-ad preference. 6. Test with 50–100 consenting users. 7. Charge three merchants a small fixed pilot fee before building an auction. Success metrics: - 95%+ price/availability accuracy at presentation time. - 100% sponsorship disclosure retention. - Zero cases where ad text changes agent instructions. - Sponsored candidate meets all hard constraints in 98%+ of surfaced cases. - Useful-option rate is not materially worse than organic alternatives. - At least three merchants renew or pay after the pilot. - Users do not show a meaningful trust drop versus an organic-only control. Kill or pivot if: - agent platforms refuse external sponsored candidates; - users consistently ask to disable the feature; - merchants will not pay before an auction exists; - attribution cannot distinguish qualified consideration from bot noise; - sponsored candidates are systematically worse than affiliate/organic inventory. ## Competitive reality Existing primitives already solve pieces of the problem: - `schema.org/Product` and `Offer` describe products and commercial terms. - Merchant feeds distribute catalog, price, and availability data. - `llms.txt` is a proposed discovery/documentation convention, not a ranking or advertising standard. - MCP and agent-to-agent protocols can transport tools/messages, but do not create advertiser trust or user-aligned ranking. - Affiliate networks already monetize referrals and may be the fastest supply-side partner. The defensible layer is therefore not “JSON for ads.” It is **verified live offers + policy enforcement + disclosure integrity + agent-quality measurement + conversion reconciliation**. ## The hard truth The biggest risk is distribution, not technology. OpenAI, Google, Microsoft, Apple, Amazon, and browser-agent vendors can build their own sponsored surfaces and may block outside networks. Do not begin by asking them to adopt a new ad format. Begin by making merchant data measurably more useful to any agent, prove user trust and conversion in a narrow category, then sell the resulting verified supply and evaluation layer to platforms. ## References to use during implementation - Schema.org Product: https://schema.org/Product - Schema.org Offer: https://schema.org/Offer - llms.txt proposal: https://llmstxt.org/ - Model Context Protocol: https://modelcontextprotocol.io/ - FTC native advertising guidance: https://www.ftc.gov/business-guidance/resources/native-advertising-guide-businesses - Google Merchant Center product data specification: https://support.google.com/merchants/answer/7052112 Verify any 2025–2026 vendor-specific agentic-commerce announcement against its current primary source before relying on it in investor or customer materials.