AI agent discovery, marketplaces and offers

On this page

Chapter 11 of The Hitchhiker's Guide to the Agentic Economy

Report hub · In this chapter: six discovery gates · market map · AE-JOB-001 · Discovery and Offer Record · Next: commerce protocols and checkout

Our view

An agent cannot choose a supplier safely from visibility alone. Commercial discovery is a funnel through reachability, eligibility, current availability, capability fit and trust. Each gate needs its own evidence. A registry result is a lead until the buyer can identify the provider and version, reach the route, see a bounded offer for the relevant market and understand what happens when delivery is late, wrong or disputed.

The surfaces make different promises: a protocol card describes a skill and endpoint; an app store shows publication or administrative availability; a service marketplace exposes a callable route and payment requirement; a merchant catalogue returns product and shipping context. None of those facts alone proves this buyer can invoke it, that the price is current, that work will be accepted or that a remedy exists.

Key Takeaways

• A public registry, enterprise registry, marketplace, app store and merchant catalogue make different promises; listing count does not make them interchangeable.
• Listing, endpoint, seller and payee identities may differ. Namespace verification establishes control or provenance, not a solvent counterparty or good result.
• Discovery metadata is a dated lead. The live offer, buyer entitlement and terms determine whether that lead is commercially current.
• A count, score, health badge, call metric or promoted placement needs a named denominator. None measures accepted jobs or repeat customers by itself.
• The Commercial Job Record links the candidate and quote to later order, payment, delivery and acceptance records.

This chapter uses specifications, registries, marketplace documentation, terms and public surfaces checked on 13 September 2026. It is a global map with Australian conditions where they change the route. It does not infer demand or adoption from listings, downloads, settlement records or provider-reported counts.

Read this report correctly: Part III is a market map and operating framework, not evidence that agentic commerce is mature or investable. The reviewed sources document available specifications, products, terms and public surfaces. They provide no independent cohort joining active buyers, attempted jobs, accepted work, repeat use, retained revenue and contribution. Until such a cohort exists, the market maps identify what can be tested—not what has won.

Sources and scope

Agentic Economy reviewed three source ledgers containing 128 entries across discovery, commerce/payments and enterprise/services, with overlaps retained where one source supports more than one boundary. The scan prioritised official specifications, first-party product and terms documentation, government or scheme material and dated public surfaces; it is not an exhaustive census of every directory, provider or implementation. Core examples include MCP Registry documentation, A2A discovery guidance and UCP's specification overview.

No account was created, endpoint invoked, quote requested, payment made, output delivered or work accepted. The AE-JOB-001 walkthrough is an illustrative proposed test record, not a live transaction. About Agentic Economy explains the publication; corrections can be submitted through the contact page.

Discovery is becoming its own infrastructure layer

The market is separating into six kinds of discovery surface: public protocol registries, enterprise stores, merchant catalogues, payment-gated service marketplaces, API marketplaces and connector directories. They appear similar because each publishes a list. They differ in who controls admission, what can be discovered and whether the listing carries identity, availability, pricing or transaction state.

Enterprise platforms such as Microsoft distribute agents inside existing tenant, identity and administration boundaries. Shopify and Google are exposing merchant catalogues to purchasing agents. RapidAPI and Apify combine discovery with plans or usage pricing. Bazaar links machine-readable resources to x402 payment requirements. Glama, Smithery and PulseMCP organise the expanding MCP ecosystem.

Stripe describes the emerging interface shift directly: “interfaces like ChatGPT are quickly becoming a new kind of storefront” (Stripe, "Instant Checkout in ChatGPT"). That statement reveals where commerce platforms are investing: turning conversational discovery into a merchant-controlled transaction route. It does not establish that agent storefronts have displaced search, marketplaces or direct supplier relationships.

Our view is that discovery will remain plural. Enterprise stores, merchant catalogues and developer registries serve different markets, and none currently provides a universal route from finding a capability to receiving accepted work and commercial recourse.

Discovery is six gates, not one search result

The market has six gates between a listing and an actionable capability: visibility, reachability, eligibility, current availability, commercial fit and sufficient trust. Every pass and unknown changes the status of the candidate.

