The Marketplace Becomes the Deal Registration

On April 9, 2026, AWS Marketplace turned on a Discovery API that gives buyers and their own tools programmatic access to product descriptions, categories, and pricing, public and private offer terms both, across the entire catalog. Five months earlier, ahead of re:Invent, AWS had already added Agent Mode, a conversational interface that takes a buyer's requirements document and returns product comparisons and a downloadable proposal, built on a Model Context Protocol server for discovery. Between the two, a listing on AWS Marketplace can now be found, compared, and priced without a person opening a browser or a seller answering a phone.

That is a bigger change than it looks like from the vendor's side. A marketplace listing used to be marketing copy: a page built for a person to read and a salesperson to walk through. When the listing becomes queryable data and the private offer becomes a set of terms an API can return, the listing stops being a lead magnet and starts looking like the deal itself. Procurement agents are built to compare, evaluate, and eventually transact against exactly that kind of data. What used to require a person to click "request a quote" is becoming a call a piece of software can make on its own.

The marketplace becomes the deal registration

Deal registration exists because a vendor cannot otherwise see who actually influenced a sale that closes somewhere the vendor doesn't control. A partner submits an opportunity into the vendor's system before a competitor or the vendor's own sales team touches it, in exchange for protected pricing, and that submission is the vendor's only proof the partner did anything at all.

A marketplace transaction removes the reason that proof is needed. When a buying agent finds a listing, reads its terms, and completes the purchase entirely inside the marketplace, there is no "somewhere else" the vendor can't see. The listing, the offer, and the close all happen on one platform, timestamped and attributable by construction. The transaction record already answers the question deal registration exists to answer: who put this offer in front of the buyer, on what terms, and when. A separate registration step becomes paperwork for a deal that already carries its own audit trail.

This is the same dispute Episode 7 examined, one layer earlier. An agent-sourced deal raised a crediting argument there because the sourcing happened outside any system that could prove it happened at all. A marketplace transaction removes that ambiguity structurally: discovery, negotiation, and close run on one auditable rail instead of being stitched together across a seller's CRM, a partner's outreach, and a vendor's pipeline. That only holds, though, if the marketplace itself is actually built to carry the whole loop. Most of them aren't yet.

What six marketplaces look like to a buying agent

We read six major marketplaces the way a buying agent would: not the storefront a person sees, but what is actually available as data. One clears the bar outright.

AWS Marketplace's new Discovery API, combined with the private-offer APIs AWS has documented for longer, lets a program or its agent search the catalog, read both public and private-offer terms, and drive a private-offer negotiation, all as API calls, with no browser required. That AWS leads this list again is becoming a pattern worth naming on its own: the same company built the enablement interface Episode 6 found nobody else had matched, and it has now done the equivalent for the transaction itself.

A second tier gets partway there, each missing a different half of the problem. Azure Marketplace's tools in the Azure MCP server let an agent search products, read pricing plans, and compare SKUs, explicitly documented as read-only and idempotent: the same server that can tell an agent what something costs cannot let that agent buy it, a deliberate stop one step short of the transaction. Snowflake Marketplace takes the opposite half. New listings can now generate their own conversational data agent automatically, so a buyer's agent can query the data inside a listing in natural language the moment it's shared. What that exposes is the product inside a listing. The commercial terms of buying access to it stay as unstructured as everywhere else.

The remaining three still require a person to find out what something costs. Google Cloud Marketplace has a Partner Procurement API, but it is built for the seller side, so a partner's own AI-agent product can report signups and usage back to Google; it is not a catalog a buyer's agent can browse. Salesforce's AgentExchange, a marketplace for agentic components launched in March 2025, has no published catalog API; discovery happens on the AgentExchange website or inside Salesforce's own Agent Builder, both built for a person. A marketplace named and built for agents currently has no way for an agent that isn't Salesforce's own to read what's on the shelf. HubSpot's App Marketplace has the same gap, filled the same way Episode 6 found partner-enablement content getting filled: a small industry of third-party scrapers built to work around an API that doesn't exist.

