From Laptop to Marketplace: How to Publish an AI Agent on Google Cloud

Prepare a Working Agent for Marketplace

This guide is for the point after the demo. Your agent already does something useful, and now you want a customer to discover it through Google Cloud Marketplace and use it in a real environment. You do not need Marketplace experience, but basic familiarity with APIs, Google Cloud projects, and application deployment will help.

Start with one agent and follow what changes

We will use one example all the way through: Cloud Change Review Agent. A user gives it a proposed Google Cloud change — perhaps a GKE deployment or Terraform plan — and the agent explains the security, reliability, and cost risks before the change reaches production.

On your laptop, that is enough: start the agent, send a request, get an answer. A Marketplace customer needs more. The agent needs a reliable home, a standard way to describe itself, a purchase flow, a way for your backend to know who bought it, and a secure way for approved users to call it.

Understand Each Marketplace Component

Several services participate in a Marketplace purchase. The following breakdown explains what each component handles so you can map it to your implementation.

Two choices come first: how you sell it and where it runs

This is the first place new publishers often get confused because “deployment” can refer to two different decisions.

Decision 1 — What are customers buying?

This guide follows the AI Agent as a Service using A2A path because that is the Marketplace path in the source designed for agents that integrate with Gemini Enterprise. The other product types are still valid when they match a different business model.

Decision 2 — Where does the hosted agent actually run?

Trace the Purchase and Access Flow

Before touching Producer Portal, look at the end-to-end picture. The customer, Marketplace, your purchase-handling backend, the agent runtime, authentication, and the customer’s Gemini Enterprise environment all have different jobs.

The official diagram may look busy on the first pass. That is fine. For now, keep the simple path in mind: customer buys → Marketplace records the purchase → your backend receives the change → access is provisioned → the customer can use the agent.

Do the engineering and seller setup in parallel

Run two workstreams in parallel: prepare the agent for production, and complete your organization’s Marketplace seller setup.

Step 1 — Give the agent a stable production home

For our example, we will use Cloud Run because the idea is easy to follow: package the agent, deploy it as a service, and give it a stable HTTPS endpoint.

That fits a request-driven agent well. The source also notes that Cloud Run has different resource types for different execution patterns, so the important point is to choose the runtime shape that matches how your agent actually works.

What you should have at the end of this step

https://your-agent-service.example.com

or

https://YOUR_CLOUD_RUN_SERVICE_URL

At this stage, the URL is not the Marketplace product. It is simply the reliable address that the rest of the onboarding will point to.

Step 2 — Give the agent a standard way to talk to other agents

Think of A2A as the public conversation contract for your agent. Your internal implementation can use ADK, LangGraph, custom code, or another framework. A2A gives the outside world a consistent way to understand and interact with the agent.

If MCP is also part of your design, that is not a conflict. The two protocols answer different questions:

Step 3 — Create the Agent Card: your agent’s machine-readable introduction

If A2A is the conversation protocol, the Agent Card is the introduction that tells a client who this agent is and how to work with it.

• the agent’s name and description;
• the A2A protocol version;
• the endpoint to call;
• which transport it supports;
• which organization provides it;
• what the agent can do;
• which skills it exposes;
• which input/output modes it supports;
• and how authentication should work.

For Marketplace A2A agents, the source requires an Agent Card aligned to the A2A specification. You store that JSON file in Cloud Storage and select it later from Producer Portal.

{
  "name": "Cloud Change Review Agent",
  "protocolVersion": "1.0",
  "description": "Reviews proposed cloud changes and summarizes deployment risk.",
  "url": "https://agent.example.com",
  "preferredTransport": "JSONRPC",
  "provider": {
    "organization": "Example Partner",
    "url": "https://example.com"
  },
  "version": "1.0.0",
  "capabilities": {
    "streaming": false,
    "pushNotifications": false
  },
  "defaultInputModes": ["application/json"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "review_cloud_change",
      "name": "Review cloud change",
      "description": "Analyzes a proposed cloud change for security, reliability and deployment risk.",
      "tags": ["cloud", "risk", "deployment"],
      "examples": [
        "Review this GKE deployment before production."
      ]
    }
  ]
}

