Provisioning a tenant, running the fleet, and the operator's agent.
Creating a project is one flow, identical across hosting tiers: create the Neon project, apply the schema chain and replay the stateless set, seed the defaults and the solution's demo catalog, create the two storage buckets and mint their credential, configure the auth instance and its trusted origins, enable the Data API, mint the project-scoped key, and register the tenant in the fleet directory. The project is written as provisioning first and flipped to active last, so a run that dies leaves a visible non-serving row rather than an unregistered project. The flow is resumable.
Runtime provisioning is dedicated-only: create the Vercel project, copy the runtime environment, add the tenant's secrets, assign its exact host, deploy. A shared tenant needs none of that.
Teardown sets deprovisioning, revokes the tenant's key, and deletes the Neon project, which deletes its buckets with it.
Every operation that touches many tenants is a fleet job: one tenant at a time, stopped by a deadline, returning the slug it stopped at so a re-run resumes from there. Migrations, rule replays, key minting, secret sealing and the analytics refresh all run this way, from the command line or as an agent tool.
A tenant's owner connection is never stored. It is derived on demand from the tenant's project-scoped key, which in turn is sealed under a secret only the operations runtime holds.
The operations app hosts an agent whose scope is the control plane: projects, credentials, migrations, grants, runtimes, solutions. It holds no tenant-content tools; a tenant's own products and settings are managed from the tenant's admin, and a customer provisions their own store from the console.
Every write tool carries a structural approval gate. When the model calls one, the session pauses and the operator sees a card with the tool's full input; the write proceeds only on their answer. The instructions require the model to state plainly what a write will create, change or delete before calling it, grounded in what the read tools returned. Operator chats are ephemeral working sessions, not records.
The agent is sealed in production until a real operator login replaces the placeholder: a browser session holds no machine identity, so the auth chain fails closed off the loopback.
The provisioning key, which alone can create and delete projects, lives in the operations app's environment and nowhere else. The Vercel token that writes a dedicated tenant's secrets lives there too, read by exactly two tools. The model cannot reach the environment: it sees only tool results, and no tool executes model-authored code in the runtime that holds the keys.