- Enterprise AI plans from model providers are good for individual productivity. On their own, they do not solve routing, company context, compliance, auditability or ownership for production systems.
- The owned intelligence layer is the part a company should control: a gateway and router, a context layer, policy and compliance controls, a reliable action layer, observability and cost, evals, and workflow integrations.
- Models stay rented and swappable. Everything that encodes how the business works, and how you know AI is doing it well, lives in your infrastructure and your repositories.
- We build it in production slices: one workflow end to end on the shared foundations, then the next workflow reuses them.
This is part 9, the last part of Enterprise AI. The previous eight parts each described one problem: paying frontier prices for routine work, missing business context, unowned intelligence, data compliance, shadow AI, vendor lock-in, pilots that never ship and missing audit trails. This part describes the one architecture that addresses all of them, and how we build it.
01What does an enterprise plan give you, and what does it not?
Enterprise plans from model providers are solid products. They typically offer strong models in a polished interface, admin controls, single sign-on, and contractual commitments on data use and retention. For people who need an assistant for open-ended work, they are often the right purchase.
What they are not designed to be is the foundation for your production AI systems:
| Need | Enterprise chat plan | Owned intelligence layer |
|---|---|---|
| Right model per task, cheapest that passes | One vendor's models, per seat | Routing across providers by task and eval |
| Your business context, current and permissioned | Uploaded files and connectors in the vendor's product | Your connectors, index, rules and permission model |
| Data rules enforced on every call | Vendor terms and admin settings | Classification, redaction and regional routing in your gateway |
| Reliable actions in your systems | Limited, inside the vendor's tools | Tools with effect classes, approvals, durable execution |
| Evidence of what happened | Vendor logs, vendor retention | Your audit trail, your retention, replayable |
| Switching models when the market moves | Migrate away from the platform | Change configuration, run evals |
| Who owns the capability | The vendor's product | You |
The two are not exclusive. Many companies should have both: an assistant for people, and an owned layer for systems.
02What is in an owned enterprise AI platform?
Seven components, mapped to the stack we use for every system (L0 to L5):
1. Gateway and router (L0, L2). One entry point for every model call in the company. Routes each task to the cheapest model that passes its eval, escalates hard cases, falls back across providers, and meters cost per task and team. See part 1 and the model-agnostic seam.
2. Context layer (L1, L3). Connectors to your systems of record, a current index with structure-aware chunking and hybrid search, versioned business rules, and permissions enforced before ranking. See part 2.
3. Policy and compliance (L0, L1). Data classification, redaction and minimisation, approved providers and regions per data class, retention rules. See part 4.
4. Reasoning and evaluation (L2). Prompts, schemas and evals in your repository; structured outputs validated at the boundary; evals on every change of prompt or model.
5. Action layer (L4). Tools with declared effect classes, permissions scoped to the acting user, approvals as durable waits, and durable execution so runs survive crashes and never repeat a side effect, as in KEEL.
6. Observability, cost and audit (L0). A trace for every model and tool call, cost per request and feature, and a replayable audit trail with clear retention.
7. Workflow integration (L5). Intelligence placed inside the tools people already use, with accept, edit and reject paths, and feedback captured as your data. See put the model inside the workflow.
apps & workflows (L5) ── support workbench · claims queue · CRM · internal tools
│
action layer (L4) ───── tools · effect classes · approvals · durable runs
│
reasoning & evals (L2) ─ prompts · schemas · validation · eval suites context (L1/L3)
│ connectors · index
gateway (L0) ────────── routing · fallback · policy · redaction · audit ── rules · permissions
│
model providers ─────── provider A · provider B · self-hosted (rented, swappable)03Should a company build all of this itself?
Not all at once, and not all from scratch. The decision we make with each client:
In practice the layer is assembled from good parts: managed databases and search, open-source libraries, cloud services, and custom code where your business is specific. What you own is the design, the configuration, the context, the evals and the data. That is the part that compounds.
04How do we build it?
In production slices, never as a platform project that delivers nothing for a year.
- Pick one workflow with a measurable outcome, such as triaging support tickets or extracting invoice data.
- Build the minimum foundations it needs: the gateway with routing and policy, the context for that workflow, its evals, its tools and its audit trail.
- Ship it inside the workflow, measure against the baseline, and hand it to the team that will own it.
- Take the next workflow. It reuses the gateway, the context layer and the controls, so each slice is faster and cheaper than the last.
After a few slices, the company has an AI platform that was proven one production system at a time, routes every call to the right model, knows the business, enforces its rules, records what happened, and stays the company's own as models come and go.
Rent the models. Own the intelligence. That is the whole strategy, and it is an engineering job.
05Where to go from here
If you recognise your company in this series, the most useful next step is to describe one workflow you want to make intelligent: what exists today, where it breaks, and what good would look like. That is exactly what the brief on our homepage asks for, and an engineer reads every one. To see how a platform engagement runs, phase by phase, see AI Platform.
Previous: No audit trail. Start of the series: Paying frontier prices for routine work.