Consumer → Enterprise — the same chassis, stricter constraints

Everything on this site so far has been about one person chatting with their assistant on a phone, and what a lab must build so that a hundred million such people each get their assistant. This chapter turns the picture around. An enterprise — a bank, a retailer, an insurer, a hospital — that deploys an AI assistant to its customers or employees needs the same chassis: a per-turn context pack, stateless workers, a control plane that reconciles a fleet, an eval gate, observability. What changes is not the machine. What changes is the set of constraints bolted onto it: who owns the data, where it may live, who must sign off, and what has to be provable afterwards.

Said the third way: a user becomes a tenant, a segment becomes a policy, and the loops stay the loops.

📖 Story: why the consumer product is the better teacher

Teams that build an enterprise assistant first tend to start from the constraints — the residency rule, the audit requirement, the approval workflow — and bolt a model call onto the side. The result works for forty pilot users and falls over at four thousand, because nothing about the request path was ever designed to be stateless, budgeted, or cheap per turn. Consumer AI had no such luxury: a lab serving millions of strangers had to solve isolation, cost per turn, and quality-at-volume on day one, or it would not have survived the launch week. That is why the consumer architecture is the right starting point. The enterprise version is not a different system; it is the consumer system with a stricter contract layered over each seam that already existed.

What maps to what?

The mapping is close to one-to-one. Each row is a concept from an earlier chapter and the name it takes on inside a company.

Consumer concept	Enterprise counterpart	What carries over unchanged	What tightens
a user with a persona	a tenant (a customer organization, or a business unit)	keyed profile facts, one context pack per turn	identity comes from the tenant's own directory, not a sign-up form
a segment choosing a tone template	a policy (tone, allowed topics, allowed tools, disclosure rules)	template chosen before the model is called, not after	policies are versioned, reviewed and signed off, not A/B tested silently
a memory namespace per user	the tenant data boundary	retrieval never crosses the boundary; write-back lands inside it	the boundary also pins where the data lives (residency) and who can read it (roles)
an eval run against a golden set	compliance evidence	the regression gate on every deploy	the run is retained, dated and attributable — an auditor can ask for it
the HPA reconcile loop	capacity SLAs per tenant	desired-state autoscaling on load	a tenant may buy a floor (reserved capacity) and a ceiling (a spend cap)
a persona's tone template	brand voice	tone is a first-class, testable dimension	one voice per brand, legally reviewed phrasing for regulated topics
consumer abuse limits (rate limits, caps)	entitlements (what this contract paid for)	the same counters, the same enforcement point at the edge	limits are contractual, per tenant, and reported back on an invoice
async write-back to memory	a record of processing	off the hot path, idempotent	every write is attributable to a turn id and a human or system actor
a canary rollout	change management	traffic split, watch the SLO, roll back	a change window, a named approver, a rollback plan on file

🪤 Misconception — "enterprise AI is a different product category." It is the same request path. A bank's advisor assistant and a consumer companion both do: guardrail in, session, query rewrite, profile lookup, retrieval inside a namespace, budgeted context pack, agentic loop, generate, guardrail out, write-back. The bank adds a human approval step and a retention rule at two of those seams. That is a configuration of the chassis, not a new chassis.

What does the chassis look like with the constraints layered on?

The diagram below is the same picture drawn in the fleet chapter — edge, stateless workers, shared stores, a control plane — with the five enterprise constraints attached to the seam each one actually touches.

flowchart TB
  IDP["Identity · SSO / directory"] --> EDGE["Edge · auth, entitlements, rate limits"]
  EDGE --> W["Stateless workers (the fleet)"]
  W --> PACK["Context pack · profile ⊕ policy ⊕ top-K"]
  PACK --> MODEL["Model service · routing, tiering"]
  MODEL --> HITL["Human-in-the-loop gate (regulated actions)"]
  HITL --> OUT["Answer · streamed, output guardrail"]
  W --- NS["Tenant namespace · region-pinned store"]
  W --- AUDIT["Audit trail · every turn, every tool call"]
  CP["Control plane · reconcile per tenant SLA"] -. scales .-> W
  COST["Per-tenant cost meter"] -. reads .-> AUDIT
  EVAL["Eval gate = compliance evidence"] -. blocks deploys .-> MODEL

