Case study · 2026 to now · Founder
StoreOS
AI that edits a real store, without ever being allowed to break it.
StoreOS is the agentic operating system for ecommerce. A merchant says what to change; agents propose it; the merchant previews, approves and applies it, and can undo it. It also designs the storefront, keeps it online and migrates stores in. I’m building it as a founder, alongside the day job, and it’s in private beta.
- Prototype
- 10+ parallel provisions
- Success rate
- >99%, zero orphaned resources
- Tenant isolation
- Enforced in Postgres, fails closed
- Status
- Private beta
The problem
Small merchants can’t afford an agency and shouldn’t trust a chatbot with a live, revenue-bearing store. The product problem is trust: an agent that can change checkout is a liability; an agent that can only propose is a colleague.
The engineering problem follows from it: every action must be previewable, reversible, attributable and safe to retry, and tenants must never see each other, even when a developer makes a mistake.
How it’s built
The core is deliberately boring: one door, one ledger, one place where tenancy is enforced. The agents live outside it and can only knock.
Scroll the diagram sideways →
- The only door
- Every client and every agent goes through one Go API. Mutations are typed capabilities that produce a ChangeSet, and carry an idempotency key.
- ChangeSets are a state machine
- Propose, preview, approve, apply, undo, with risk classes, an audit ledger and an outbox. The riskiest class always needs a person.
- Tenancy is a database wall
- Forced row-level security on the workspace. A missing tenant returns zero rows, not everyone’s.
- A namespace per store
- Each store runs its own Medusa and database in its own Kubernetes namespace; a controller reconciles every store toward its desired release.
- Agents on a durable workflow engine
- One Temporal workflow per conversation: parallel design directions, then a build-and-review loop before a merchant sees anything.
Decisions that cost something
01
The database is the wall.
Tenancy enforced with row-level security means an application bug leaks nothing. A forgotten WHERE clause stops being a security incident.
The costEvery query path pays the policy tax and migrations are fussier.
02
Agents propose; people dispose.
Every agent action is a ChangeSet that can be previewed, approved, applied and undone. It’s slower than letting the model just act, and it’s the only version a merchant will switch on.
The costLatency on the happy path, in exchange for trust.
03
Lock the money paths.
Cart, checkout and payment code are off-limits to agents entirely, however the request is phrased. The blast radius of any model mistake is bounded by construction, not by prompt.
The costSome customisations need a human. That’s the point.
04
Replace the operator, not the idea.
The prototype ran on a Python Kopf operator. Production needed stricter guarantees, so a Go controller is replacing it. The reconciliation model carried over untouched; only the implementation changed.
The costA rewrite, paid for once, with the design already proven.
What went wrong, and what it taught me
Cleanup is the product.
StoreOS began as a provisioning prototype in April 2026: Kopf, Helm, Medusa and WooCommerce on a small k3s cluster, creating isolated stores on demand. Getting to 10+ parallel provisions at over 99% success with zero orphaned resources taught me that the create path is the easy half. The delete-and-recover path is where trust lives. That lesson became the spine of the rewrite.