Platform Architecture
Split enterprise AI systems into experience, control, runtime, async, and governance planes.
Key takeaways
- A model call inside a route handler is not a platform; it becomes one when control, runtime, data, and governance responsibilities are separated.
- The architecture splits into experience, control, agent, tool runtime, async, and governance planes, each with a distinct failure impact.
- Keep request-response work small and resumable, and put model routing and provider policy behind a control plane.
- Isolate risky tools from the application runtime and use queues for bursty or batch work.
- Attach observability from the first production experiment.
Enterprise AI architecture starts by naming boundaries. A model call inside a route handler is not a platform; it becomes a platform when control, runtime, data, and governance responsibilities are separated.
Platform Planes
| Plane | Responsibility | Failure impact |
|---|---|---|
| Experience | UI, auth context, streaming response | Poor user experience |
| Control | Model routing, policy, cost, fallback | Provider sprawl and policy drift |
| Agent | Long-running tasks and approvals | Stuck background work |
| Tool runtime | Code, file, browser, and shell execution | Data leakage or lateral movement |
| Async | Fan-out, batch, retries, rate control | Pipeline backlog |
| Governance | Logs, alerts, audit, security | Incidents become invisible |
Design Rules
- Keep request-response work small and resumable.
- Put model routing and provider policy behind a control plane.
- Isolate risky tools from the application runtime.
- Use queues for bursty or batch work.
- Attach observability from the first production experiment.