Agent registry is a metadata surface for finding agent or service records. Marketplace is a commercial surface that can add offers, plans, checkout or payouts around listings. Capability card is a machine-readable description of an agent or service interface. Actionable offer means a current, bounded proposition that this buyer can evaluate and carry into authority, order and remedy decisions.

1. Visible: does a record exist?

The first gate is publication. A search result, server.json, Agent Card, UCP profile, app-store entry or marketplace page tells the buyer that some source has a record; it does not establish that the index is complete, current or intended for this buyer. The MCP Registry points to public packages or remote locations, A2A Agent Cards publish provider and skill metadata, and ARD describes provider catalogs and registry crawling. All three are publication evidence.

2. Reachable: can this buyer reach the declared route?

Reachability means more than a syntactically valid URL. The endpoint, package or channel must resolve for this buyer with the needed protocol, authentication, network and rate limit. The Google Agent Registry and Gemini Enterprise A2A guide separate discovery permission from invocation permission. A public page cannot substitute for a buyer-specific reachability check.

3. Eligible: may this buyer use it here?

Eligibility includes plan, role, workspace, model, tenant, region, market, network, asset, KYC, shipping country and data-use restrictions. Shopify's UCP catalog exposes conditions such as ships_to and available; Google's Merchant Center UCP guide described a pilot whose product checkout was US-only at the checked date. Microsoft's regional availability includes Australia, but that does not make every Store agent available to every Australian tenant.

4. Available: is this version and route current?

Freshness is a policy, not a decorative timestamp. The relevant record includes the publisher's update, last test, version, stale threshold and removal or deprecation rule. Aggregators may scrape periodically (MCP guidance); Glama describes rescans but disclaims timeliness (methodology, terms); RapidAPI versions can be deprecated while existing subscribers retain them (versioning); Bazaar documents its own validation and removal rules (CDP). Each clock is local. There is no universal freshness clock.

5. Commercially suitable: does the capability and offer fit the job?

Capability fit asks whether inputs, outputs, constraints, data coverage, permissions and errors match the work. Commercial fit asks for the unit, currency, maximum exposure, quota, renewal/expiry, fees and acceptance boundary. MCP/A2A schemas make inputs legible but do not guarantee quality. Shopify, RapidAPI, Apify and Bazaar show offer-shaped metadata, not necessarily a fresh buyer-specific quote, taxes, service level or remedy.

6. Sufficiently trusted: who stands behind the result?

Trust is operational and commercial, not a badge. It consists of provenance, an accountable counterparty, terms, support, response time, acceptance and remedy. The namespace owner may differ from the payee, and a marketplace may not be party to the service contract. Apify's terms make the creator-user contract direct; RapidAPI's finance rules describe refunds, disputes and a 25% Hub fee; OpenAI's terms place external checkout responsibility with the developer. Failure ownership follows those relationships rather than the discovery surface alone.

The gates are cumulative. A provider can be visible, reachable and eligible while still being unpriced or unable to state what counts as delivery. The correct state is then “candidate with unknown offer”, not “buyable”.

Funnel state	State event to record	Evidence source at this stage	What this state does not prove
Listed	A registry, store, catalogue or marketplace returns a named result	Source URL, listing ID, publisher and checked timestamp	Complete indexing, demand, buyer visibility or current publication
Reachable	The declared endpoint, card, package or channel resolves for the intended buyer and protocol	Non-destructive probe, provider status, authenticated route or platform test	Safe behaviour, capability correctness, entitlement or service quality
Eligible	Plan, role, tenant, market, network/asset, KYC or shipping context passes	Buyer-context check, IAM decision, catalogue filter or documented eligibility rule	Legal permission, procurement approval, inventory guarantee or cross-border compliance
Quoted	A current bounded price or plan is returned for the job and buyer context	Quote/plan response with currency, unit, limits, fees, expiry and terms reference	Order, payment authorisation, acceptance or remedy unless those are explicit
Ordered	The buyer authorises an offer and the supplier or merchant acknowledges an order	Order/mandate record owned by the Chapter 12 lifecycle	Settlement, delivery or a successful business outcome
Delivered	An output, artefact or product-delivery event is supplied	Delivery receipt, artefact reference or provider fulfilment event	Completeness, correctness, acceptance, invoice reconciliation or repeat use
Accepted	The responsible buyer or system judges the result against the agreed criterion	Acceptance record, rejection/rework decision and evidence reference	General quality, market demand or future repeat orders
Repeated	A later accepted job links to the same buyer, offer and provider relationship	Job and customer denominator with repeat interval and outcome	A listing count, call count, settlement or popularity score standing in for demand

