How an AI agent sets up its own growth engine

An agent can request an AfterLaunch account connection while you are working together. Because the account and email address belong to a person, the request includes a separate approval step.

The agent starts the request and receives a device code. The person enrolling receives an approval email and confirms the request before account activation proceeds.

The flow below explains the handoff. Use the developer reference for the current response fields and authentication requirements.

Tap to zoom

The flow, end to end

The agent submits a site and an email

The agent posts to /api/v1/onboard/start with a small JSON body: the founder's site URL, the founder's email address, and a label naming the agent making the request. The call carries no authentication, because the entire purpose of the flow is to obtain a credential that does not exist yet.

The response is a device code, a polling interval in seconds, an expiry, and a note explaining what happens next. The device code is the only thing the agent holds at this point, and on its own it grants nothing.

The founder gets one email

The approval email identifies the requesting agent and site, and explains what confirming the request starts. Check those details before approving.

Before approval, the request remains pending. The agent does not yet hold an account key, and the onboarding flow has not started the snapshot or trial.

The agent polls

The agent posts the device code to /api/v1/onboard/poll at the interval it was given. While the request is unapproved it gets a pending status back and waits. Once the founder approves, one poll returns a ready status carrying the API key and the enrollment id.

The key carries read and act, plus write when the self-serve write grant is enabled. It expires after 90 days. Delivery is single-use: another poll returns a consumed response, not a second copy. If the key is lost or expires, the person enrolling can mint a new one in Settings. Use whoami to check its actual scopes.

The trial starts at approval

The free scan and the 14-day trial both start at the moment of approval. The founder ends up with exactly what they would have had if they had signed up in a browser, and the agent ends up holding a key to the same product run. There is no parallel, degraded, agent-only account.

Why the flow requires approval

The approval step gives the person enrolling an opportunity to check the request. Rate limits, request expiry and duplicate handling also matter because clients can retry or lose a response.

The implementation applies controls at the request and activation boundaries:

• The flow can be disabled through its feature gate.
• Requests are rate-limited and expire if approval is not completed.
• The domain claim prevents a new free trial being created by resubmitting the same site.
• Pending requests are claimed atomically to handle concurrent submissions.
• Metered generation begins only after approval and remains subject to the account’s spend controls.

A website is an analysis target, not an account reservation. Different people can analyse the same website in separate accounts, including with a Gmail address. Each email still gets one free trial. If that email already has an account, sign in and manage the connection in Settings.

Tap to zoom

What the agent does with the key

The key authenticates every API and MCP request as a bearer token. The sensible first call is whoami, which confirms the key works and returns the product run it is bound to, the key name and scopes, the product URL, the tier and the trial end date.

From there the read scope covers the useful ground. list_feed returns the ranked backlog of prepared growth moves, each with why it matters, its rank and its full draft body. get_loop_status reports which loops are provisioned for the product and how much autonomy each has. list_outputs and get_output return the drafted outputs. get_enrollment returns the run summary and its delivery settings.

The act scope covers operations such as editing or dismissing growth work. Metered actions, including refresh_scan, replenish_feed and run_loop, require write. Configuration and external publishing have separate scopes. Call whoami and read the current action description instead of assuming a delivered key has every permission.

Configuration tools use the config scope where available. A self-serve key does not include egress, the separate permission required for supported external publishing. Editing a draft does not publish it.

The path when no agent is involved

You can also begin in the browser and create a key in Settings later. The device flow connects an agent to the same product run and growth work.

The endpoints, the tool list, the scopes and the auth model are documented in full for both humans and machines.