Ten minutes is not a claim about typing speed. Nobody is racing a form.
It is a claim about a property: that the entire path from signed contract to working agent is a sequence of API calls with no human decision in the middle. Once that is true, the elapsed time is however long the calls take, and ten minutes is a generous estimate. Once it is false — once one step requires a person to open a console and choose something — the elapsed time is no longer measured in minutes, because it now includes that person's queue.
That is the whole finding, and it is worth stating before the details: the difference between ten minutes and three days is almost never labour. It is waiting.
Provisioning as a protocol is thirty years old in the next room
The identity world settled this argument a decade ago and wrote it down.
RFC 7644, System for Cross-domain Identity Management: Protocol, published September 2015 by Hunt, Grizzle, Ansari, Wahlström and Mortimore, defines an HTTP protocol for exactly this problem. Its abstract states the intent plainly: to "reduce the cost and complexity of user management operations by providing a common user schema, an extension model, and a service protocol." Not a better admin UI. A protocol, on the premise that provisioning is machine-to-machine work that humans should not be in the middle of.
The SaaS architecture literature says the same thing about tenants rather than users. The AWS Well-Architected SaaS Lens, published 4 April 2023, defines the problem: "SaaS applications rely on a frictionless model for introducing new tenants into their environment. This often requires the orchestration of a number of components to successfully provision and configure all the elements needed to create a new tenant."
Orchestration of a number of components. That is the correct framing and it is the one agent platforms have mostly not adopted, because their onboarding was designed for a company signing up for itself — a path walked once, by someone with time — rather than for an operator walking it forty times.
The clock
What follows assumes every operation has an endpoint. Where it says a step is one call, that is the test: if it needs a console, the clock stops.
Minute 0 — what has to already exist
The honest part, first. Ten minutes is only available because of work that happened before the client existed:
- A parent tenant holding the connections, branding defaults and policy that children will inherit.
- A versioned agent artifact — the workflow definition, its guardrail configuration and its tool bindings, exported as JSON and kept in version control like any other deployable.
- A limits profile per tier, expressed as values rather than as a plan name.
- An API key with provisioning scope, and an audit log that will record what it did.
None of this is exotic, and all of it is the actual project. The ten-minute onboarding is the output of having built these; treating it as a feature to add later gets the dependency backwards.
Minutes 0–1 — the boundary
One call creates the tenant: name, slug, default locale, and the parent it hangs under.
This is the only irreversible-ish decision in the sequence, because it determines what the client inherits. Everything after it is an override. Getting the parent wrong is not fatal but it is annoying, and it is the one place worth a validation step in your script.
Minutes 1–3 — limits and feature gates
Three families of control, written as values onto the tenant rather than as a subscription:
| Control | Examples | Behaviour when reached |
|---|---|---|
| Resource limits | max agents, users, child tenants, hierarchy depth, storage | Creation is refused with an explicit error |
| Consumption limits | messages per cycle, hard spend ceiling, soft threshold below it | New requests blocked; conversations already in flight are not cut off |
| Feature flags | which channels, which integrations, whether the workflow editor is available | The capability is simply absent |
Two design properties are worth copying if you are building this yourself. Limits resolve up the hierarchy — the tenant's own value, then the nearest ancestor that has one, then the platform default — so an operator sets a ceiling once and it applies to every client underneath without being written forty times. And the enforcement layer never reads the plan. Plans are commercial; limits are functional. Provisioning writes numbers, the runtime reads numbers, and the two are decoupled — which is what lets you give one client a temporary exception without inventing a plan for them.
The default should be unlimited, with limits opt-in restrictive. A limits system whose failure mode is blocking existing tenants will be switched off within a quarter.
Minutes 3–4 — connections, inherited rather than copied
The child does not get its own copy of your model provider key. It resolves connections up the tree and cannot modify what it resolved.
Copying the credential down would be faster to implement and it is the wrong call, for a reason that shows up much later: a copied key is a key you now have to rotate in forty places, and a key the client's team can read. Inheritance makes rotation one write at the parent and makes the credential unreadable from below. The client operates their agent; they do not hold your key. That relationship is the whole point of the hierarchy, and this is the minute where you either get it or lose it.
Minutes 4–6 — the agent, from an artifact
Import the versioned artifact, then override the handful of things that are genuinely per-client: display name, greeting, knowledge base bindings, branding.
The artifact carries its own security configuration — which checks run, on which content, with which action on violation. This matters more than it sounds. If guardrail policy is configured per client after provisioning, then it is configured well for the clients you were paying attention to and badly for the rest, and the manipulation surface is not something you want varying with how busy you were that week. Ship it in the artifact and let the override be the exception.
The agent is created inactive. It is activated at minute nine, after verification, and not before.
Minutes 6–8 — channels and origins
Enable the channels the tier allows, wire the client's own messaging credentials where the channel needs them, and register the allowed origins for the web widget.
The origins list is the step most likely to be skipped and the most likely to produce a support ticket, because the symptom of getting it wrong is a widget that loads and then silently fails to talk — a CORS rejection in a console nobody has open. Script it, and script the check.
Minutes 8–9 — people
Create the client's administrator and send the invitation. Scope their role to their own tenant.
Invitation rather than a set password. You should not know, transmit, or store the client's credential, and an onboarding script that generates one has created a secret that now exists in a log somewhere.
Minutes 9–10 — verification
Send a real message to the agent through a real channel and assert on the reply.
This is the step that separates a provisioning script from a provisioning pipeline, and it is the one most implementations omit. Without it you have made forty API calls and confirmed that forty API calls returned 200, which is not the same as a working agent. With it, activation is conditional on a passing test, and the failure lands on you at minute nine rather than on the client on day two.
Why the same work takes three days
Add up the manual version and the labour is roughly forty minutes of clicking. It still takes three days, and the diagram above is the reason: each human step is a handoff, and each handoff waits on somebody's queue.
The four that do it most reliably:
- A credential that has to be requested. The client's messaging account details arrive by email, on their schedule. This one is often genuinely external — but it can be moved to the front and made a precondition rather than discovered at step six.
- A step only one person knows. Usually the origins list or the channel wiring. It is not documented, so it waits for that person.
- Configuration by copying the last client. Fast, and it propagates whatever was wrong with the last client. This is how fleets drift: not from a decision, but from forty successive copies.
- No verification, so failures surface later. The three days become five when day four is spent diagnosing a widget that was never going to connect.
When ten minutes is the wrong target
Two cases, and both are common enough to name.
When the clients are not similar. Scripted onboarding pays off in proportion to how much of the configuration is shared. If every client needs a bespoke workflow, bespoke integrations and a bespoke data model, you are not onboarding tenants — you are delivering projects, and the artifact you would template does not exist. Build the script when the third client's configuration looks like the second's, not before.
When the boundary is heavier than the need. A tenant per client means a boundary to provision, permissions to model, and a hierarchy to reason about. Some clients need a bot, not an organisation. Provisioning an agent inside your own tenant is a shorter path and the correct one when the client will never log in.
And a caveat that applies even when the script is right: automating a process encodes it. If your onboarding is wrong today, scripting it produces a fast, repeatable wrong outcome, forty times, with an audit trail proving you did it deliberately. Get the manual version correct once, then automate the correct one.
The test
Take the onboarding you run today and score it. One point each, and the scoring is deliberately unforgiving because partial credit is what hides the problem.
- Can you provision a complete client without opening a UI? Not "mostly" — at all.
- Is the agent's configuration a versioned artifact in source control, or does it live only in the platform?
- Does the new client inherit your provider credentials, or receive a copy?
- Are limits written as values, so you can grant an exception without inventing a tier?
- Is there an automated smoke test between provisioning and activation?
- Can you tear down a client completely, in one operation? Untested teardown means untested onboarding, because you cannot run the thing twice.
- Does the audit log record which identity performed each provisioning step?
- Could someone who joined last week run it end to end from the documentation?
Six or better and your constraint is genuinely the client's paperwork. Below four, the ten minutes is not a tooling problem — it is that the process still has people standing in it, and every one of them is a queue.
RFC 7644 made this argument for user accounts in 2015 and the industry agreed. The same argument for tenants is not harder. It is just newer, and mostly still being made in consoles.
