Publish a flow with explicit call state
Launch is one click in the studio (or one API call), it is free, and it is repeatable: relaunching updates the agent without breaking anyone's integration. This page covers what launch validates, what it creates, and the one secret it will only show you once.
One request, an agent out the other side
From the studio, the Launch button does this for you; from code, it is a single authenticated request. The price is optional; a flow launched with no price (or a price of 0) becomes a free agent whose endpoint never issues a payment challenge. A nonzero intended price still does not enable payment by itself.
The response contains everything an integration needs:
What launch checks before anything goes live
Launch validates the flow before any writes, so a failed launch never leaves a half-published agent behind. The checks, in order:
Structure
The graph must be wired together; a disconnected or half-built flow is rejected with a specific structural error rather than silently going live.
Schedule
If the flow has a Schedule node, its cron expression must parse (five fields, UTC, e.g. 0 9 * * * for daily at 09:00). A bad expression fails the launch, not the first scheduled run three days later.
Payout address
If provided, it must be a valid EVM address. You can launch a priced agent without one, but its endpoint will refuse live calls with a 503 until a payout destination exists; the platform never settles money into nowhere.
No prototype nodes
Graphs containing the Connector Lab's API Operation node are rejected with a 409; that node is simulation-only and cannot back a live endpoint.
Shown once, kept forever
If the flow has a Webhook node, launch generates the HMAC signing secret server-side and returns it exactly once, in the launch response. It is stored hashed and cannot be recovered later. Save it wherever the third-party service that will call your webhook keeps its secrets.
Relaunching an agent that already has a webhook endpoint deliberately does not rotate the secret; whatever external service is already signing requests keeps working. The signing scheme itself (HMAC-SHA256 over timestamp.body, 5-minute staleness window) is documented in the node reference.
Discovery is automatic, settlement is opt-in
The moment launch returns, the agent has a public page, directory listing, AgentCard, A2A interface, and explicit call state. An ordinary standalone service may expose a preview; a company or otherwise unready service may be unavailable. Payment-enabled services expose active x402 terms:
Launch does not turn on real settlement. Ordinary standalone services can remain preview-ready until settlement is enabled; company and payment-only services may instead be unavailable. Launch also does not freeze the flow; relaunch after editing to update the live agent. The slug, and therefore every URL above, stays the same across relaunches; a relaunch with a new priceUsdc changes the payment terms callers see on their next 402 challenge, if the service is payment-enabled.
What callers experience on the other side of this endpoint (the 402 flow, request/response shapes, rate limits) is documented in API for callers. What you earn per call is in Payments.
Launch also does not enable AP2 by itself. A payment-enabled, actively deployed service may be eligible for the experimental AP2 v0.2 merchant authorization profile, but it appears in discovery only when AP2_MODE is optional or required and the platform's signing key, issuer trust, and durable replay storage are ready. The advertised extension URI is https://github.com/google-agentic-commerce/ap2/v1. x402 remains the settlement rail; the AP2 layer is a gated authorization and merchant-receipt profile, not a claim that Suede operates every AP2 role.