What "partner preference" means when the reader is an agent

The first cut a buying agent makes is visibility, and it happens before preference ever enters the picture. A listing that only exists as a web page is invisible to an agent before any comparison happens, whatever its actual merits. Google Cloud Marketplace, AgentExchange, and HubSpot's marketplace aren't losing on price or quality right now; they aren't in the running at all for a buyer whose agent only reads structured data.

Among listings an agent can actually see, preference becomes a question of which signals are available as fields rather than paragraphs. Certifications and compliance attestations that currently live in a badge image or a PDF need to exist as structured, verifiable data. Service-level terms need to exist as published values that a field can hold, the kind a comparison engine can actually read. Review counts, verified customer outcomes, and response time on a private-offer request all become comparable the moment they're structured, and invisible the moment they aren't. This mirrors a discipline already forming in consumer search, often called answer engine optimization: making a page legible to the system doing the choosing as much as to the person eventually reading the result. For a partner marketplace listing, the job is the same. Differentiation that only exists as prose an agent can't parse isn't differentiation to that agent. It's noise.

The private offer, machine-negotiated

AWS's private-offer APIs already let a seller programmatically create and modify a custom offer for a specific buyer account, though a person behind the scenes usually still triggers that today. The next step, an agent both requesting and accepting a private offer within limits its owner pre-authorized, needs two things that currently sit in different companies' roadmaps: a catalog layer that exposes eligibility terms as data, which AWS is furthest along on, and a payment-authorization layer that can prove an agent had real permission to commit real money. Google's Agent Payments Protocol, built around cryptographically signed "mandates" that record a buyer's intent and then lock in an exact cart before payment, is the clearest answer so far to that second half. Google's own announcement names autonomous marketplace procurement as a use case for it. A year later, Google Cloud Marketplace's own procurement API still doesn't do that. The two halves of a machine-negotiated private offer, what it costs and who's allowed to say yes, are being built by different companies solving different problems, and neither is complete on its own yet.

The case against it, and where it holds

Three objections come up whenever this argument gets tested against how a real partner team actually sells, and each holds a real mechanism worth answering.

Commoditization is the first. An agent that mainly compares structured price and spec fields flattens years of relationship-based differentiation into something that looks like a spec sheet, pushing every category toward the lowest number. The fix is moving the actual differentiators, certification depth, verified outcomes, SLA terms, into fields an agent can weigh. A preference an agent can't see isn't preference. It's a story that never reaches the buyer that matters now.

Margin erosion is the second. A machine-negotiated private offer, requested by an agent instructed simply to find the lowest number, could pressure negotiated margin across an entire category faster than any human buyer ever could. The answer is the same gating logic Episode 7 recommended for sourcing credit: tie private-offer eligibility to qualifying conditions, a volume commitment, a contract length, an account tier, encoded as machine-readable terms, rather than leaving price as the only lever an agent has to pull.

Liability is the third, and the one worth taking most seriously, because real money is now changing hands. If a buying agent transacts against stale or misread pricing data, responsibility hasn't been settled anywhere in this industry yet: not for the marketplace platform, not for the seller, not for the buyer's own agent operator. The practical answer is the same discipline Episode 6 recommended for enablement content, version and timestamp every machine-readable offer field, extended now to terms that carry real financial commitment.

The Operator Move: score your own listing through an agent's eyes

Twenty minutes. Pull up your own top marketplace listing and answer four questions honestly.

1. Can an AI agent find your listing's public price and specs as structured data without a person logging in first, or does someone have to read a page before they know anything?
2. If a buyer's agent qualifies for a private offer, can it read the eligibility terms and pricing programmatically, or does it still take a phone call to your team?
3. Does your listing expose the signals that actually differentiate you, certifications, SLAs, verified outcomes, as structured fields an agent could compare, or only as prose on the page?
4. If a competitor's listing were more machine-readable than yours today, would you have any way of knowing?

Two or more uncertain answers means a competitor whose listing an agent can actually read is starting from a real advantage, one that compounds every time a buyer's agent runs the comparison instead of a person.