Init demo recap: Rami Banna provisions WorkOS from an agent with Stripe Projects

A coding agent can write the integration code and then stall at the signup form. Someone still has to create the account and copy the keys into the project. Rami Banna's lightning demo at init() moved that step inside the agent's run.

Banna, from Stripe, presented in the afternoon program at WorkOS init() on October 7, 2026, at SFJAZZ in San Francisco. The full init() 2026 recap covers the keynote and the rest of the day. Michael Grinich introduced him with a promise of new agent work from Stripe, one of the event's sponsors. Banna opened by saying Stripe wants agents to be able to provision their own tools and services, and is building the infrastructure for it.

A gray badge and a dead button

The starting point was a small admin app in dark mode that the agent had built earlier in the same session. It had overview, teams and settings pages, a gray not-configured badge, and a Manage integrations button that didn't work yet.

Banna's prompt told the agent to make that button work with WorkOS Admin Portal, turn the badge green and provision WorkOS. He had no WorkOS account going in, so the account itself was part of the job.

What the agent did without an account

While the agent worked, Banna explained the piece underneath. He described it as part of Stripe's provisioning infrastructure, a protocol he had spent a few months on with partners so that an agent can discover a service, provision it and pay for it.

The agent picked up the Stripe Projects skill and found WorkOS available on the Stripe Projects network. Banna narrated the plan from there. The agent would create the WorkOS account and the resource, bring a provisioning skill from WorkOS into the local project directory, and then use the new credentials in the app running locally.

His framing of the gap was blunt. If agents can already write the code, the unsolved part is getting hosting, auth, databases and the rest of a stack into real production. Mid-run he put the Stripe Projects catalog on screen, with hosting providers including Cloudflare listed next to database, AI, analytics and communications services. The catalog was context. The agent provisioned only WorkOS on stage.

Green badge, working button

Banna refreshed the app and the badge had turned green. Clicking Manage integrations opened WorkOS.

He then showed the project directory the agent had been working in. The agent had provisioned WorkOS auth with two credentials and placed a newly created credential in an environment variable. Banna summed up the run as autonomous account and resource provisioning on the free tier.

The run stayed on the free tier. Banna said paying for a plan could also go through Stripe's rails, but nothing was charged on stage. The agent also picked those credentials up from its own working directory to wire up the app, so the project now holds WorkOS credentials that need the same handling as any other secret.

The API under the CLI

Then Banna moved from the agent to the infrastructure behind it. He said Stripe had just opened the provisioning API as a private preview and invited the audience to apply. Stripe's documentation lists the Provisioning API as allowlisted during that preview.

His pitch was that you could embed the same provisioning, across the providers on the network, inside your own agent, SDK or development platform, and white label it. To show what that might look like, he switched to a second UI: a vibe-coded marketplace built on the same API, doing what the agent had just done through the CLI. These are separate things. The marketplace illustrated what a platform could build on the API, while the green badge came from the agent run with the Stripe Projects skill.

The platform version also draws a different trust boundary. Stripe's guide has your backend hold the Stripe key and check that the user is authorized for the tenant before it calls the API. It tells you not to let a browser, a generated application or a coding agent call the Provisioning API directly.

Trying the CLI path now

WorkOS has been a Stripe Projects provider since April. Running stripe projects add workos/auth in a project directory provisions a WorkOS environment and writes WORKOS_CLIENT_ID and WORKOS_API_KEY to .env. Stripe labels Stripe Projects a public preview, and its skill installs into coding agents so they can run the same commands.

Banna posted afterward that the agent got its own WorkOS account and keys and wired them up in under five minutes. The route he used on stage starts in the Stripe Projects docs. If you run a platform and want your users' agents to provision services through your product, the Provisioning API guide explains how to request preview access.