Describe capabilities, not slogans

A vague skill such as “helps with cloud” tells another system almost nothing. A skill such as “reviews a Terraform plan for security, reliability, and cost risks” gives an orchestrator a clear reason to call the agent.

Step 4 — Store the Agent Card where Marketplace can read it

The Marketplace flow in the source expects the Agent Card JSON in a Cloud Storage bucket in the same project used for the Marketplace product.

gcloud storage buckets create gs://YOUR_AGENT_CARD_BUCKET \
  --location=us-central1

gcloud storage cp agent-card.json \
  gs://YOUR_AGENT_CARD_BUCKET/agent-card.json

Keep the source version in version control and treat updates carefully. The Agent Card is part of the product contract that other systems use to understand your agent.

Step 5 — Create the product in Producer Portal

Producer Portal is where the listing, Agent Card, pricing, and technical integration come together. Your organization first needs the required Marketplace vendor onboarding and Project Info Form completed.

Google recommends using a project mainly for Marketplace products. Once you have access, the creation flow is straightforward:

1. Open Producer Portal in the Marketplace project.
2. Select Add product.
3. Choose AI agent as a service.
4. Enter the product name.
5. Review the generated Product/Solution ID carefully.
6. Create the product.

Step 6 — Let Producer Portal check the Agent Card

Inside the product, open the Agent Card section, select the JSON file from Cloud Storage, and choose Save and validate.

Marketplace will point out missing or unclear information. Use that feedback to tighten the card instead of treating validation as a box to tick.

The source specifically calls out details such as skills, competence, models, and security. The clearer those are, the easier it is for both systems and customers to understand what they are dealing with.

Step 7 — Explain the product to the person who might buy it

The Agent Card explains the agent to machines. The Marketplace listing explains it to people.

Your title, icon, description, documentation, support links, categories, industry, and business-function metadata should answer the questions a buyer will actually have:

• What business problem does this agent solve?
• What systems or data does it need?
• What exactly will it do?
• What will it not do?
• How is it secured?
• How is it supported?
• How is it priced?

Avoid phrases such as “AI-powered enterprise automation platform” unless they are followed by something concrete. “Reviews proposed GKE and Terraform changes before production and returns security, reliability, and cost risks” tells the buyer what the product actually does.

Step 8 — Choose a Pricing Model You Can Support

For A2A AI agents, the source documents four core pricing choices.

Pricing review can take up to four business days, so it makes sense to submit pricing while the technical integration work continues.

What can “usage” mean for an agent?

Usage does not have to mean model tokens. It can be a business event that customers understand:

• reports generated;
• tickets resolved;
• documents processed;
• deployments reviewed;
• anomalies detected;
• workflows completed.

Whatever you charge for must also be something your backend can count consistently. If the product is priced “per deployment review,” engineering needs one unambiguous definition of what counts as a deployment review.

Step 9 — Make your backend react when the customer buys

Your backend must respond to the purchase by provisioning the access included in the customer’s plan.

Pub/Sub tells your backend that something changed

Your Partner Engineer creates the Pub/Sub topic used for Marketplace lifecycle events. Your backend subscribes so it knows when a customer purchases, changes, or cancels the product.

Partner Procurement API tells you what the customer is entitled to

The Partner Procurement API connects your own customer record to the Marketplace purchase. The source notes that access to this API is enabled through your Partner Engineer rather than simply switched on in the console.

Usage pricing adds one more responsibility: metering

If pricing depends on usage, a trusted part of your system also has to count the agreed metric and report it through the required billing integration.

Step 10 — Payment and identity are two different checks

A customer can have a valid subscription and still send an unauthenticated request. Those are two separate questions.

For Gemini Enterprise integration, the source discusses public access or OAuth 2.0 Authorization Code Grant. For a typical enterprise product, you should expect to design real authentication rather than simply leave the agent anonymously reachable.

