--- title: "What Changes When an Agent Signs Up for Your Product" date: 2026-10-22 description: "What agent signup reveals about temporary access, identity, trial limits, setup, and permission to spend." author: Kat Laszlo stylesheet: /blog/agent-onboarding.css reading_time: 6 min read --- # What Changes When an Agent Signs Up for Your Product A customer asks an agent to find a tool, try it, or set up a paid service. The agent can read the docs, create a resource, and start working. The customer may not open the product until there is something to claim, approve, or pay for. That changes the self-serve experience. Products need to help the agent get started, show the customer what needs their attention, and let the agent continue afterward. Three onboarding patterns show how this is taking shape: 1. **Try first, claim later.** The agent creates a resource. The customer takes ownership later. 2. **Start with restricted access.** The agent can use the product, with limits on what it can do. 3. **Authorize before access.** The customer grants permission before the agent receives credentials. These patterns can overlap. A product might let an agent create a temporary resource with limited access, then ask the customer to claim it.
Three schematic paths. Try first, claim later: an agent requests a temporary resource, does trial work, and a person claims it to keep it. Limited until verified: an agent requests restricted access and works within limits until required verification permits broader access; the verifier may be an agent or a person. Person sets up first: a person links an account or authorizes access, then the agent receives credentials and works within permissions. These paths were not all tested end to end.
The point where ownership or verification enters the flow changes. These are schematic paths; the required verification may be performed by an agent or a person.

Try first, claim later

CloudflareNeonPrisma

Start with restricted access

AgentMailCloudinary

Authorize before access

InsForge
Browser-approved device flow
## Try first claim later The agent creates a temporary resource. The customer can evaluate the result and claim it to keep using it. [Cloudflare](https://developers.cloudflare.com/workers/platform/claim-deployments/) lets agents deploy supported resources into temporary accounts with a 60-minute claim window. [Neon](https://neon.com/docs/reference/claimable-neon) offers database projects that expire after 72 hours if unclaimed. [Prisma's create-db](https://www.prisma.io/docs/postgres/npx-create-db) provisions temporary databases with a default 24-hour lifetime. [Netlify's anonymous deploys](https://docs.netlify.com/api-and-cli-guides/cli-guides/get-started-with-cli/#anonymous-deploys) provide a live URL and an hour to claim the project. The customer gets to make a decision about a working app or database. The product should explain what they are keeping, what limits or costs apply, and what happens if they leave it unclaimed. The agent needs those details too. It should be able to tell the customer how much time they have and recover if a claim code expires. Neon separates those deadlines. An unclaimed project can last 72 hours, while an unused claim code expires after 15 minutes. The API can issue a replacement code while the project remains valid. The customer can miss the code's deadline without losing the database. Claiming can also change the agent's access. Cloudflare says that claiming a temporary account does not grant the provisioning platform permanent access. Neon changes credentials during transfer. After the customer claims the resource, the agent needs to check whether it still has access and obtain new credentials if required. The claim should leave it with a clear way to continue. ## Start with restricted access The agent gets access immediately, with limits on what it can do or where the result can be used. [AgentMail's signup endpoint](https://docs.agentmail.to/api-reference/agent/sign-up) can create an inbox without a human_email. It can receive email but cannot send until a human is attached or an eligible inbox is claimed through the Console. An agent setting up an inbound-email workflow can get started. An agent asked to send an email needs to complete another step. [Cloudinary's temporary clouds](https://cloudinary.com/auth.md) allow uploads and transformations immediately. Delivery of the resulting media is limited to declared public IP addresses until claim. Usage caps are also lower than those of a regular free account. That can affect what the customer sees. If delivery allows only the agent server's IP, the agent can upload and transform an image, check the URL, and return a result the customer cannot open. The initial access needs to support a useful part of the task. A receive-only inbox can demonstrate an inbound integration. An image transformation needs a way for the intended viewer to see the output. When an action is unavailable, the product should explain why and what enables it. The agent needs to know whether it can complete another setup step itself or needs to ask the customer. ## Authorize before access Some products ask the customer to approve access before the agent can use them. [InsForge's device flow](https://api.insforge.dev/auth.md) asks the customer to open a browser, sign in, and approve the requested scopes. The agent receives a scoped OAuth access token after approval. Creating the backend project remains a separate step. InsForge also documents an identity-assertion route for participating providers. With user consent, a supported provider can supply an assertion carrying the user's verified email. InsForge can then match or create the user and return a user API key. Its [agent instructions](https://insforge.dev/skill.md) describe that route as a preview, dependent on provider support. The agent needs to show the customer where to approve access and what permissions are being requested. Once approved, it needs to check the result and continue. Email verification establishes something narrower. A code demonstrates access to an inbox. Whether a person reviews or submits it depends on the flow. [Cosmic's tutorial](https://www.cosmicjs.com/blog/agentmail-cosmic-agent-signup) shows an agent supplying an AgentMail inbox as Cosmic's human_email, reading the claim code, and completing Cosmic's verification. The tutorial separately sets up AgentMail using an owner's mailbox. Verifying an inbox and getting the customer's approval are different checks. The product needs to be clear about which one it requires. ## From access to a working product After getting access, the agent still needs to configure the product and check that the result works. [Autumn's setup workflow](https://useautumn.com/SKILL.md) offers a choice between signing in and creating a sandbox without an account. A customer can claim the keyless sandbox later. Its instructions guide the agent through pricing configuration, approval, and verification. The workflow asks the customer to approve the proposed pricing before the agent applies it, unless they have already authorized proceeding without review. The agent handles the setup and verification around that decision. Purchasing can also require preparation. [AgentMail's x402 integration](https://docs.agentmail.to/integrations/x402) requires a wallet with USDC funds for API usage. [Stripe Projects](https://docs.stripe.com/projects) documents signing in, associating a provider account, and adding a payment method before an agent session to avoid browser pop-ups during provisioning and credential exchange. It also supports global and per-provider spend limits. The agent needs to know what it is already allowed to buy and when to ask the customer for a new decision.
Both schematic payment paths require a supported payment route, sufficient funds, and permission to spend. Prefunded wallet: a person funds a wallet, the agent requests a price, pays within its authorization, and checks both payment and resource delivery. Linked card: a person links an account, adds a card, and may set a spending limit; the agent selects a paid service, an authorized charge is processed, and both payment and resource delivery must be checked. A bank or provider may reject a request. Payment success alone does not prove delivery.
Funding and authorization happen before the purchase. Confirm any required account eligibility, then check payment and delivery separately.
It also needs a way to check whether a purchase succeeded. If the result is unclear, it should be able to inspect the original request before trying again. The customer needs to know whether they paid, whether the resource exists, and whether it is ready to use. ## Help the agent continue An agent should be able to explain what it has set up, what works, and what still needs the customer. If a database expires, the agent needs to know when. If an inbox cannot send, it needs to know how sending is enabled. If claiming a project changes its credentials, it needs a way to reconnect. The customer's decision should move the task forward. After they claim a resource, approve access, or authorize a purchase, the agent should be able to check what changed and continue the work.