Read it as five overlays on four familiar boxes:

Identity (SSO) replaces the sign-up form. The edge trusts the tenant's identity provider and turns the assertion into the keyed lookup the context pack already needed.
Data residency is a property of the memory namespace. The namespace was already the privacy boundary (see Trust); now it also carries a region, and the router sends the turn to the workers that sit next to that region's store.
Audit is the turn-id trail from Quality, retained longer and made queryable per tenant.
Human-in-the-loop is a gate placed between the agentic loop and the outbound stream for a listed class of actions — nothing else in the loop changes.
Per-tenant cost is token accounting with one more tag on every record.

What changes, and what does not?

What changes (the constraints):

Residency — a tenant's namespace, its embeddings, its audit records and its backups stay in a named region; the fleet is sharded by region before it is sharded by load.
Audit — every turn, retrieval, tool call and approval is written with actor, time and tenant, retained for a contractual period, exportable on request.
Human-in-the-loop — for regulated or irreversible actions the model proposes and a person disposes; the answer is held, not streamed, until the approval lands.
Identity and SSO — users arrive via the tenant's directory; roles decide which tools, which documents and which policies apply.
Per-tenant cost and SLAs — capacity floors, spend ceilings, and a latency SLO that is a contract term, not an internal target.
Policy review — tone templates and allowed-topic lists become versioned artifacts with an owner.

What does not change (the chassis):

A turn is still a context pack assembled per request from keyed facts, a template and top-K recall.
Workers are still stateless; scale is still more replicas pulling from shared stores.
The control plane still runs the same reconcile loop toward a desired state — the desired state now has per-tenant terms in it.
Quality is still gated by an eval run against a golden set; empathy (now "brand voice") is still scored.
Guardrails still sit on the way in and the way out; secrets still never enter a prompt.
Observability is still SLOs, an error budget and a per-turn cost line.
The bill is still tokens, so model routing and tiering matter exactly as much.

⚠️ Pitfall — treating audit as a log file. A log is what the system happened to print; an audit trail is what an outside party can reconstruct a decision from. If the retrieved chunk ids, the policy version and the model version are not on the same record as the answer, the trail has a hole precisely where a regulator will look.

Scenario one: a bank's advisor assistant

A retail bank gives its financial advisors an assistant that drafts client-ready answers about products, rates and a client's own holdings. It is regulated: some statements need a licensed human's sign-off before a client sees them, and every recommendation must be reconstructible for years.

sequenceDiagram
  participant A as Advisor (SSO)
  participant E as Edge
  participant W as Worker
  participant M as Model
  participant H as Approval queue
  participant L as Audit trail
  A->>E: "Draft a rebalancing note for client 4471"
  E->>W: identity + role + tenant policy
  W->>W: context pack (client facts · bank policy · top-K)
  W->>M: generate (tiered model)
  M-->>W: draft + citations
  W->>L: turn id · chunks · policy v · model v
  W->>H: hold — regulated advice
  H-->>A: licensed reviewer approves / edits
  H->>L: approval · reviewer id
  A-->>A: client receives the approved note

🔍 See it happen — one advisor turn, end to end

The request. An advisor signs in through the bank's directory. The edge maps the assertion to a keyed identity: advisor id, branch, licence class, tenant = the wealth division. Entitlements say this role may use the holdings and product-sheet tools, and may not use execute-trade.

The pack. The worker assembles the context pack: the client's keyed facts (risk profile, holdings — exact, never left to similarity), the tenant's policy template (tone: formal, plain-language, no performance promises; disclosures required on certain product classes), and top-K retrieval from the division's namespace — which lives in the bank's home region and nowhere else.

The loop. The model calls the holdings tool, reads the product sheet, drafts a note with citations. A sketch of what gets recorded:

TEXT

turn 8f21 · tenant wealth-eu · advisor 1093 · client 4471
policy v14 · model tier-2 · chunks [c88, c91] · tools [holdings, product_sheet]
verdict: REGULATED → hold for approval

