A Structured Framework for AI System Design

AI Engineer2026-06-28go watch the original →

the gist

Moving AI systems to production requires a four-phase framework: defining product requirements, designing architecture, establishing evaluation guardrails, and optimizing for cost and latency.

The Four-Phase Design Framework

Building production-grade AI systems requires moving beyond "just ship it" to a structured approach. The process is divided into four distinct phases: product requirements, system design, evaluation and monitoring, and optimization.

Defining Requirements and Success Metrics

Before selecting an architecture, define the business problem in a solution-agnostic way. A strong problem statement identifies the specific user, the current baseline performance, and the pain point. For example, in a health insurance claims review system, the goal is to reduce processing time from two days to one hour within 90 days. Constraints must be identified early, including regulatory compliance, data residency requirements, and human-in-the-loop mandates. The role of AI should be classified by criticality (is it core or complementary?), interaction style (reactive or proactive), and autonomy level.

Architecture and Data Strategy

Avoid over-engineering by starting with the simplest possible design. For a claims review system, the architecture involves:

Data Processing: Chunking long documents like clinical guidelines, embedding them, and extracting metadata for retrieval. Patient history stored in databases like MongoDB requires PII removal before LLM ingestion.
Retrieval Strategy: Use hybrid search or vector search with metadata pre-filtering for unstructured documents (guidelines/policies) and exact-match lookups for structured patient identifiers.
Design Patterns: Implement a control flow pattern where the LLM provides recommendations based on retrieved context, with an escalation path to human reviewers for complex cases or denials.

Evaluation and Guardrails

Because LLMs are probabilistic, guardrails are mandatory to ensure system reliability.

Input Guardrails: Filter out irrelevant or harmful requests (e.g., rejecting "write me a poem" in a claims system).
Output Guardrails: Enforce structural requirements, such as requiring citations for every approval or denial verdict.
Metrics: Track faithfulness (whether the output is rooted in retrieved context), missing citation rates, and domain-specific KPIs like average processing time. Once in production, monitor human override rates as a proxy for system accuracy and user trust.