Listing AI Agents on Google Cloud Marketplace

A buyer’s procurement team already has a $2M Google Cloud committed-spend agreement, and they want your AI agent to count against it. If your agent is only on a PDF order form, it doesn’t. If it’s a listing on the google cloud ai agent marketplace, it does — and that single fact is why AI-native ISVs are racing to list. But an agent listing behaves unlike the SaaS listings Marketplace was built for. Here is how AI agents actually get listed, priced, and co-sold with Google, and the checks that keep the listing from stalling in review or under-metering once it’s live.

Why AI agents list differently from SaaS

Google Cloud Marketplace was designed around a familiar unit: a SaaS product or a deployable image a buyer subscribes to. An AI agent breaks that mold in three ways. First, it has a runtime identity — it calls models, holds tools, and often acts on the buyer’s data with delegated credentials, which raises security-review questions a static app never triggers. Second, its cost curve is consumption-shaped: an agent that reasons over a long document burns far more than one answering a one-line prompt, so flat seat pricing rarely fits. Third, discovery is changing — buyers increasingly browse for agents as a category, not for a vendor name they already know.

The practical consequence: you can’t just port your existing SaaS listing and rename it “agent.” The packaging, the pricing dimensions, and the review conversation are all different. Teams that treat the agent listing as a cosmetic change discover this in review, when Google asks how the agent authenticates and what it’s permitted to do on the buyer’s behalf. If you’re coming from a broader GCP motion, the Google Cloud Marketplace growth playbook for ISVs covers the fundamentals this post assumes.

Picking a product type: SaaS vs self-hosted agent

The first real decision is how the agent runs. A SaaS agent lives on your infrastructure; the buyer subscribes, and you emit usage records to Marketplace as they consume. A self-hosted agent ships as a Kubernetes application or VM image the buyer deploys into their own Google Cloud project — useful when data residency or in-VPC execution is non-negotiable, but it hands you a harder metering and update story.

Packaging also shapes the security review. A SaaS agent is evaluated largely on how you handle the buyer’s data and credentials on your side. A self-hosted agent gets scrutinized on what it deploys into the buyer’s project and what IAM permissions it requests. Under-scoping IAM is the fast path through review; over-scoping — asking for broad project roles “just in case” — is a reliable way to get sent back. Map the minimum permissions your agent actually needs before you submit.

Pricing an agent: metering the consumption

Seat pricing rarely survives contact with an agent. Consumption varies by an order of magnitude between a light user and a heavy one, so most agent listings meter usage — per token, per task run, or per resolved outcome — often layered on a committed baseline. The catch is that Marketplace meters only what you report. If your usage emitter drops records, that usage is unbilled, and there is no retroactive fix beyond a short reporting window. This is the same failure mode ISVs hit on any usage listing; the pricing guide for AI companies selling on cloud marketplaces goes deeper on picking the metered unit.

A representative split of where AI-native ISVs land on their primary agent pricing dimension — illustrative, not a survey:

Consider a mid-market support-automation ISV that lists a resolution-solving agent as a SaaS product. They price on resolved tickets — a clean outcome unit buyers love — but wire metering to fire only on a “resolved” webhook that occasionally never arrives when a conversation is closed manually. For the first quarter, a slice of real resolutions goes unmetered. The listing looks healthy, buyers are happy, and revenue simply comes in light against forecast with no error anywhere to point at. The fix isn’t a better price — it’s testing that every billable event reliably produces a usage record before launch.

Co-selling the agent with Google

Listing is table stakes; the reason to be on Marketplace is the motion around it. Two mechanics do the heavy lifting. First, committed-spend drawdown: purchases made through your listing draw down the buyer’s existing Google Cloud commitment, which removes budget friction and often collapses procurement from months to days. Second, co-sell: once your agent is listed and you’ve done the partner legwork, Google’s field sellers can bring it into their accounts — but only if they can find it, price it, and trust it.

Earning co-sell attention is a real motion, not a checkbox. It rewards a clean listing, a clear metered price, deal registration hygiene, and a track record of transacting through Marketplace rather than around it. For the full sequence — from listing to attach to field alignment — the 2027 GCP Marketplace seller playbook lays out the steps in order.

Take a typical AI-native ISV that lists its agent, then registers a live deal already in flight so the first transaction runs through Marketplace and draws down the buyer’s commitment. That single clean transaction does more for co-sell credibility than a quarter of partner-portal activity, because it proves the listing is real, the metering works, and the drawdown lands.

Pre-launch checklist for an agent listing

Before you submit — or accept your first offer against a new agent SKU — walk this list. It maps to exactly the failures above.

None of this is exotic, but skipping any line item is how an agent listing quietly under-performs. If you want the deployment-side fundamentals underneath all of this, the GCP Marketplace overview covers the platform, and the marketplace listing checklist tool turns the steps above into something you can actually work through.