Modern AI products fail less often because the model is weak than because the surrounding system is incomplete. A convincing prompt demo can be built in an afternoon; a dependable product needs contracts, observability, evaluation, fallbacks, security, and cost controls.
Start with the decision, not the model
The first architecture question is not “Which model should we use?” It is “What decision is the system making, and what happens when it is wrong?” A summarizer, support assistant, document extractor, and coding agent have completely different risk profiles even when they use the same foundation model.
Write the contract before the prompt:
- What inputs are accepted?
- What output schema must be returned?
- Which claims require evidence?
- What latency and cost budgets apply?
- Which failures can be retried, and which require a human?
This turns an open-ended generation problem into an engineering interface.
Build a deterministic shell around probabilistic behavior
Models are probabilistic. Your application does not have to be. Validate everything at the boundary and make state transitions explicit.
$result = $ai->generate(
schema: SupportDecision::class,
input: $ticket,
timeout: 8,
);
if (! $result->isValid() || $result->confidence < 0.72) {
return EscalateToHuman::dispatch($ticket);
}
Structured output, schema validation, timeouts, idempotency keys, and bounded retries are not optional polish. They are what convert model output into a safe application event.
Use a three-layer architecture
Production AI systems become easier to reason about when split into three layers.
1. Context layer
This layer assembles only the information needed for the current decision: user intent, permissions, conversation state, retrieved knowledge, and applicable policy. Context should be versioned and observable. If the answer is wrong, you need to know exactly what the model saw.
2. Reasoning layer
The reasoning layer owns model selection, prompts, structured schemas, tool definitions, and retry policy. Keep it stateless where possible. A model call should be reproducible from a captured request, even if the exact text varies.
3. Action layer
The action layer performs real work: saving records, sending messages, issuing refunds, or triggering workflows. It must enforce authorization independently. Never assume that because the model selected a tool, the action is allowed.
Evaluation is part of the product
Traditional tests still matter, but they are not enough. AI behavior needs evaluation sets built from real tasks and real failure modes.
A useful evaluation suite includes:
- Golden cases: representative inputs with expected facts or decisions.
- Adversarial cases: prompt injection, malformed context, and conflicting instructions.
- Regression cases: every important production failure becomes a permanent test.
- Operational metrics: latency, token cost, fallback rate, and human override rate.
Do not reduce quality to one score. Track groundedness, task completion, format validity, safety, and user outcome separately. A response can sound excellent while failing the actual job.
Design for model change
Models change quickly; business rules change slowly. Keep model-specific details behind an adapter and store prompt versions with every trace. This makes it possible to compare a new model against the current one on the same evaluation set before routing production traffic.
request_id → prompt_version → model_version → retrieved_context
→ structured_output → validation_result → user_outcome
This trace is the foundation for debugging and continuous improvement.
Control cost without sacrificing quality
The cheapest call is the one you do not make. Cache stable transformations, avoid sending entire histories, and route simple tasks to smaller models. Use the strongest model where ambiguity or risk justifies it, not as a global default.
A practical router considers:
- task complexity;
- required context size;
- acceptable latency;
- consequence of error;
- whether a deterministic implementation exists.
Security belongs outside the prompt
Prompts are instructions, not security boundaries. Authorization, tenancy checks, field-level permissions, rate limits, and audit logging must live in application code. Treat retrieved documents and tool output as untrusted input, and clearly separate system policy from external content.
For high-impact actions, require explicit confirmation or human approval. The system should make the safe path easy and the irreversible path deliberate.
A production readiness checklist
Before launch, confirm that the system has:
- typed inputs and structured outputs;
- prompt and model versioning;
- evaluation datasets and regression gates;
- end-to-end traces with sensitive-data redaction;
- timeout, retry, and fallback policies;
- authorization at every action boundary;
- cost and latency budgets;
- a human escalation path;
- a kill switch for automated actions.
The model is only one component. The real product is the controlled loop around it: context in, decision made, action validated, and outcome measured.