This table sits beside the figure so the visual cannot be mistaken for a conversion chart. The funnel is a control model, not a measured market rate. Payment initiation and settlement sit between order and delivery in the wider Commercial Job Record and are owned by Chapters 12 and 13.

What discovery surfaces actually do

The reviewed sources show overlapping discovery surfaces; this scan does not establish one complete global agent-services directory. This dated table is a functional map, not a ranking. “Buyer” and “supplier” identify the main roles; neither implies a transaction.

Surface	Buyer and supplier	What it exposes or checks	Business model, geography and maturity	Strongest evidence and material gap
Public protocol registry	Builders discover public MCP/A2A capabilities; publishers control the package or endpoint	server.json, Agent Cards and ARD catalogs expose names, URLs, auth, skills and schemas.	Open publication and downstream aggregation; ARD remains evolving.	MCP, A2A, ARD. No shared price, eligibility, acceptance or remedy schema.
Enterprise registry or app store	Administrators and platform users discover agents/apps; internal, partner and external publishers supply them	Google and Microsoft expose identity, capabilities, channels and admin states; OpenAI exposes app metadata and plan/region/workspace controls.	Tenant, role, plan, model and region gated; review and removal are platform-specific.	Google, Microsoft, OpenAI terms. Publication does not prove invocation, offer, eligibility or support.
Merchant catalogue	A shopper's agent searches products; merchants supply price, variants, availability and policies	UCP profiles advertise capabilities/endpoints. Shopify documents catalogues, ships_to, available and product context; Google adds checkout-eligibility flags for participating US merchants.	Product catalogue and referral/checkout economics; rollout limits matter. Shopify's invite-led Developer Preview documents a base 0.3% last-click attributed-purchase commission with disclosure.	UCP, Shopify, placement. A product record is not an accepted order or inventory guarantee; paid rank is not quality evidence.
Payment-gated service marketplace	Builders or buyers search callable resources; service publishers supply endpoints and payment terms	Bazaar filters network, asset, scheme, pay-to, URL and max USD; CDP documents HTTPS/402/metadata/facilitator validation, health ranking and removal. Apify exposes Actors, usage prices, caps and selected payment adapters.	Per-call or usage models with network, wallet, KYC and eligibility constraints. CDP reports >23,000 resources, a dynamic publisher count, not demand.	Bazaar, seller rules, Apify x402. No generic accepted-output or cross-border remedy is stated.
API marketplace	Developers and businesses subscribe to APIs; providers publish plans and receive payouts	RapidAPI exposes popularity, latency, success metrics and Free/Paid/Freemium plans; providers can require approval, disable plans or deprecate versions.	Subscription, pay-per-use and tiered plans with account, quota and overage rules; RapidAPI documents a 25% Hub fee before PayPal fees.	Plans, consumer guide, finance. Platform metrics are not independent quality or accepted-work evidence.
Connector aggregator and directory	Builders search a broader catalogue; aggregators ingest or test submissions; providers remain responsible for the route	Glama describes scans, drift/history and healthy-only search. Smithery and PulseMCP expose labels, scores or counts.	Advertising, hosted connector and curation models vary; records may be scraped, retained or paused. PulseMCP displayed “1–42 of 21,932” while changes were paused.	Glama, terms, PulseMCP, Smithery. Health, score and count do not prove authorisation, delivery, demand or recourse.

Three differences matter: the registry or aggregator may not operate the endpoint; a card may describe a skill without a price, while a plan may price a call without an acceptance test; and remedy is usually outside discovery. The supplier, platform and payment provider can allocate responsibility differently.

A listing is not an offer

An agent needs a chain of identities and states, not a single URL:

discovery source and listing ID
  -> provider namespace and declared version
  -> endpoint/package/channel identity
  -> seller or merchant identity
  -> buyer eligibility and current offer
  -> order and payment references
  -> delivered artefact or product
  -> acceptance, remedy and repeat relationship