The gate. The output guardrail classifies the draft as regulated advice. Instead of streaming, the worker parks the draft in an approval queue. A licensed reviewer sees the draft, the citations and the policy version, edits one sentence, approves. The approval — reviewer id, timestamp, diff — is appended to the same turn id.

The scale question. Advisors work business hours in one region; the control plane's desired state for this tenant has a reserved floor during those hours and scales to near zero at night. The bank's SLA is a p95 on draft ready, not on client sees it, because the human step is outside the system's control — the SLO is written around the seam the machine owns.

Scenario two: a retailer's support agent

A retailer runs a customer-facing support agent. It answers order questions, tracks parcels, and can issue refunds — but a refund is money leaving the company, so it sits behind a gate. Traffic is wildly seasonal: ten times the load in the last week of the year.

flowchart LR
  C["Customer"] --> G["Guardrail in"]
  G --> P["Context pack · order facts ⊕ brand voice ⊕ FAQ top-K"]
  P --> LOOP["Agentic loop"]
  LOOP --> T1["tool: track_parcel"]
  LOOP --> T2["tool: issue_refund"]
  T2 --> GATE{"amount ≤ limit and policy match?"}
  GATE -- yes --> AUTO["auto-approve · log"]
  GATE -- no --> HUMAN["agent queue · human decides"]
  T1 --> ANS["Answer · brand voice · output guardrail"]
  AUTO --> ANS
  HUMAN --> ANS

🔍 See it happen — a refund request in peak week

The request. A customer, signed in through the retailer's own account system, writes "my order arrived broken, I want my money back." The edge attaches customer id and tenant = the retailer's consumer brand; entitlements for a customer role allow track_parcel and issue_refund but cap refund value.

The pack. Keyed facts: the order, its items, delivery date, prior refunds this quarter. Brand voice template: friendly, short sentences, apologise once, never argue. Top-K from the support namespace: the damaged-goods policy and the returns FAQ.

The loop. The model calls track_parcel (delivered three days ago), then proposes issue_refund for the item's value. The tool gate evaluates two things before anything moves: is the amount under the role's cap, and does the case match the damaged-goods policy retrieved into the pack? Both true — the refund is issued automatically and the turn id, policy version and amount are written to the audit trail. Had the amount been over the cap, or a third refund in a month, the same tool call would have landed in a human agent's queue with the draft reply attached.

The scale question. This is the week the control plane earns its keep. Desired state is driven by queue depth and concurrency, not by a user ratio; the fleet scales out ahead of the morning wave and back in at night. The model tier drops one notch for FAQ-style turns to hold cost, and the eval gate runs a peak-week golden set (returns, delays, damaged goods) before any change ships in December.

🎯 At consumer scale, a lab with 100M weekly users has already solved the hard version of every one of these constraints — isolation without per-user servers, cost without per-user budgets, quality without per-user reviewers. That is why the enterprise mapping is a narrowing, not a rebuild: the enterprise system serves fewer people with more rules, on a chassis that was designed for more people with fewer rules.

What should a designer take from this?

Three habits transfer directly. First, name the boundary before the model: decide what a tenant is, where its namespace lives and who may read it, and the rest of the design falls into place around that line. Second, put every constraint at a seam that already exists — identity at the edge, residency on the namespace, approval between the loop and the stream, cost on the turn record — rather than inventing new components for each. Third, keep the eval gate honest: an enterprise will ask for the evidence, and the only evidence that means anything is a dated run against a golden set the tenant helped write.

🧭 Enterprise mapping — the reverse direction. Enterprises return the favour. Human-in-the-loop queues, retained audit trails and versioned policies are exactly the tools a consumer lab reaches for when a class of answers turns out to need review — medical, legal, financial. The chassis is symmetric: what a bank bolts on by contract, a consumer product bolts on by risk appetite.

Continue to the reference architecture to see one concrete build of this chassis, or back to Trust for the guardrails the enterprise constraints sit on top of. Terms used here — tenant, data residency, human-in-the-loop, entitlement — are in the glossary.