Who this is for: the product or commercial lead who owns signup, activation and the first week, and has been asked whether an agent can buy and start using the product without a person on your side.
Someone's assistant tried to buy your product last Tuesday. It read the pricing page, picked the middle tier, and hit the signup form, which wanted a work email and a company size. The next screen wanted a verification link clicked in an inbox the assistant can't open. The one after that offered a call on Thursday. The assistant gave up and told its owner your product "needs a sales conversation", and nobody at your company logged it, because nothing was ever submitted.
Here's the definition, taken from what broke: onboarding a software buyer means that at every step where a person would read, decide, agree, or pay, the software acting for that person can do the same in a single exchange, with no human on your side. That comes down to four obligations - a machine-readable offer, payment inside the same request, an identity on the account, and a route back to a person - and most of your current flow is none of the four and can go.
What onboarding looks like when the buyer is software
Take your flow apart and ask, of each step, what it's for. The answer is usually one of three things: it collects a fact, it establishes trust or consent, or it exists because someone wanted a lead. The first two have machine equivalents. The third stops the purchase.
The signup form collects facts. An agent can supply facts, but not by parsing a form out of HTML with no idea which fields are required. The equivalent is a document at a fixed address listing what you sell, what each thing costs, and what a request must contain. That's what an llms.txt file is for: a plain-text index at a domain's root, proposed in September 2024, that points a model at the documents it needs instead of making it scrape the site.
Email verification establishes that a real, reachable party is behind the account. That job survives, but the inbox isn't where it gets done. Payment does it instead: if the agent pays per call from a wallet, the wallet holder is the accountable party and money moving is stronger proof than a clicked link. The mechanism is an HTTP 402 response, which is just the API quoting a price for the request it refused, which the agent pays and then retries. Two wallet rails carry that payment today, x402 and MPP, and a card is the third. For a prepaid plan you issue a bearer credential, an agent account with a token sent on every request, and that credential is the identity.
The welcome sequence is five emails teaching a person where things are. An agent doesn't learn over five days; it learns at call time or not at all. The equivalent is one documentation page with a real request and a real response on it, linked from the catalogue.
The "book a call" step is where the purchase dies. There's no machine equivalent, because the step exists to qualify a lead, not to serve a buyer. If it's genuinely a gate - you can't sell into certain jurisdictions, say - state it in the catalogue as a condition so the agent can check whether it qualifies. If it's there to route a lead to a rep, it costs you the sale and you never see the loss.
The trial survives, in a better form. A free tier metered per call, on the same endpoints as the paid one, does everything a fourteen-day trial did and doesn't expire mid-task. What doesn't survive is a trial that needs a key issued by a human.
What you still owe the person behind the agent
The temptation, once the form is gone, is to treat the agent as the customer. It isn't. It's a buyer acting for someone, and that someone will dispute the charge, answer for the data, or cancel. Three things stay yours. First, a record the person can read: an itemised receipt, in an account they can reach with a human login even though the agent never used one. Second, limits that hold without supervision - a spend ceiling, a rate limit, and a clear refusal when either is hit, so a looping agent can't run up a bill its owner never agreed to. Third, a way back to a human: an address a person can write to, and a support path that doesn't require replaying what the agent did.
Consent is the one to be careful about. When your terms change materially, a human buyer gets an email and a notice period. A software buyer needs the terms at a versioned address, and needs your API to refuse rather than silently continue when the version it agreed to isn't the one in force. That's the equivalent of a notice period, and it's the piece most teams skip.
The steps, and what happens to each
The table is a model of a common self-serve flow, not a measurement of yours. Fill in your own rows and the pattern will hold.
| Onboarding step | What it's for | Agent equivalent | Verdict |
|---|---|---|---|
| Signup form | Collect facts | Machine-readable catalogue at a fixed address | Replaced |
| Email verification | Prove an accountable party exists | Payment from a wallet, or a bearer credential | Replaced |
| Password and login | Authenticate | Per-request payment, or a token the storefront issues | Replaced |
| Welcome sequence | Teach the product | One documentation page with a working request | Replaced |
| Book a call | Qualify a lead | None; a stated condition if it's a real gate | Stops the purchase |
| Manual key issuance | Control access | None | Stops the purchase |
| Free trial | Let the buyer test | Metered free tier on the same endpoints | Survives, improved |
| Terms acceptance | Consent | Versioned terms, refusal on mismatch | Survives, changed |
| Invoice and receipts | Records for the buyer | Itemised receipts a person can read later | Survives unchanged |
| Support | Help when stuck | Human-reachable address plus machine-readable errors | Survives unchanged |
The smallest version worth shipping
One endpoint you already have, exposed at an agent-accessible API storefront: a catalogue document listing that service and its price, per-call payment so no key has to be issued, versioned terms, a spend ceiling, and receipts the owner can read. Skip the dashboard, the plan builder, and the agent-specific pricing tier. You can't design the second version until the first one has taken an order.
The decision isn't whether to build agent onboarding. It's which single endpoint you'll sell without a human in the loop, and who signs off on the spend ceiling.
What this doesn't tell you
The table is a model, not a finding: we haven't measured how many purchases your form loses, and neither have you, because a stalled agent leaves no record. Nothing here covers products where the buyer must be identity-verified by law; there the human path is the compliant path, and the catalogue's job is to say so. And this is about self-serve onboarding. If your product needs a solutions engineer for two weeks, an agent buying it isn't your constraint this quarter.
Questions people ask
What does onboarding look like when an AI agent is the customer?
It looks like a document the agent can read, a price it can pay in the same request, and a first successful call, all in one session. The form, the verification email, and the welcome sequence are replaced by those three things.
How do I let an AI agent sign up for my product without a form?
Don't make it sign up. Price the endpoint per call and let the agent pay on the request, so the payment creates the account rather than the other way round. If you need a persistent account for a prepaid plan, issue the token automatically on first payment.
Doesn't this let anyone use our product anonymously?
Paid isn't anonymous: a wallet payment identifies who paid and leaves a record on both sides. What you lose is the marketing profile, not the accountability.
Do we have to run two onboarding flows forever?
Yes, and that's fine. The human site and the agent-accessible API storefront are two assets serving two buyers; what's shared is the product underneath, not the front door.
Sources
- The /llms.txt file specification, the proposal for a plain-text index at a domain's root, first published September 2024 (read on 18 September 2026). Read this first.
- x402.org, the HTTP 402 payment protocol: what the price quote looks like and how an agent pays and retries.
- mpp.dev, the Machine Payments Protocol, the second wallet rail an agent may present.