A platform, by definition, serves more than one customer. The moment it does, a new property dominates every design decision: isolation. One tenant must never see another's data, exhaust another's capacity, or be exposed to another's failure — and yet pooling resources across tenants is the only way the economics work. Multi-tenancy is the discipline of getting that trade-off right, separately, at every layer of the stack.

26.1 The isolation spectrum: silo, pool, bridge

Isolation is not one switch. For each resource you choose where to sit on a spectrum. At one end, the silo model gives every tenant dedicated infrastructure — strongest isolation and simplest blast-radius story, but linear cost and operational sprawl. At the other, the pool model shares one set of resources across all tenants, separated only logically — radically more efficient, but every shared component is now a potential cross-tenant leak and a shared failure domain. The bridge model mixes the two per resource: pool the stateless, cheap-to-share layers (compute, the gateway) and silo the dangerous or regulated ones (data, encryption keys), or tier it by plan so premium tenants get dedicated capacity. The right architecture is almost always a bridge, decided resource by resource rather than globally.

26.2 Isolation is a decision at every layer

Tenancy is not a feature of one component; it is a property the whole stack must carry. Data — separate by a row-level tenant_id with database row-level security, a schema per tenant, or a database per tenant as isolation needs rise; vector and graph stores get per-tenant namespaces or collections; sensitive tenants get their own encryption key (customer-managed keys make a leak cryptographically impossible across tenants). Identity — the tenant is part of every principal, encoded in the SPIFFE ID or OAuth claims (Ch. 15), so authorization is tenant-aware by construction. Compute — sandboxes are per-tenant (Ch. 9, 24) and mesh namespaces segment traffic (Ch. 23). Policy — each tenant can carry its own OPA policy and configuration (Ch. 17). Cost and rate — per-tenant quotas and budgets, enforced as bulkheads (Ch. 20, 21). Observability — every span, metric, and log line is tagged with the tenant (Ch. 18), or you cannot attribute cost, debug a tenant, or honour a deletion. Miss the tenant dimension in any one of these and you have a leak or an un-attributable cost waiting to surface.

26.3 Noisy neighbours and fairness

Pooled capacity creates the noisy-neighbour problem in its sharpest agentic form: one tenant's runaway loop or aggressive fan-out can consume the shared inference floor (Ch. 21) and starve everyone else. Classic rate limiting is necessary but blunt. The platform needs fairness: per-tenant concurrency limits and token budgets so no tenant exceeds its share; bulkheads (Ch. 21) that isolate each tenant's resource pool so one tenant's saturation cannot drain the whole system; and priority tiers so a premium tenant's traffic is scheduled ahead of best-effort load when capacity is scarce. The durable engine's queue (Ch. 4) becomes the place fairness is enforced — admit and schedule per tenant, rather than first-come-first-served.

26.4 Tenant-aware configuration

The corollary of per-tenant policy and limits is that almost everything becomes configurable per tenant: prompts, enabled tools, model choice and routing, guardrail strictness, data-residency region, budgets, and feature flags. The clean design is a tenant registry in the control plane that resolves a tenant's full configuration at request time, so a single shared data plane behaves differently per tenant from one source of truth — rather than forking the deployment per customer. This is the same control-plane/data-plane separation of Chapter 3, now with the tenant as the key.