Stop building tenant isolation from scratch.

You're already past prototype

You have a working single-user demo of your AI product. The next step is multi-customer, and you've already started writing your own isolation logic. Right now your TODO list looks like this:

• Per-customer session and memory storage
• Per-customer LLM key proxying or per-customer cost accounting on shared keys
• Sandboxed code execution for customer-provided agents
• Channel pairing (WhatsApp, Slack, your own webhook)
• An admin API to provision customers and rotate their credentials
• Backup and restore for customer data portability
• A web terminal so support can actually help when something goes sideways

Each of those is a week of engineering and a week of debugging edge cases. OpenClawMU has shipped all of it.

What you stop owning

• Tenant directory layout and the assumption that it's correct on every code path.
• Token hashing, rotation, and constant-time verification.
• Path-traversal hardening on every API that takes a path string.
• Bubblewrap vs Docker decision, plus the seccomp filter and the cgroup limits.
• WebSocket-based terminal session management.
• OpenAI / OpenResponses compatibility shims.
• S3 backup with the same path-traversal protection.
• The CSV report generator your finance team will ask for in week three.

What you still own

• Your customer-facing auth (Auth0, Clerk, your own).
• The mapping from your customer record → OpenClawMU tenant.
• Your billing UI and your invoicing.
• Your domain logic — the prompts, the tools, the system prompts, the brand voice.
• Your distribution and your customer relationships.

A concrete integration sketch

When a customer signs up in your app:

1. Your signup handler calls POST /v1/tenants on the OpenClawMU control plane with the admin key, passing the customer's quota.
2. You store the returned token in your customer record (encrypted, of course).
3. For chat in the customer's browser, your backend issues a short-lived signed cookie that proxies to OpenClawMU with the tenant token attached.
4. For channel pairing (WhatsApp etc.), you redirect the customer to the gateway's pairing flow URL with their tenant token.
5. Nightly, your billing cron calls GET /v1/tenants/<id>/usage for each customer and pushes the result into Stripe Billing.

That's the whole integration. The product you're actually differentiating on lives entirely above this layer.

Migration off — if you ever need to

Apache-2.0 means you can fork and run forever. The data model is boring filesystem state plus a small SQLite DB; even if Neul Labs disappeared tomorrow, you'd have your tenants' state on your own disks in formats anyone with a half-decent backend background can read.