Wiring Agent Provisioning Into Your Signup Webhook so Every Customer Gets Their Own Agent Instantly

Give each new customer their own AI agent by putting a single provisioning API call in the signup webhook. That call must create an isolated, persistent sandbox with a spending limit and a stable endpoint before the customer reaches the dashboard. Auto-sleep makes this practical by separating a persistent agent from compute that runs all day.

Why provisioning belongs in the signup webhook, not in the onboarding flow

Signup is the event every customer completes, so it is the right place to attach provisioning. A wizard, a “set up your agent” button, or a post-login prompt makes agent creation depend on another action. If the customer skips that action, abandons the flow, or hits an error, the agent never appears. The founder then has to notice the gap and repair it manually.

A webhook tied atomically to signup removes that dependency on user behavior. Agent37 uses this pattern to provision each customer’s agent when signup ends, without the founder having to step in. The event is consistent even though its delivery can be retried, which makes duplicate handling a provisioning requirement. Provisioning on first use avoids a setup button but introduces a cold-start delay at the moment the customer expects the product to work.

What the webhook payload must carry before the provisioning call is made

The webhook needs to supply identity and constraints. Its minimum inputs are a stable user identifier, the selected agent harness, the customer’s plan, and any tool-integration scopes already authorized. If those inputs are missing, the provisioning layer cannot reliably assign ownership, choose the runtime, or attach the right spending controls.

The stable identifier comes from the auth system and becomes the sandbox’s namespace. A user ID or tenant ID gives the provisioning layer a key that stays the same, so it can spot the same event when it arrives again. The selected harness, including Claude Code, Codex, OpenCode, Hermes, Grok, or a custom harness, determines the runtime environment. The plan or tier sets the spending limit and resource quota when the sandbox is created, so those limits are in place before any later configuration step.

Authorized tool scopes establish what the agent may do for that customer from the first session. They describe the permissions already granted, but the payload must not carry raw credentials, full OAuth tokens, or secrets traveling in plaintext. Those secrets belong in task-scoped runtime injection.

What the single API call must guarantee when it hits the provisioning layer

A sandbox ID is a receipt. The call must put isolation, persistence, a spending limit, and a stable endpoint in place together. Otherwise, the builder still has to assemble those guarantees through separate steps, and “one call” describes only the wrapper. Agent37’s Cloud API implements this pattern through a per-user sandbox with hard filesystem boundaries, persistent state, and a billing cap tied to the customer’s plan.

Isolation needs both filesystem and process boundaries between tenants. Standard Linux containers share the host kernel, so a kernel exploit or a misconfigured mount can expose one customer’s files to another. A distinct sandbox name does not close that gap. Stronger designs include gVisor, which intercepts system calls, and Firecracker microVMs, which use hardware-enforced KVM boundaries.

Persistence is a separate guarantee. A persistent personal agent requires files, variables, and state to survive between sessions, including sleep. The call must also accept a per-sandbox budget cap so a runaway agent cannot consume an unbounded share of the platform’s resources. Finally, the user ID must serve as the idempotency key, so a duplicate webhook returns the same sandbox.

How auto-sleep makes the economics of one persistent agent per user viable at scale

A sandbox for every customer sounds expensive if “persistent” means “running continuously.” It does not have to mean that. Auto-sleep pauses an idle sandbox and wakes it on demand with state intact, making compute cost follow activity.

Browser and computer-use tasks use compute in bursts and sit idle between them. Billing for active compute rather than the full wall-clock lifetime is materially cheaper for that workload. Retained storage still has a cost, so sleeping is not the same as deleting the sandbox or making it entirely free.

Paid customers put this model to a harder test than inactive free accounts because their agents do more work. Auto-sleep keeps idle cost in check, while the spending limit set at provisioning caps what the platform can spend during active use. A stable endpoint also does not promise uninterrupted uptime, since availability still depends on the prepaid balance and auto-sleep settings. A monthly plan can work with persistent state, compute that runs on demand, and limits on spending, but it cannot support unlimited operation.

Wiring tool integrations so each agent can act on behalf of its user from session one

A correctly isolated sandbox is still inert until it can reach the customer’s tools. If signup already captured permission to use an app, making the customer authorize it again on first use restores the manual setup that automatic provisioning was meant to remove. The provisioning call therefore needs to carry that authorization context into the integration layer.

There are two parts to this connection, namely access to the app and proof of whose account the agent may use. Composio’s managed authentication model stores OAuth credentials as per-user connected accounts, so the agent can act for the right person without the builder having to handle the tokens. Gmail, Slack, GitHub, WhatsApp, and Notion calls then use that customer’s authority. An isolated filesystem cannot compensate for a global credential that gives every agent the same access.

