A reference architecture for the business-integration layer of an LLM-native platform on AWS — single-table multi-tenancy, domain-routed tenant resolution, a unified lead pipeline, role-permissioned client dashboards, and synchronized billing — the layer that turns AI capability into a product many clients run on one platform.
Abstract
Layer 5 is the business-integration layer of an LLM-native systems architecture — the layer that turns AI capability into a running, multi-tenant product. It is single-table multi-tenancy with isolation by construction, domain-routed tenant resolution, a unified pipeline that captures and attributes every lead across a fleet of client sites, role-permissioned dashboards where each client sees only its own data, subscription billing wired in as infrastructure, and integration with the tools clients already run. The model layer is commoditized; the integration layer that makes one platform serve many businesses — each isolated, billed, and reporting on its own terms — is where the architecture meets the org chart.
This is a reference-architecture paper in the same series as *Layer 3: Data + Retrieval*, the companion paper on caching and model routing, and *Layer 4: Reliability Engineering*. It documents the top of the stack — the layer where a working AI capability becomes a product that clients pay for and operate.
The intended reader is technical and accountable for shipping a multi-tenant AI product: a CTO, a VP of Engineering, or the architect who has to make one platform serve many clients without their data, their mail, their dashboards, or their invoices ever crossing. The argument is that the hardest part of productizing AI is not the model — it is the integration layer that turns one capable system into a hundred isolated businesses.
1. What Layer 5 Is
Layer 5 is business integration — APIs, internal tools, multi-tenant networks, and billing. It is the layer where a working AI capability becomes a product: many clients served by one platform, each isolated from the others, each seeing only its own data, each billed and reporting on its own terms. The engineering problem is not "can the model do this" but "can one system serve a hundred businesses without their data, their mail, their dashboards, or their invoices ever crossing."
A demo answers a narrow question: can the model do X for one client. Layer 5 answers a different and harder one: can we run X for a hundred clients, across different verticals, on one platform — with isolation, billing, reporting, and integration that all hold at once.
That is an organizational problem as much as a technical one. A single tenant's deployment is a system; a hundred tenants on one platform is a *business*, and the business has requirements the model never sees: client A must never glimpse client B's data, each client's notification mail must look like it came from that client, each client's dashboard must show only that client's world, each client's subscription must bill correctly, and each client's existing tools must keep working.
The rest of this paper is how one network meets all of those at once.
2. One Network, Many Tenants
Multi-tenancy done right is isolation by construction, not by convention. A single data store keys every record by tenant — the partition key *is* the tenant identity — so a query for tenant A cannot return tenant B's rows by the shape of the key, not by a filter that a bug could skip. Every request resolves to exactly one tenant through a cascading auth chain (OAuth token, API key, signed session), and the resolved tenant scopes every read and write. The infrastructure is shared; the data plane is not.
The cheapest multi-tenancy filters by tenant at the application layer — every record sits in a shared space, and a WHERE tenant = X clause keeps them apart. The problem is that a clause is a thing a bug can omit, and the day it does, one client sees another's data. Isolation that depends on remembering to filter is not isolation.
Tenant in the partition key. The architecture keys every record on the tenant identity itself: a tenant's profile, its users, and its captured leads all live under one partition key derived from the tenant. A query for tenant A literally addresses tenant A's partition; it cannot return tenant B's rows, because it never reaches B's partition. Isolation is a property of the key, not of a clause.
This is the multi-tenant data-isolation pattern the AWS Well-Architected SaaS Lens treats as foundational, applied on a single table.
One resolved tenant per request. Moreover, every inbound request resolves to exactly one tenant through an ordered auth chain — an OAuth access token, an API key, a signed session token, or an authenticated session cookie — with an explicit admin override for cross-tenant support. Whatever the entry point, the request arrives carrying one tenant identity, and that identity is the scope for everything downstream.
Shared infrastructure, isolated data plane. One platform, one table, one deployment — and a hundred isolated tenants on top of it. The shared substrate is what makes the economics work; the per-tenant keying is what makes it safe. Both at once is the point.
3. Domain-Routed Tenant Resolution
A single platform serving many client domains needs to map an inbound host to a tenant. A curated domain-to-tenant map resolves each production domain — and its staging alias — to a tenant, and a companion map resolves a tenant back to its canonical domain for outbound work. One deployment answers for every client site, and the host is what selects the tenant. The map is curated rather than dynamically discovered, so onboarding a client is an explicit, auditable change.
When one platform backs many client-facing sites, something has to decide which tenant an inbound request belongs to before any data is touched. Host-based routing does it: the request's domain selects the tenant.
The map. A curated map resolves each host — a client's production domain, its staging alias, and localhost for development — to a tenant. The inbound host is normalized and looked up; the result is the tenant for that request. A companion map runs the other direction, resolving a tenant back to its canonical production domain for outbound work — tool calls, links, and anything that needs to address the client's site rather than receive from it.
Curated, by design. That said, the map is explicit rather than dynamically discovered, and that is deliberate. The client roster is known and changes on purpose; a curated map is auditable and predictable, and adding a client is a reviewed change rather than an implicit discovery that could mis-route a request to the wrong tenant. At a layer where mis-routing means one client's traffic landing in another's data, predictability beats cleverness.
This is what lets one platform — one codebase, one deployment — answer for a fleet of distinct client domains, each request landing in exactly its own tenant.
4. The Unified Lead Pipeline
At network scale, the right place to capture conversions is once, centrally — not per site. A first-touch attribution pixel stamps the traffic source on every visitor; each client site's thin form proxy forwards submissions to a single ingest endpoint that resolves the tenant, parses attribution, enriches with AI-crawler signal, scores the lead, writes it atomically with a daily rollup, enforces a per-tenant rate cap, and strips PII for regulated tenants — all in one call. Notification mail sends from one managed sender with each tenant's own recipients and branding.
Doing lead capture per-site does not survive a fleet. Every site would need its own verified email domain, its own DKIM and SPF, its own storage, and its own notification logic — multiplied by every client, maintained forever. The architecture that scales centralizes the pipeline and keeps only the thinnest possible client at the edge.
First-touch attribution at the edge. A lightweight pixel on each client site sets a first-touch source cookie — source, medium, campaign, click identifier, and landing page, detected in priority order (campaign parameters, then ad click ID, then AI-engine referral, then ordinary referrer, then direct) and held for thirty days. The attribution rides with the visitor so that whenever they convert, the origin of the relationship is already known.
Thin proxy, one endpoint. Each client site runs a thin form proxy: it validates input, runs spam checks, reads the attribution cookie, and forwards the submission to a single authenticated ingest endpoint. That one endpoint serves every client site — and the AI concierge widget — through the same path.
One call does the work. On receipt, the endpoint resolves the tenant, parses the attribution, enriches the lead with AI-crawler signal (whether an answer engine recently crawled the converting page — a Layer 5 read on a Layer 3 signal), scores it against the tenant's optional fit rules, and performs an atomic write: the lead record and a daily rollup counter together, so the feed and the analytics can never disagree.
A per-tenant daily rate cap bounds abuse, and for a regulated (medical) tenant the stored record is PII-stripped — name, email, and phone nulled — before it is written.
Centralized sender, per-tenant identity. Notification mail goes out from one platform-managed sender, but each tenant configures its own recipients, from-name, and subject line — so the client receives branded, correctly-routed notifications without standing up any email infrastructure of its own. (This is centralized sending with per-tenant configuration, not a separate mail identity per client — the operational simplicity is the point.) For the regulated tenant whose stored record was stripped, the notification still carries the contact details to the practice, so capture stays compliant while follow-up stays possible.
5. Permissioned Client Dashboards
In a multi-tenant product, every client touches the same application but sees only their own world. A role matrix maps each role — owner, member, billing, admin — to the set of modules it may open, enforced at render and at the API; and every query is scoped to the resolved tenant's partition, so a client cannot see another's data even by guessing a URL. The dashboard is one application; the view is per-tenant and per-role.
A multi-tenant dashboard has two isolation jobs at once: keep tenants apart, and keep roles within a tenant apart. Both run on the same principle as the data layer — enforcement by construction, not by hiding a button.
Role-to-module matrix. Each role maps to a defined set of modules it may open. An owner sees the operational and billing modules; a member sees the operational modules but not billing or internal support; a billing-only role sees billing, account, and the home view and nothing else; an admin sees everything.
The mapping is checked both when the navigation renders and at the API, so a hidden module is also an unreachable one — removing the link is never the only thing standing between a role and a capability.
Tenant isolation in every query. Every dashboard query is keyed to the resolved tenant's partition — the same key-shape isolation as the data layer. A client's leads, analytics, content, and tickets are addressable only under its own tenant key, so no cross-tenant data reaches the UI or the API, even if a URL is guessed or an ID is forged. The client sees its own world because its own world is the only world its requests can address.
Admin support without breaking the model. Even so, an administrator can switch tenant context to support any client, scoped by an explicit override — so support is possible without weakening the isolation that every client relies on. The override is the seam where one team can see across tenants; for clients themselves, there is no such seam.
6. Billing as Infrastructure
Billing in a multi-tenant product is not a bolt-on; it is a synchronized system. Subscription state lives on the tenant and is kept current by idempotent webhooks: each provider event — create, update, cancel, trial-ending, payment-succeeded, payment-failed — updates the tenant's status, deduplicated by event ID so a redelivered webhook is a no-op, with a customer-to-tenant lookup that tolerates events arriving before the link is set. The client sees its own subscription status, renewal date, and plan.
Billing is where a lot of multi-tenant products get sloppy, because the payment provider is the source of truth and the temptation is to query it on demand and move on. At scale that breaks: webhooks arrive out of order, get redelivered, or land before the local record that should receive them exists. Billing has to be treated as a stream to reconcile, with the same discipline as any other.
Idempotent webhook sync. The subscription lifecycle — created, updated, deleted, trial-will-end, payment-succeeded, payment-failed — maps to updates on the tenant's stored status (active, past due, canceled, trialing, and so on). Every event is deduplicated by its identifier with a retention window, so a redelivered or replayed webhook is a safe no-op — the duplicate-handling discipline Stripe's webhook guidance names as a best practice.
A customer-to-tenant reference resolves which tenant an event belongs to, and events that arrive before that link is established are buffered rather than dropped. The result is a billing state that survives the messy reality of webhook delivery.
State the client can see. The billing module surfaces the tenant's own subscription status, its renewal date, any scheduled cancellation, and its plan — the client's billing standing, visible to the client.
Why infrastructure, not a bolt-on. After all, billing events are just another stream the multi-tenant platform reconciles, with the same idempotency and per-tenant keying as everything else. Treating subscription state as synchronized infrastructure — always current, always reconcilable — is what keeps the commercial layer as reliable as the technical one.
The discipline here is the reconciliation, not a claim that every request is gated at the turnstile; the system always knows each tenant's standing, which is the property the business actually needs.
7. Integrating the Client's Own Stack
A multi-tenant AI platform has to meet clients where their tools already are. Per-tenant, opt-in integration mirrors captured leads into the client's own CRM — when a tenant configures its CRM credentials, every lead is forwarded to that CRM in addition to the platform's own store, non-blocking so a CRM outage never drops a capture. The platform owns the AI and the capture; the client keeps their CRM as the system of record. Integration, not replacement.
The fastest way to lose a mid-market or enterprise client is to ask them to abandon the system of record they already run. A serious integration layer does the opposite: it plugs into the client's existing stack and feeds it.
Per-tenant, opt-in CRM mirroring. When a tenant supplies its CRM identifiers, every lead the platform captures is also forwarded to that CRM — the client's own system of record receives the lead with full detail, because it is the client's data in the client's tool. The forward is non-blocking: a CRM outage or a rejected submission is logged and never fails the capture, so the platform's own record is always written even when the downstream integration is down.
The boundary. The platform owns the AI, the capture, and the cross-network intelligence; the client keeps their CRM as the system of record. This is integration, not replacement — the client's existing investments keep working, and the AI layer makes them better rather than demanding they be torn out.
Regulated dual-write. For a regulated tenant that opts in, a parallel record can carry full detail to the client's own controlled system, while the platform's own store stays PII-stripped. The client's compliance boundary is respected on both sides: the platform holds only what it should, and the client's system of record holds what the client is entitled to hold.
8. Why Business Integration Is the Layer That Ships
Layer 5 is where AI capability becomes a business. The model, the retrieval, the cost controls, and the reliability engineering are all upstream of the question a buyer actually pays to answer: can one platform run my business's AI alongside a hundred others, keep my data and mail and dashboards and billing entirely my own, and plug into the tools I already use. That is multi-tenant business integration, and it is the layer that turns architecture into a product.
Every layer below this one makes the AI good. Layer 5 makes it a business — and the two are not the same achievement.
Indeed, the convergence is that per-tenant keying is both the isolation boundary and the cost boundary at once. The same partition key that keeps client A's data away from client B is what lets one shared platform serve them both — multi-tenant economics and multi-tenant safety from the same design.
Domain routing, the unified pipeline, role-scoped dashboards, reconciled billing, and CRM integration are the machinery that lets one small team operate a fleet of client deployments without the per-client overhead multiplying out of control.
This is what a mid-market or large-enterprise buyer is actually buying. They are not buying a model — they assume the model is good. They are buying a system that runs their AI as a product: isolated from every other client, billed correctly, reporting on its own terms, and wired into the tools they already use.
We apply this discipline across a client base that runs from mid-market to large enterprise, and the integration layer is what lets one platform carry all of them at once.
Layers 1 through 4 make the AI capable, reliable, and affordable. Layer 5 makes it a business. The model layer commoditizes; the integration layer that serves many tenants without their worlds ever crossing is the part that compounds — and the part a serious firm owns.
Companion Papers
This is a reference-architecture paper in a series across the layers of an LLM-native system:
- Private LLM Architecture for Mid-Market Healthcare on AWS Bedrock *— shipped.* Model isolation and compliance in a HIPAA workflow.
- Layer 3: Data + Retrieval *— shipped.* Pipelines, permissioned retrieval, hybrid search, context engineering, memory, and feedback loops.
- Keeping AI Spend Flat: Caching and Model Routing *— shipped.* The cost-and-latency half of Layer 4: prompt caching, per-task routing, cheaper defaults, and spend observability.
- Layer 4: Reliability Engineering for Regulated AI *— shipped.* Guardrails, atomic integrity, investigate-only audit, circuit breakers, retries, and quality gates.
- *Layer 5: Multi-Tenant Business Integration* *— this paper.* Single-table multi-tenancy, domain routing, the unified lead pipeline, permissioned dashboards, and synchronized billing.
Conclusion
Productizing AI is mostly an integration problem, not a modeling one.
Layer 5 is the layer that solves it: single-table multi-tenancy where isolation is a property of the key rather than a clause a bug can skip; domain-routed resolution that lands every request in exactly its own tenant; a unified pipeline that captures, attributes, scores, and routes every lead across the fleet in one call; role-permissioned dashboards where each client sees only its own world; billing kept current as synchronized infrastructure; and per-tenant integration that feeds the client's own system of record rather than replacing it.
The layers below make the AI good; this one makes it a product clients pay for and operate.
Notices
Not legal, compliance, or financial advice. This paper is for informational purposes only. Architectural decisions in regulated and multi-tenant workflows require qualified counsel and a formal review.
Implementation details vary. The architecture here is a reference pattern drawn from production systems; specific role sets, rate caps, retention windows, and integration points are tuned per deployment and evolve over time. Operational specifics describe representative configurations, not guarantees.
Capabilities change. AWS service capabilities and the surrounding tooling evolve continuously; verify current state before implementation.
Trademarks. AWS is a trademark of Amazon.com, Inc. or its affiliates. Stripe is a trademark of Stripe, Inc. HubSpot is a trademark of HubSpot, Inc. References are descriptive and do not imply endorsement.
About the author. Joe Elstner is the founder of iSimplifyMe, a Chicago-headquartered AI infrastructure firm operating since 2011 across North America and Asia-Pacific. iSimplifyMe is bootstrapped, deploys production AI on AWS, and runs a multi-tenant orchestration platform across healthcare, legal, financial, and editorial verticals.
Contact. apex@isimplifyme.com — for engineering teams building a multi-tenant AI product, we offer a multi-tenant architecture review at no cost.
Cite this paper. Elstner, J. (2026). *Layer 5: Multi-Tenant Business Integration.* iSimplifyMe Whitepaper. https://isimplifyme.com/whitepapers/layer-5-business-integration