The source alias is useful for navigation; the endpoint or package is what the agent reaches; the seller or merchant promises the work; and the payee receives money. These can differ. A verified reverse-DNS name or GitHub organisation shows namespace control, not a legal entity, solvency, data obligations or willingness to correct failure.

The live offer owns current commercial facts. A complete quote references the exact endpoint/version, check time, buyer context, price unit, currency, maximum exposure, quota, fees, expiry, renewal, tax treatment and terms version. Missing values remain not established; an old cached price cannot populate a new quote.

Reputation signals need the same discipline. RapidAPI success figures, Bazaar calls/unique payers/lastCalledAt, Glama's “Healthy” and “Last Tested”, and a Microsoft live-channel state are platform observations. Shopify's promoted placement is paid and disclosed; an OpenAI directory section shows placement. None is a portable prediction of accepted work.

Every count needs its denominator. “More than 23,000 resources” is a publisher's dynamic resource count; “21,932 servers” was an observed directory display while ingestion changes were paused. Neither means suppliers were reachable by Australian buyers, quoted, accepted or repeated. The rule applies equally to downloads, calls, unique payers, reviews, scores and featured placement.

AE-JOB-001: find a competitor-briefing supplier

The following is an illustrative proposed test record, not a supplier recommendation and not a live transaction.

Job. A Perth advisory firm wants one sourced competitor briefing covering five named competitors and up to ten approved public sources, delivered within one business day after a complete brief and reviewed by an analyst. The first job may become a weekly service only after delivery, acceptance and reconciliation. The team wants a repeatable service boundary, not an unbounded instruction to “find data”.

Proposed acceptance boundary. The buyer specifies the competitor set, URL scope, retrieval week and timezone. Each row needs its source page, value, currency/unit and retrieval time; “not found” and ambiguity are valid, invented values are not. A human reviews a sample. These are AE proposals, not provider promises.

The candidate set

The agent could search several illustrative source types for a capability that retrieves public pages and returns structured records. These named examples are not a provider shortlist, recommendation or tested route:

1. An Apify Actor may expose usage pricing, examples, support and an agentic adapter. Eligibility, data-use limits, creator identity and output quality remain separate fields. Its x402 integration describes a capped prepaid USDC token with 14-day expiry and non-refundable unused balance; that is not evidence this job was run or accepted.
2. An x402 Bazaar resource may expose an HTTPS endpoint, 402 requirements, schema and platform fields. No call or payment was made here, so it remains documented supply until an authorised route check.
3. A RapidAPI plan may show quota, price, latency and success metrics. An account and plan are required; overage, deprecation and the Hub fee affect comparison.

This is not a ranking. A known research supplier may enter through a direct relationship rather than a discovery surface. The differentiator is whether the candidate can state the promised work and remedy.

The funnel in practice

Listed. The record carries source, listing ID, publisher, endpoint/package, protocol and checked timestamp. A missing price is unknown, not a rejection; paid placement is not quality evidence.

Reachable. The endpoint/package resolves and its input/output surface is visible. A non-destructive check can confirm protocol response or a documented payment challenge, not extraction quality or delivery. Account-gated routes also carry the buyer's plan and permitted test route.

Eligible. Australian buyer access, public URLs, network/asset or account, and data-use constraints determine this state. A country list is a condition, not proof this account is enabled; KYC, tenant, wallet and region requirements stay visible.

Quoted. A current plan for one brief carries price unit/currency, maximum spend, page or runtime cap, overage, expiry, renewal, commission, tax and terms. A per-call payment requirement is not the job's total quote. A candidate can be reachable and eligible while not quoted.

Rejected stale candidate. Suppose a public connector page displayed “Healthy” and “Last Tested: 14 August 2026” when checked on 13 September. With a seven-day threshold, reject it for quoting until a fresh check. This rejects stale evidence, not the endpoint; without the reason, an agent may commit money or data to a changed route.

Ordered, delivered, accepted and repeated. These stay blank here. Chapter 12 owns order; Chapter 13 owns payment and settlement; later records own delivery, acceptance, remedy and repeat use. A payment success response does not fill them.

Requesting a quote and accepting one are different gates. A non-binding quote needs enough identity, route and buyer eligibility to approach the candidate without creating an obligation or disclosing sensitive data. Acceptance or credential presentation adds a current bounded offer, maximum exposure, terms, acceptance and remedy evidence appropriate to the job's consequence. Without those fields, the lead remains open with a named next check.