Organizational tools can need a different scope. Composio introduced Shared Connections in September 2026 so a company account can be shared across a team’s agents and teammates without passing credentials around. That is distinct from using a shared account where individual identity is required. MCP, or Model Context Protocol, brings these integrations to the agent through an endpoint that can expose many apps. However, loading the entire catalogue’s tool schemas into every call consumes context and tokens, so expose only the schemas needed for the task.

The four security controls the provisioning layer must enforce at sandbox creation

Security settings need to be in place when the sandbox is created because an agent can act before an audit finds its mistakes. The provisioning layer must enforce four controls, namely a network egress allowlist, filesystem write restrictions, task-scoped secrets, and configuration file protection. These are conditions of readiness. A private sandbox is only part of the boundary if it can still send data anywhere or rewrite the instructions it will execute later.

The first control limits outbound network access to authorized endpoints. NVIDIA’s practical guidance recommends tightly scoped allowlists enforced through HTTP proxy, IP, or port-based controls, with a default-ask posture combined with enterprise-level denylists. With open egress, prompt injection can have a way to send data out. The second control blocks writes to dotfiles, hooks, and MCP configuration directories. A malicious change to these auto-executing paths can stay in place across sessions.

The third control supplies only the secrets needed for the current task and revokes them when the task ends. Inheriting the host’s full credential environment instead exposes every key available to that shared process. Composio’s connected-account model addresses whose credentials an integration uses, but that identity boundary does not replace task-level limits inside the sandbox. The fourth control locks MCP server configs, IDE extension configs, and hook files against modification regardless of the user’s approval level. Filesystem restrictions set where an agent may write, while configuration protection guards the files that can carry malicious instructions across restarts.

Harness defaults cannot stand in for these provisioning controls. Claude Code’s official documentation states that its sandbox is off by default, and Windsurf also does not enable sandboxing by default. Cursor’s official Run Modes documentation says that automatic review mode, the default since Cursor 3.6, runs other shell commands in the sandbox when it can. The provisioning layer still has to supply the per-user isolation and creation-time controls.

How Agent37's Cloud API implements this pattern end to end

The practical pattern starts with the signup event and ends with an endpoint assigned to that customer. With Agent37’s Cloud API, the webhook passes the user ID, selected harness, plan tier, and OAuth scopes already captured. Supported harness choices include OpenClaw, Hermes, Claude Code, Codex, OpenCode, and Grok. These inputs describe the environment to create and the limits under which it will operate.

The API creates an isolated, persistent sandbox namespaced to the user ID. A retry resolves to that same sandbox, and the returned stable endpoint is stored by the product for later sessions. The Cloud API is designed to bring spending limits, authorized integrations, and creation-time security controls into that provisioning step. By the time the customer reaches the dashboard, the agent is available without a setup wizard or another connection prompt for permissions already granted.

Built-in Composio integrations connect that environment to Gmail, Slack, WhatsApp, GitHub, Notion, and hundreds of other apps through per-user connected accounts. For a white-label operator, the same steps create a private, persistent agent with the operator’s branding for each new customer, without the operator’s team having to provision it by hand. Auto-sleep then pauses compute charges while the sandbox is idle, although retained disk continues to bill. Agent37 has a low monthly starting price per agent, and the endpoint and state persist while compute usage and the customer’s spending cap govern ongoing cost.

What to build once provisioning is automatic: the operator model and its economics

Once signup creates the agent automatically, the founder’s bottleneck moves from infrastructure setup to the product itself. The same agent configuration can be deployed privately for each customer in a niche without another round of manual provisioning. That makes the build-once, resell model executable rather than dependent on the founder’s available hours. The next customer gets a separate environment.

Agencies that use per-agent resale usually charge a monthly fee per agent plus a markup on what the platform charges for usage. The economic advantage is not that serving another customer has no cost. It is that provisioning and its associated operational work are handled by the platform rather than growing as a separate manual job for every account. Auto-sleep limits idle compute expense, and per-sandbox caps bound active spending. Those controls make it clearer how much the operator should charge for the service.

That leaves more capacity for selling and improving the agent instead of creating and recovering individual instances. Gartner’s July 2026 projection that a significant share of enterprise application SaaS spending will be exposed to agentic AI by 2030 points toward a market where agents become an expected part of software. Automatic provisioning supports that expectation without making each new sale an infrastructure project.