Platform Architecture
Split enterprise AI systems into experience, control, runtime, async, and governance planes.
Written and reviewed by Eric Han · Co-founder & CTO, reopt
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.
Current execution contract: Node.js and Fluid Compute
New Node.js projects default to 24.x; the documented choices are 24.x and 22.x. Streaming and SSE work on Node.js. Next.js 16.3+ routes and pages no longer support runtime = 'edge'.
| Item | Current boundary |
|---|---|
| Function duration | 300s default; Hobby 300s max; Pro/Enterprise normally 800s max |
| Extended duration | 1,800s on Pro/Enterprise is Beta and has additional requirements |
| Large bundles | 5 GB support is Beta; verify opt-in and ordinary limits separately |
| Request/response body | 4.5 MB; route larger files through direct upload flows |
| Workflow selection | Durable resume, step retries, external events, or approval waits |
Choose Workflow by persistence requirements rather than an arbitrary ten-second threshold. Increasing a request timeout does not supply recovery or side-effect idempotency.
Node.js versions · Edge→Node.js · Functions limits.
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.