How an AI agent sets up its own growth engine

An agent can stand up a database without asking anyone. Setting up a growth engine is a different problem, because the account, the inbox and the money belong to a person who is not the one making the call.

So AfterLaunch onboards agents the way it would want to be onboarded by one. The agent can start the process, but it cannot finish it. A human approves, in one click, from an email they were expecting, and nothing at all happens before that click.

This post walks the flow exactly as it works, then explains why it is shaped that way.

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

One approval email goes to the address the agent supplied. One, not a sequence. It says which agent asked, which site it asked about, and what approving will start.

Before that click, the state of the world is a pending request and nothing else. No account is provisioned. No snapshot runs. No trial clock starts. No key exists to be leaked. The single email is the only side effect the whole pre-approval path can produce, which is a deliberate design constraint rather than a happy accident.

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.

That key carries the read and act scopes, is delivered exactly once, and expires after 90 days. Polling again after delivery returns an explicit consumed response rather than a second copy, so a key cannot be handed out twice by a retry. If the key is lost or expires, the founder mints a fresh one from Settings; the flow does not replay it.

The trial starts at approval

The free Growth Snapshot 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 approval-first is the only defensible shape

An agent acting for someone else should never be able to spend that person's money or fill their inbox. Those two failure modes are the whole risk surface of machine-initiated signup, and both are easy to reach by accident: a retry loop, a hallucinated email address, a script pointed at a list of domains.

The flow is built so that none of those turn into a cost or a nuisance.

• The whole path is flag-gated, and the default is off. A configuration failure closes the door rather than opening it.
• Rate limits apply per IP and per email address, so nobody enumerates domains or retries their way past a wall.
• One free trial per site. The claim is keyed to the registrable domain, so subdomains count as the same site, and it is an atomic claim rather than a check followed by a write.
• One pending request at a time per email and per domain, also claimed atomically. A second concurrent attempt loses rather than doubling anything.
• No metered work is reachable before approval. There is no path from an unapproved device code to a paid call.
• After approval, the ordinary caps take over: credits, per-cycle limits on every metered action, and per-tenant daily and monthly spend caps.

There is a practical instruction for anyone writing an agent against this. Do not retry a site with a fresh email address or a different subdomain. The one-trial-per-site rule is keyed to the registrable domain and it will not be worked around. If a site has already been onboarded, the correct move is to send the founder to sign in and mint a key from Settings.

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.

Acting is part of the same key. Shipping, skipping, editing or archiving a move runs on the act scope, and so does minting a checkout link, which is how an agent hands its founder the upgrade path. Every key minted in Settings and every key the device flow delivers carries it, and none of those actions spends anything. The metered tools, refresh_scan, replenish_feed and run_loop, sit behind the write scope that AfterLaunch issues separately, each bounded by credits, an idempotency key the caller mints, a per-cycle limit and the per-tenant spend caps.

Changing how the engine itself behaves needs the config scope: set_loop_autonomy for the rung a loop runs at, set_loop_cadence to slow or pause one. Social channels never accept the autonomous rung, so anything destined for a social account stays review-and-post by a person no matter which scope the key carries.

The path when no agent is involved

Nothing here replaces the browser. A founder can run the free Growth Snapshot directly, read the same Feed on a page, and mint an API key from Settings whenever they want to hand one to an agent. The device flow exists to remove a copy-and-paste step from a founder who is already working inside an agent, not to build a second product for machines.

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