The Discovery and Offer Record

Each material candidate and quote receives its own record. For AE-JOB-001, the proposed ID is AE-JOB-001-DISC-001. It owns discovery through quoted; later chapters append order, payment, delivery, acceptance and reconciliation references without overwriting discovery evidence.

Field group	Commercial record
Identity	Provider legal/display name if disclosed; discovery surface; namespace/listing ID; endpoint/package/channel; protocol; version; source URL; checked timestamp; publisher and payee relationship if known
Capability	Job purpose; inputs and outputs; schema/examples; source coverage; data and tool permissions; errors and limits; expected artefact; acceptance dependency
Freshness	Publisher published/updated; last tested, health or settlement fields; source of the check; stale threshold; deprecation/removal rule; observed status
Offer	Quote or plan; price unit, amount and currency; maximum spend; quota/overage; platform fee or commission; renewal/expiry; taxes and required fees, or explicit unknowns
Eligibility and geography	Buyer plan/role/IAM; countries/markets; address or ships_to context; network/asset; KYC; data/use restrictions; evidence that this buyer passes or remains unknown
Terms and remedy	Legal counterparty; terms/contract URL and version; support route and response window; cancellation/refund; dispute or appeal route; delivery and acceptance criterion; evidence-retention rule
Reputation	Signal type: health, calls, unique payers, score, reviews, popularity or paid placement; signal owner; measurement window; denominator; independent corroboration; paid label
Decision and links	Gate state; unresolved risks; next non-destructive check; approver; discovery decision rationale; future order/payment/delivery/acceptance IDs intentionally blank until those events occur

Each field carries its source, checked date and current status. A missing price is not zero; absent geography is not global; an untested endpoint is not verified; a call count is not an accepted-job denominator.

Provenance and selection are different facts. The URL shows what a publisher declared; the selection record shows whether it sufficed for this job, date and authority. An aggregator that retains a deleted record needs a visible retention rule or the market will misread history as current supply.

Every funnel stage retains its denominator

The funnel is useful for operating a route and dangerous for market-size claims. Count each transition against the population that could make it, and identify who observed it.

Measure	Defensible denominator	What can be said	What cannot be inferred
Listed	Records returned by a named index at a named time	This surface displayed this many records	Global supply, completeness or demand
Reachable	Listed records tested from a named network/auth context	This probe reached this version under these conditions	General uptime, safe behaviour or buyer-wide access
Eligible	Reachable candidates assessed for one buyer, plan, region or network	This buyer passed or remained unknown for this subset	Universal geographic or legal eligibility
Quoted	Eligible candidates for which a current quote was requested/returned	These candidates exposed a bounded offer for this job	Order intent, payment, delivery or value for money
Ordered	Quoted offers actually authorised and acknowledged	These orders were formed under the recorded authority	Settlement, delivery or acceptance
Delivered	Orders with an attached output or fulfilment event	These jobs produced a deliverable	Correctness, buyer acceptance or repeat use
Accepted	Delivered jobs judged against the stated acceptance test	These jobs met the agreed result	Broader market demand or profitability
Repeated	Buyers with a later accepted job in a defined period	This cohort repeated under this definition	A universal retention rate without the cohort and period

The reviewed sources do not publish a cross-marketplace denominator joining these states. Bazaar calls or unique payers, RapidAPI popularity or success, Apify supply, aggregator counts and store placement are useful fields, not accepted-job records. Economic comparison requires the numerator, denominator, period, population and source.

What the market has not resolved

No discovery surface currently joins supplier identity, live availability, buyer eligibility, a current commercial offer, delivery evidence and remedy across the whole market. Each category stops at a different boundary. Enterprise stores know more about the buyer. Merchant catalogues know more about the product and checkout. Developer registries know more about technical interfaces. Payment-gated directories know more about the immediate transaction.

We expect those surfaces to connect rather than collapse. Discovery metadata will become easier to exchange, while eligibility, ranking, contracting and recourse remain attached to the platform or commercial network that owns the relationship.

What the sources establish

The source set establishes a substantial and varied supply of discovery mechanisms:

