Production Ownership — B2B AI Workspace by Achraf El MouhibProduction Ownership — B2B AI Workspace by Achraf El Mouhib

Production Ownership — B2B AI Workspace

Achraf El Mouhib

Achraf El Mouhib

Production Ownership (B2B AI Workspace)

TL;DR

I led the production pivot of an AI workspace from a consumer-only architecture to an enterprise-ready B2B platform, enabling 150+ enterprise seats and 2–3 paid pilots (~$60k–$240k total).
I shipped true multi-tenancy, SSO, RBAC + auditability, and a reusable integrations framework under strict constraints: no downtime, no data leaks, and active enterprise usage throughout. (Company and customer names omitted due to NDA.)

Setup

Before: single global context (personal chats, personal memory, personal tools). Enterprise blockers: no tenant boundary, no admin controls, no SSO path, no safe workspace-level integrations. Hard constraints: Privy remained canonical identity; enterprise requirements were non-negotiable; production traffic could not be disrupted. Trigger: a large enterprise required Microsoft SSO + isolated workspaces + secure document access via Microsoft systems.

What I Owned

Production delivery and release governance for the enterprise pivot: sequencing high-risk changes across identity, tenancy, memory, infra, and integrations, with explicit rollout/rollback paths.

Battle 1 — True Multi-Tenancy (Workspace Boundary)

Decision: introduce workspaces as the real platform boundary, not a UI concept.
Execution: chats, agents, documents, and memory became workspace-scoped; isolation enforced across API, DB access, and storage.
Proof (Isolation, by design):
A single entry gate resolves workspace context and validates user membership (workspace_users) before workspace actions execute.
Data access is always scoped by workspace_id; object storage is prefix-scoped by workspace/user (e.g., {workspaceId}/{userId}/…).
Memory retrieval is explicitly scoped (user / workspace / chat / none) and filtered server-side using workspace_id + user_id.
Migration strategy (no downtime):
No big-bang backfill. Existing users receive a personal workspace on next login (idempotent provisioning) while legacy identifiers remained stable.
Chat histories + documents were migrated with dry-run → staging → production, moving storage into the workspace/user prefix layout.
Result: the product moved from “one app with users” to a multi-tenant platform that can host multiple companies in parallel without cross-tenant leakage.

Battle 2 — Enterprise SSO Without Breaking Canonical Identity

Constraint: enterprises demanded pure SSO; Privy had to remain canonical; double auth and identity divergence were unacceptable.
Decision: separate enterprise auth surfaces without forking identity.
Execution:
Enterprise workspaces run on dedicated subdomains ({workspace}.company.com) enforcing an SSO-only auth path.
On first SSO login, users are silently provisioned/linked into Privy to preserve one canonical identity pipeline.
Result: enterprise users see only SSO; consumer auth flows stay intact; identity consistency across chat/memory/workspaces is preserved.

Battle 3 — Integrations as Core Infrastructure (Not One-Offs)

Need: enterprise agents had to access Microsoft systems (SharePoint/OneNote) without custom client engineering.
Decision: build workspace-level integrations as reusable core infra.
Execution (framework primitives):
Delegated OAuth + workspace-scoped connector lifecycle (connect, refresh, revoke).
RBAC-gated integration management and usage.
Resource registry + agent tool surface (standard pattern for new connectors).
Proof (Token security):
OAuth tokens are encrypted at rest (AES-256-GCM); the database stores ciphertext only.
Decryption happens server-side only; tokens are never exposed to the client.
Result: Microsoft Graph shipped as the first connector; future connectors (Slack/Notion/Google Drive) fit the same framework.

Battle 4 — Memory Reliability + Cost Reset (Qdrant, TS → Python)

Decision: move memory to a dedicated service built for reliability and cost control, without changing product behavior.
Execution:
Migrated memory retrieval/write to a dedicated Python service backed by Qdrant, removing the Neo4j graph layer from the hot path with no functionality loss.
Standardized memory payloads (camelCase → snake_case) via an idempotent scroll-based Qdrant migration (dry-run → staging cluster → production).
Deployed on dedicated Frankfurt VMs aligned with the Next.js region to minimize network hop.
Observed outcomes (post-cutover):
~$200/month run-rate reduction (graph layer removed).
Average latency: search ≈ 1.5s, save ≈ 0.5–2s.

Release Governance (Why This Didn’t Break Prod)

This work touched the riskiest surfaces (identity, tenancy, infra, memory). I acted as the production gate:
Blocked high-risk PRs (secrets exposure, identity bypasses, unsafe DB changes).
Shipped behind feature flags with staged rollout and explicit rollback paths.
Monitored auth and integration health during rollout (e.g., SSO callback and token refresh flows) with no customer-visible incidents.
Outcome: zero downtime and no customer-visible incidents during the enterprise rollout.

Outcomes

Business
150+ enterprise seats running in production on isolated workspaces.
2–3 paid enterprise pilots enabled (~$60k–$240k total).
A credible enterprise sales foundation built on SSO + isolation + integrations.
Technical / Operational
Safer release process for identity/infra changes.
Repeatable enterprise onboarding and integration pattern without fragmenting the consumer base.
Memory reliability improvements with a lower run-rate cost.
Like this project

Posted Dec 25, 2025

Chat experience with persistent memory/retrieval, plus production systems: RBAC/SSO, multi-tenancy, integrations, observability, release safety.