A store run by eighteen agents.
A white-label commerce platform where a creator or small merchant does not configure a store. They direct a roster of eighteen specialised agents, for design, pricing, growth, operations and money, that watch the business, draft changes, and hand every consequential decision back for a one-tap approval.
A real system, described without its names.
What it does.
Underneath the agents is a full commerce back end: catalogue, pricing, checkout, orders, fulfilment, payouts and paid growth, in twenty-three domain slices with an explicit dependency order. Thirty-two business lifecycles are written as state machines; an order alone runs three. Eighteen process managers carry facts across slices, from a checkout to an order to a fulfilment remedy.
The roster is data, not processes. Eighteen roles are skins worn by one reasoner, and their work runs as durable jobs, so eighteen roles for one tenant costs the same shape as eighteen roles for thousands. A shared nine-state gate fronts every run, from idle through proposed and awaiting review to applied or rejected, and nothing reaches applied without a person. A separate two-legged journal records anything that crosses an external boundary, with a receipt that says succeeded, partial, refused, or unknown effect.
Where a request-and-response stack breaks.
- 01Fan-out, join, then wait for a person
The storefront builder spawns one drafting task per planned section, joins them, and can park indefinitely for a human seal, with no live process and no timer holding the place.
- 02Eighteen roles without eighteen processes
Per tenant, the roster must cost nothing while idle and be fully isolated while running. The answer is jobs and a shared reasoner, not a supervised process per role per tenant.
- 03Side effects you cannot take back
A crash between telling the payment provider and recording that you did is a real failure mode. The journal makes unknown effect a first-class outcome that a reconciler can pick up.
- 04Money in the background
Thirty workers and eighteen process managers touch money, fulfilment and webhooks, so recovery is code, not an incident: webhooks re-registered after an enqueue crash, a dead-letter watch, reconciliation of supplier orders and credit holds.
The same problems, on two runtimes.
Python is a fine language and a poor runtime for this shape of work. Each point below names the piece of infrastructure a Python stack would add, and the runtime property that makes it unnecessary here.
PythonWhat you would have to build
- Draft in parallel, park for days
In Python that is a workflow engine on top of Celery and Redis, a state store for the parked run, and a redeploy that loses whatever asyncio had in flight. The runtime's graph agent records each super-step as an event; a parked run holds no process and resumes from its log.
- Called, or called and known
A request stack cannot tell the provider was called from the provider was called and we have the result. Event sourcing with a journal receipt can, and the receipt survives the crash that caused the doubt.
- A roster across thousands of tenants
If every role is a worker and every tenant a queue, the worker pool is your cloud bill. On the BEAM a tenant's agents are processes measured in kilobytes, and suspending or decommissioning a tenant is one call to the tenant directory.
- Thirty-two lifecycles
Python has no supervision tree and no state-machine discipline built in; each lifecycle becomes columns and if-statements, and each crash a manual repair. Here every machine is explicit, its transitions are events, and its process is restarted on failure.
- Twenty live views over the same facts
The command centre and the public storefront render read models in-process. In Python they are a REST layer, a WebSocket layer and a front-end store, kept consistent by hand.
Z8What the runtime already does
- Agents and one graph
Twenty-four agent modules, one of them a graph with channels, nodes, edges and branches: fan-out, join and a durable pause are declarations, not infrastructure.
- Durable jobs
Thirty workers on the runtime's job queue, with retries, uniqueness and recorded transitions; the roster's work rides on them.
- An event-sourced core
208 event types, 130 commands, fourteen projections and eighteen handlers acting as sagas, on one Postgres event store.
- A tenant directory
Every dispatch, job, fact and pub-sub topic is account-scoped; the runtime's tenant directory is reconciled from the database at boot.
- A gate before every model call
A credits reservation stands in front of each call, so an agent cannot spend what the account does not hold.
- The dashboard, in the app
Mounted under the admin area and password-gated in production; two roles keep long-term memory.
One log, everything around it.
Where it stands.
Pre-launch
Pre-launch, under a formal launch-readiness audit. A strict production boot refuses any simulated adapter: payments, domains, mail and the live model path switch on only when the audit passes. Six hundred and ninety-five commits and 150 merged pull requests in the first six weeks.
Counts on this page are taken from the code as it stood in September 2026: modules, workers, event types and tests, not usage or revenue, which we do not publish.
Does your system have this shape?
Many agents on one problem, work that must survive a deploy, a person in the loop, and a trail someone will inspect. Tell us what you are building.
henry@z8.run