If you use Dynamic Client Registration, the Agent Card can advertise the registration information needed for Gemini Enterprise to establish the OAuth client relationship.

Step 11 — Test the purchase journey, not only the agent

Your agent endpoint can be perfectly healthy while the Marketplace product is still broken. The real test starts before purchase and ends only after access, plan changes, cancellation, authentication, and troubleshooting all behave correctly.

Step 12 — Complete the reviews, then publish

Producer Portal separates the product into several review areas. According to the source, you need:

• Product details review;
• Pricing review;
• Technical integration review;
• Agent Card validation.

Product details and pricing can be submitted in either order, but pricing must finish review before the technical integration review is submitted.

Once the required reviews are successful, the agent goes through Marketplace validation and testing. After validation, Google provides the process or command used to make the listing public.

What the customer sees after the purchase

Once the listing is public, an enterprise buyer can discover and procure the agent through Google Cloud Marketplace. In the A2A + Gemini Enterprise flow described in the source, an administrator can then add or configure that procured agent in the customer’s Gemini Enterprise environment.

That separation is useful: the person responsible for purchasing does not have to be the same person who decides which employees are allowed to use the agent.

Google provides the marketplace. You still own the product.

Where Agent Registry fits — and where it does not

You may also use Agent Registry, but it solves a different problem from Marketplace.

Agent Registry is about discovering and governing agents in the Google Cloud agent ecosystem and within an organization. The source notes that supported runtimes can register agents automatically, while external or cross-project agents can be registered manually. A2A information such as the Agent Card and skills can help describe them.

Google Cloud Marketplace is about distributing and selling the agent to customers.

Agent Registry
  → discovery and governance

Google Cloud Marketplace
  → commercial listing, procurement, entitlement, billing

Gemini Enterprise Agent Gallery
  → governed end-user discovery and use

Seven mistakes that turn onboarding into rework

1. Opening Producer Portal before the agent contract is stable

If the endpoint, authentication model, or public capability keeps changing, the Agent Card and integration keep changing too. Stabilize the external contract first.

2. Mixing up product type and runtime

Cloud Run and GKE tell you where software runs. A2A Agent-as-a-Service, SaaS, Kubernetes app, and Professional Services tell you how the customer buys what you offer.

3. Writing the Agent Card like marketing copy

The Agent Card is integration metadata. Keep it precise, technical, and honest about what the agent can actually do.

4. Describing skills so vaguely that nobody knows when to call them

A skill is useful only if another system can look at it and know when your agent is the right agent to call.

5. Choosing usage pricing before defining the meter

A pricing metric has to be countable, repeatable, and auditable before you build billing around it.

6. Treating Marketplace events like optional webhooks

Purchase and cancellation events affect access and revenue. Use idempotency, persistence, retries, and monitoring.

7. Treating entitlement and authentication as the same thing

A caller can be authenticated while the customer’s subscription is inactive. A customer can also be entitled while a particular request is not authenticated. Check both.

For a first Marketplace agent, this is the order I would use

1. Define exactly what the agent does and who buys it.
2. Choose the Marketplace product type.
3. Choose the runtime.
4. Deploy one stable production endpoint.
5. Add and test A2A for the Agent-as-a-Service path.
6. Create and version the Agent Card.
7. Start Marketplace vendor onboarding in parallel.
8. Create the product and validate the Agent Card in Producer Portal.
9. Write the human-facing listing and submit pricing early.
10. Implement Pub/Sub and Partner Procurement API integration.
11. Add usage reporting only if the pricing model requires it.
12. Implement and test authentication, OAuth, and DCR where required.
13. Run an end-to-end purchase, upgrade, cancellation, and access test.
14. Complete product, pricing, technical, and Agent Card reviews.
15. Pass Google validation and publish.
16. Test the real customer-side Gemini Enterprise journey.

One last check before you call it ready

Keep the official Google Cloud docs beside you while you build