• protocol registries and cards can publish identity, endpoint, capability and schema metadata;
• enterprise registries and app stores can add tenant, role, publication, channel, review or administrator controls;
• merchant catalogues can expose product, price, availability and market context;
• service and API marketplaces can expose callable routes, plans, payment requirements, limits and platform metrics; and
• some operators describe freshness checks, ranking, deprecation, support and removal policies.

The evidence does not establish that any one surface is complete, that a listed provider is currently reachable from an Australian buyer, that a health or quality signal predicts accepted output, or that any directory has agent-mediated demand at scale. No source reviewed supplies a portable record joining identity, current offer, buyer entitlement, legal counterparty, accepted delivery and remedy across surfaces.

The chapter also does not decide Australian tax, privacy, consumer, employment, data-transfer or sector obligations. A discovery record can expose geography, data restrictions and terms for review; it cannot certify compliance. Product checkout guidance that is US-only cannot be generalised to Australian service availability. AE's initial platform remains pre-launch, so this chapter does not claim that Agentic Economy operates a global registry, enables production purchases or has tested a listed route.

Unresolved market questions

Six market developments would materially change this category:

1. How quickly do provider changes, endpoint failures, deprecations and deletions reach each downstream index? Can a buyer see both the source timestamp and propagation latency?
2. Can a service marketplace return a buyer-specific quote with taxes, fees, maximum exposure, acceptance and remedy before a payment credential is presented?
3. How should an agent compare a public card, a tenant-gated app and a paid marketplace plan without treating private eligibility as a missing technical detail?
4. Which independent records join listing exposure to quote, order, delivered work, acceptance, rework and repeat use? What population and period make the result meaningful?
5. When a marketplace, provider and payment rail disagree about a failed call, which party must preserve evidence and provide correction or refund?
6. Which version and path of evolving discovery specifications should a buyer pin? The dated ARD announcement used ai-catalog.json, while the current project publication guide uses /.well-known/ard.json; that path drift is itself a record field.

The category would move from fragmented discovery towards portable commercial infrastructure if:

1. Independent tests show a cross-provider Discovery and Offer Record that joins identity, version, reachability, capability, buyer eligibility, current price, terms, acceptance and remedy, with measured conversion and failure outcomes.
2. An interoperable revocation and freshness mechanism propagates stale or deleted listings with measured latency and independently assessed completeness.
3. Public accepted-job records provide a reliable denominator linking listings to quotes, orders, delivery and repeat use across more than one surface.
4. Multiple registries and marketplaces implement a portable offer/terms/remedy schema and honour it in disputes.
5. Independent tests show that health, quality or ranking signals predict accepted output rather than calls, settlement, popularity, paid placement or metadata completeness.
6. Buyer-specific geography, authorisation and legal-counterparty data can be checked without private-tenant context and remains current through offer formation.

These would not make a directory a substitute for a contract. They would show that the discovery seam is becoming a verified, portable part of the commercial relationship rather than a set of disconnected leads.

Conclusion

Discovery is becoming the first commercial infrastructure layer in the agentic economy. A result moves from listed to reachable, eligible, current, commercially suitable and sufficiently trusted before it becomes a usable offer. Order, payment, delivery, acceptance and repeat states still belong to later systems; a listing does not pre-fill them.

The current market supplies useful pieces. MCP and A2A cards make capabilities legible. Enterprise registries and app stores add administrative gates. UCP and merchant catalogues add product and context fields. x402 Bazaar, Apify and API marketplaces expose service routes, price or payment metadata. Aggregators add search and testing signals. Their operators retain different definitions of freshness, health, eligibility, fees and remedy.

The durable market object is a dated Discovery and Offer Record linked to the Commercial Job Record. It shows who published the result, what was checked, what remains unknown, the permitted spend and the owner of a failed outcome. That record will matter more than another unsourced directory count because it can travel into order, payment and acceptance.

About the author and editorial record

Agentic Economy is the accountable publisher of this report. Joel Chan founded the publication in Perth to research the infrastructure, companies and operating choices shaping the agentic economy. This chapter is source-led market analysis, not a sponsored ranking or proof that every listed product has been independently tested. Primary sources were checked on 13 September 2026; dynamic counts, publisher metrics and observed UI states retain that date and their stated limits.

Back to the report hub · Next: commerce protocols and checkout