Mental model
The model is one probabilistic component inside a deterministic product system. Application code owns identity, authorization, state, policy, side effects, validation, observability, and recovery.
Theory
Begin at the user-visible task and trace the request across trust boundaries. The interface captures intent and displays progress, evidence, uncertainty, and control. The API authenticates identity, authorizes resources, validates inputs, assigns request IDs, and applies budgets. Orchestration selects context, retrieval, models, and tools. Post-processing validates contracts and policies before results or side effects reach the user.
Treat state by lifetime: request state, conversation state, user preferences, durable business records, and evaluation evidence. Keep provider adapters behind typed interfaces so model changes do not leak across the product. Emit correlated telemetry for every stage and define degraded behavior when retrieval, tools, or providers fail.
Alternatives and trade-offs
A single provider SDK inside one server route is appropriate for a low-risk prototype. Layered modules become necessary as policy, testing, providers, and teams grow. Microservices can isolate scale and ownership but increase latency and distributed failure. Prefer modular boundaries before network boundaries.
Failure modes and misconceptions
Putting authorization in a prompt is unsafe. Storing all state in conversation history creates privacy and freshness problems. Provider exceptions exposed directly to clients make recovery brittle. Treating model output as trusted HTML, commands, or database input creates injection paths. A successful API response is not the same as a successful user task.
Knowledge check
Which responsibilities must remain in deterministic application code even when the model appears capable of handling them?
Decision scenario
A support product uses a streaming web client, authenticated API, tenant-scoped retrieval, typed account tools, independent authorization, result validation, evaluation gates, and one correlated trace. A provider outage falls back to search-only support without hiding degraded mode.
Learning outcomes
- Explain Full-Stack AI Systems as a system mechanism rather than a slogan.
- Compare its alternatives, trade-offs, and production failure modes.
- Apply the concept to a decision and identify evidence that would validate it.
Trade-offs
Using Full-Stack AI Systems can improve capability or control, but it also introduces cost, latency, complexity, and failure modes that must be measured against an explicit objective.