Frontend
Collect user intent, show authoritative state and corrections.
Library / 03 AI Systems & Technical Fluency
Reviewed Oct 2026Anatomy of an LLM Application
The model is one component. Software around it owns the consequences.
01 / flow
A trustworthy request path
User / frontendBackend orchestrationTrusted contextModel interpretsValidation + rulesHuman authorizationDurable state
02 / cards
Responsibilities
Backend
Coordinate security, context, tools, validation and data.
LLM API
Interpret ambiguity, draft, classify and summarize.
Application logic
Enforce mechanical invariants, permissions, retries and transitions.
Database
Persist evidence, state, history, and provenance.
Human
Approve material changes and policy exceptions.
03 / table
Three crucial concepts
| Concept | Practical meaning |
|---|---|
| Context construction | Supply smallest sufficient reliable context |
| Structured output | Constrain fields for downstream machine handling |
| Validation | Check types, references, permissions, and allowed combinations |
04 / flow
Evidence through the system
Save original evidenceAssemble trusted contextInterpretValidateReview if neededApply transition
05 / list
Design for mistakes
- Preserve source evidence unchanged
- Keep source separate from interpretation
- Schema-valid does not prove semantic truth
- Use software for mechanical facts
- Show provenance and reversible history
- Fail safely when the model is unavailable
GOING DEEPER
Authority and interpretation are different
What a model response does not prove
| Output | What remains to verify |
|---|---|
| Schema-valid JSON | Fields, values and references have permitted meanings; downstream logic is still correct |
| Well-grounded proposal | It is not necessarily accepted Current State |
| A newer source exists | It may qualify prior truth without itself being reviewed or approved |
| The model explains a change | The application still checks authorization, permitted transitions and durable persistence |
Current State vs repeated reconstruction: For normal questions about current facts, use the maintained authoritative Current State rather than asking the model to infer truth from raw historical evidence every time. Keep source evidence immutable and distinguish it from interpretation, pending proposals and accepted state.
Possible stale state: If an unresolved Review could make maintained state stale, present the established fact with a visible qualification. Never silently promote the proposal to accepted truth. The model interprets; software enforces; people authorize consequential transitions.
PRACTICAL FRAMEWORK / AI PRODUCT WORK
Standing AI workers: eight operating decisions
A persistent agent is an ongoing workflow, not just a longer prompt. Scope these eight responsibilities before granting unattended operation.
01 · Goal
Which outcome owns it?
02 · Context
What may it remember; which facts are authoritative?
03 · Tools
What systems can it read or use?
04 · Authority
What may it change; what needs approval?
05 · Execution
How does it resume, stop and retry safely?
06 · Observation
What evidence, actions and state can a person inspect?
07 · Evaluation
How are task and process quality tested?
08 · Intervention
Who can correct, pause or take over?
Expiry matters: permissions suitable for a five-minute task can be excessive for a standing worker. Define renewal and revocation.