Chapter 8: AI Architecture Patterns

Ali Süleyman Topuz

“Every production AI system is built on one or more of a small number of architectural patterns. Learning to recognize those patterns is what allows a team to move from building one system to building many systems.”

Architecture as Decisions

Building a production AI system is not primarily a matter of writing code. It is primarily a matter of making decisions decisions about how information flows through the system, how the model’s outputs are used and validated, how humans remain in the loop for consequential decisions, and how the system fails when something goes wrong. These decisions, made well or made poorly, determine whether a system that works in development continues to work in production, and whether a system that works for one hundred users scales reliably to ten thousand.

Architecture patterns are the accumulated answers to these decisions, distilled from the collective experience of teams that have built similar systems and learned from both what worked and what did not. Learning to think in patterns does not constrain creativity it accelerates it. A team that recognizes the RAG pattern does not need to reinvent the retrieval-augmented generation architecture from first principles; it can spend its engineering effort on the domain-specific customization that actually differentiates their system. A team that understands the agentic workflow pattern does not need to discover through painful experience which safety constraints are essential; it starts with a principled design and adapts from there.

This chapter describes the four core architecture patterns that cover the vast majority of B2B SaaS AI use cases: the RAG system, the agentic workflow, the classification and routing system, and the structured generation system. For each pattern, the chapter describes the architecture in detail, identifies the key design decisions at each stage, describes how the pattern fails and how to design against those failures, and explains when the pattern is the right choice and when it is not. The chapter then addresses how production systems combine multiple patterns into compound architectures, how to design the evaluation layer for each pattern, and the cross-cutting principle of human-in-the-loop design that applies to all of them.

The Four Core Patterns

Before describing each pattern in detail, a brief orientation. The four patterns are not mutually exclusive production systems often combine two or more of them and they are not exhaustive. But they cover the use cases that the vast majority of B2B SaaS companies will build in the first two to three years of AI transformation, and fluency with all four is sufficient to architect most of what the roadmap will require.

The RAG system retrieves organization-specific context and uses it to ground a model’s responses. It is the right pattern when the AI system needs to know things that are specific to your organization, your product, or your customers, and when those things are too extensive or too frequently updated to include in a prompt directly.

The agentic workflow allows a model to take sequences of actions calling APIs, querying databases, running code, composing outputs in service of a goal, rather than producing a single response to a single input. It is the right pattern when the task requires multiple steps of reasoning or action, and when the steps cannot be pre-specified because they depend on intermediate results.

The classification and routing system assigns an input to a predefined category and directs it accordingly. It is the right pattern when the task is to make a discrete categorization decision reliably, at high volume, with clear categories and measurable quality.

The structured generation system uses a model to produce output in a specific format a JSON object, a structured report, a filled template that downstream systems or processes can consume programmatically. It is the right pattern when the output needs to be machine-readable, when the structure is well-defined, and when the model’s ability to reason over complex inputs and produce structured outputs adds value that a rules-based approach cannot.

Pattern 1: The RAG System

A retrieval-augmented generation system has three primary components: an ingestion pipeline, a retrieval engine, and a generation layer. Understanding each component and the design decisions it entails is the foundation for building RAG systems that work reliably in production.

The Ingestion Pipeline

The ingestion pipeline converts raw content documents, database records, support tickets, product documentation into the indexed form that the retrieval engine can search. The pipeline has four stages: document loading, chunking, embedding, and indexing.

Document loading handles the extraction of text from whatever format the source content is in PDFs, Word documents, HTML pages, database records, API responses. The challenge at this stage is handling the variety of source formats cleanly: PDFs that were created from scanned images require OCR; HTML pages contain navigation elements and boilerplate that should be excluded from the index; database records need to be formatted into text that preserves the semantic meaning of the structured data. Build the document loading stage to be extensible new source types will be added as the system evolves.

Chunking splits documents into the segments that will be indexed and retrieved as individual units. The chunking strategy significantly affects retrieval quality. Chunks that are too small lose context the relevant information may span multiple chunks, and retrieving only one of them produces an incomplete response. Chunks that are too large include too much irrelevant information, which can confuse the model during synthesis. The right chunk size depends on the nature of the content and the nature of the queries: documentation that is organized into short, self-contained sections can be chunked at the section level; long-form content that requires context from surrounding paragraphs benefits from overlapping chunks that share content at their boundaries.

Embedding converts each chunk into a vector representation using an embedding model. The choice of embedding model affects the quality of semantic search how well the similarity between query and document vectors reflects semantic relevance rather than lexical overlap. Most production RAG systems benefit from periodic re-embedding: as the embedding model improves or as the content distribution shifts, re-running the embedding pipeline on the full document collection and re-indexing can improve retrieval quality significantly.

Indexing stores the embedded chunks in the vector database along with their metadata document source, creation date, document type, and any custom dimensions relevant to your filtering needs. The metadata design at the indexing stage determines the filtering capabilities of the retrieval engine: if you need to restrict retrieval to documents relevant to a specific customer’s configuration, the customer identifier needs to be stored as metadata on every document chunk.

The Retrieval Engine

The retrieval engine, given a query, identifies the chunks most likely to contain the information needed to answer it. The design decisions at this stage are: the retrieval strategy, the number of chunks retrieved, and the re-ranking logic.

Retrieval strategy. Pure semantic search retrieving the chunks whose embedding is most similar to the query embedding works well for most queries but fails on specific queries where exact keyword matches matter more than semantic similarity. A query for “error code 4021” benefits from keyword search rather than semantic search; a query for “how do I configure the scheduling window for recurring jobs” benefits from semantic search. Hybrid retrieval combining semantic and keyword search with a fusion algorithm consistently outperforms either alone and is worth the additional implementation complexity.

Retrieval count. How many chunks to retrieve is a design parameter that trades off between recall (retrieving enough to contain the answer) and precision (not retrieving so much that relevant information is diluted). A common starting point is retrieving five to ten chunks and evaluating whether the correct information is present in the retrieved set. The retrieval count can be adjusted per query type based on empirical evaluation.

Re-ranking. Retrieved chunks are not always returned in the right order for the generation stage the most semantically similar chunk is not always the most relevant. A re-ranking step, which applies a more compute-intensive model to score the relevance of each retrieved chunk against the specific query, can significantly improve the quality of the context provided to the generation stage. For use cases where retrieval quality is the primary quality constraint, re-ranking is worth the additional latency and cost.

The Generation Layer

The generation layer combines the retrieved chunks with the query and any other relevant context into a prompt, and passes it to the model for synthesis. The design decisions here are: the prompt structure, the handling of retrieval failures, and the output validation.

The prompt structure should make explicit to the model which information comes from retrieved sources and which is part of the system instruction. Including explicit attribution instructions asking the model to indicate which retrieved document each claim is based on supports both quality evaluation (verifying that claims are grounded in retrieved content) and user transparency (allowing users to understand where the information came from).

Retrieval failures cases where the retrieval engine does not return content that is actually relevant to the query should be handled gracefully rather than silently. Build logic that detects low-confidence retrieval results (low similarity scores across all retrieved chunks) and routes those queries to a human fallback rather than generating a response that is likely to be a hallucination. The alternative generating a confident-sounding response based on irrelevant retrieved content is worse than acknowledging that the system cannot answer the query.

Pattern 2: The Agentic Workflow

An agentic workflow uses a model as a reasoning engine that can plan and execute sequences of actions to accomplish a goal. Rather than answering a single question with a single response, an agent receives a goal, determines what steps are required to accomplish it, executes those steps using available tools, and synthesizes the results into a final output.

The defining feature of an agentic workflow is tool use: the ability of the model to call external functions APIs, database queries, code execution environments, or other AI systems as part of its reasoning process. A support ticket resolution agent might query the customer’s account history, look up the relevant product documentation, check whether a known bug applies to the customer’s configuration, and draft a response all as part of a single agentic execution.

Designing Agentic Workflows Safely

The power of agentic workflows is also their primary risk: an agent that can take actions can take wrong actions, and wrong actions in an agentic workflow can cascade in ways that are difficult to reverse. Several design principles reduce this risk significantly.

Minimize the scope of actions. Give the agent access only to the tools it needs for the specific use case. An agent designed to draft support responses does not need write access to the customer’s account it needs read access to account history and write access to a draft queue. Principle of least privilege, applied to agentic tools, significantly limits the blast radius of an agent that reasons incorrectly.

Require human confirmation for consequential actions. For any action that is difficult or impossible to reverse sending a customer communication, modifying billing configuration, escalating a support case design the workflow to pause and request human confirmation before execution. The cost is a step in the workflow; the benefit is that consequential errors are caught before they reach the customer.

Design for observability of the reasoning chain. Agentic workflows are significantly harder to debug than single-turn model calls because the failure may occur at any step in a multi-step reasoning chain. Log every tool call and every intermediate output in the agent’s reasoning process. When the final output is wrong, the log of the reasoning chain reveals where the error occurred, which is the information needed to fix it.

Set explicit termination conditions. Agents that can loop re-querying, re-evaluating, re-planning need explicit termination conditions that prevent infinite loops when the agent cannot make progress. Define a maximum number of steps, a maximum execution time, and a set of exit conditions that trigger a fallback to human handling.

When Agents Are Appropriate

Agentic workflows are appropriate when the task genuinely requires multiple sequential steps of reasoning or action, when those steps cannot be pre-specified because they depend on intermediate results, and when the organization is prepared to invest in the observability and safety design that agents require.

They are not appropriate when the task can be accomplished with a single, well-crafted model call adding agentic complexity to a straightforward generation task increases latency, cost, and failure surface without adding capability. Agents are also not appropriate for tasks where the organization lacks the operational maturity to monitor and maintain the system at the level of detail that agentic workflows require. Start with simpler patterns and introduce agents when the simpler patterns have demonstrably reached their capability ceiling.

Pattern 3: The Classification and Routing System

The classification and routing system is the simplest of the four patterns and often the most reliable in production. It takes an input a support ticket, an incoming document, a user message assigns it to one of a set of predefined categories, and routes it to the appropriate handler. The pattern is appropriate when the categories are well-defined, the volume is high enough to justify automation, and the quality of the classification can be measured and maintained.

The architecture has two stages: a classification stage that assigns a category, and a routing stage that directs the classified input to the appropriate downstream process. Between them sits a confidence threshold: inputs classified with high confidence are routed automatically; inputs classified below the confidence threshold are routed to a human reviewer who makes the final determination and provides a labeled example that can improve the classifier over time.

The confidence threshold is the primary design lever for managing the tradeoff between automation rate and accuracy. A high threshold routing only very high-confidence classifications automatically produces high accuracy but lower automation rates. A lower threshold produces higher automation rates but allows more errors into the automated routing path. The right threshold depends on the cost of a routing error in your specific use case: a misrouted support ticket that goes to the wrong team is annoying but recoverable; a misrouted financial document in a regulated process may have significant consequences. Set the threshold based on the consequence of errors, not on a desire to maximize automation.

Evaluation for classification systems is more straightforward than for generation systems: accuracy against a labeled test set is the primary metric, supplemented by per-category precision and recall to identify which categories are systematically confused. Build the labeled test set before implementation the discipline of specifying the categories precisely enough to label examples consistently is itself valuable, because it reveals category definitions that seemed clear but are ambiguous in practice.

Pattern 4: The Structured Generation System

The structured generation system uses a model’s reasoning capabilities to produce output in a specific, machine-readable format from inputs that are too complex or varied for rules-based processing. The pattern is appropriate when the input requires genuine reasoning or interpretation to transform into the desired output structure, and when the output structure is well enough defined that deviations are detectable and handleable.

Common examples include: extracting structured information from unstructured text (extracting key entities and relationships from a contract or medical record), generating structured reports from complex data (synthesizing multiple data sources into a formatted analysis), and producing structured API payloads from natural language instructions (converting a customer’s natural language request into a configuration object that an API can process).

The critical design element in structured generation systems is output validation. Unlike generation systems where quality evaluation requires human judgment, structured generation systems produce output that can be validated mechanically: does the JSON conform to the schema? Are all required fields present? Do the values fall within the expected ranges? Build validation logic that is applied to every model output before it is passed to downstream systems, and design explicit handling for validation failures whether that means retrying with a corrected prompt, routing to a human reviewer, or failing gracefully with a clear error.

For use cases where output structure is strictly required, techniques like JSON mode and function calling model API features that constrain the model’s output to a specified format significantly reduce the frequency of validation failures compared to free-form generation with format instructions.

Combining Patterns: Compound Systems

Production AI systems rarely use a single pattern in isolation. The support automation system at Nexus combines a classification pattern (categorizing incoming tickets) with a RAG pattern (retrieving relevant documentation and account history to inform the response draft) and a structured generation pattern (producing a draft response in the format that the CS team’s ticketing system can accept). Understanding how to combine patterns cleanly is what separates systems that scale well from systems that become unmanageable as requirements grow.

The key principle for combining patterns is clean interfaces. Each pattern should be a distinct component with well-defined inputs, outputs, and quality metrics. The classification component produces a category and a confidence score. The RAG component produces retrieved context and a relevance score. The generation component produces a response. Each component can be tested, evaluated, and improved independently, and the interfaces between them are explicit enough that a failure at any stage can be isolated and diagnosed.

Compound systems also require compound evaluation. Each component has its own quality metrics, and the system-level quality depends on all of them. A compound system where the classification component is 95% accurate, the retrieval component finds the right context 85% of the time, and the generation component produces good outputs 90% of the time has an end-to-end quality of approximately 72% substantially lower than any individual component’s quality. This compounding effect makes it essential to measure quality at every component interface, not just at the final output, so that the weakest component can be identified and improved systematically.

There is a sequencing implication to this arithmetic: when building a compound system, start by maximizing the quality of the earliest component in the pipeline before optimizing the later components. A retrieval engine that finds the right content 70% of the time is the binding constraint on the entire system improving the generation layer from 85% to 95% quality changes the end-to-end quality by less than 7 percentage points, while improving retrieval from 70% to 85% changes it by more than 15. The compounding math makes component sequencing and optimization priority more consequential than intuition suggests.

The other design challenge in compound systems is managing the propagation of errors. When the classification component assigns the wrong category, every subsequent component in the pipeline operates on incorrect premises. The generation component may produce a perfectly well-written response that answers the wrong question. Building error detection at each interface logic that identifies inputs whose characteristics are inconsistent with the category they were assigned to, or retrieval results whose relevance score is too low for the stated query allows errors to be caught close to their origin rather than propagated to the final output.

Evaluation Architecture

Every production AI system needs an evaluation architecture the infrastructure and processes that measure whether the system is producing good outputs and alert the team when quality degrades. Evaluation is not something to add after the system is built; it is a component of the system that needs to be designed alongside the core architecture.

Evaluation operates in two modes: offline evaluation and online evaluation. They are complementary and both necessary.

Offline evaluation measures system quality against a fixed, curated dataset of inputs with known good outputs. The dataset is assembled before implementation ideally during the use case specification stage and represents the range of inputs the system is expected to handle in production. Offline evaluation runs automatically as part of the development workflow, catching quality regressions before they reach production. Its limitation is that it reflects the distribution of inputs in the dataset, which may drift from the actual production distribution over time as customer behavior and content evolves.

Online evaluation measures quality on live production inputs. Because the correct output for a live input is not always known in advance, online evaluation relies on a combination of automated metrics (measuring properties of the output that correlate with quality, like format compliance, confidence scores, and absence of contradiction with retrieved content), sampled human review (a human reviewer assesses a random sample of production outputs against defined quality criteria), and implicit user feedback (measuring downstream signals like ticket resolution rates, correction rates, or user engagement that indicate whether the AI output was useful).

The evaluation dataset is the most important artifact in the evaluation architecture and the most frequently neglected. A good evaluation dataset has four properties: it is representative of the real production distribution, including the edge cases and unusual inputs that occur in practice; it is labeled with ground truth by people who understand the task well enough to label consistently; it is versioned, so that changes to the dataset over time are tracked; and it grows over time, with the failure cases from online evaluation added as new labeled examples. A static evaluation dataset that was assembled once and never updated will gradually become less representative as the production distribution evolves.

Evaluation metrics vary by pattern. For classification systems, the primary metrics are per-category precision and recall, with special attention to the categories that carry the highest cost of error. For RAG systems, retrieval metrics (whether the relevant document was retrieved) and generation metrics (whether the response is grounded in the retrieved content, accurate, and useful) need to be measured separately. For agentic workflows, metrics should cover each step in the workflow independently the tool selection accuracy, the interpretation of tool responses, and the synthesis quality as well as the end-to-end task completion rate. For structured generation systems, schema compliance is the mechanical metric, complemented by semantic accuracy for systems where the schema-compliant output can still be semantically wrong.

Building the evaluation infrastructure the dataset, the metrics, the automated evaluation pipeline requires approximately 20% of the time invested in building the first AI system. Teams that treat this as optional overhead consistently discover, within three to six months of production, that they cannot tell whether the system is working well, cannot detect when it degrades, and cannot demonstrate to internal stakeholders that the investment was worthwhile. The evaluation infrastructure is the mechanism that converts AI development from art to engineering.

Testing Strategies for AI Systems

AI systems require a different testing strategy from traditional software, because the correct behavior is probabilistic and the failure modes are semantic rather than mechanical. A unit test that verifies the output of a deterministic function cannot verify that a model prompt produces good outputs across the range of inputs it will encounter.

The testing strategy for AI systems operates at three levels. Component-level testing verifies that each component of the architecture the ingestion pipeline, the retrieval engine, the generation layer behaves correctly in isolation. For the ingestion pipeline, this means verifying that documents are chunked, embedded, and indexed correctly. For the retrieval engine, this means verifying that specific queries return the expected documents. For the generation layer, this means verifying that the prompt assembly logic correctly combines instructions, retrieved context, and user input. These tests can be deterministic and automated.

System-level testing evaluates the end-to-end quality of the AI system against the evaluation dataset. Unlike component tests, system-level tests are not deterministic the same input may produce slightly different outputs on successive runs due to model temperature settings and other sources of variation. System-level tests measure quality distributions rather than exact matches: what fraction of inputs receive a quality rating above the acceptance threshold? Is that fraction stable across releases? Does it vary systematically across input categories?

Adversarial testing evaluates the system’s behavior on inputs designed to reveal failure modes inputs that are unusual, malformed, adversarial, or that probe the boundaries of the system’s design. For support classification systems, adversarial inputs include tickets that are ambiguous between categories, tickets written in multiple languages, and tickets that contain no description of the actual problem. For RAG systems, adversarial inputs include queries about topics not covered in the knowledge base, queries that request information that was recently updated, and queries that attempt to elicit responses not grounded in retrieved content. Running adversarial tests before production deployment is the single most reliable way to discover failure modes before customers do.

The Human-in-the-Loop Design Principle

Across all four patterns, the single most important architectural decision is how and when humans are involved in the AI system’s operation. This decision is not merely an ethical one though it has ethical dimensions it is a reliability and quality decision. AI systems make mistakes, and the design of the human-in-the-loop mechanisms determines whether those mistakes are caught, corrected, and used to improve the system, or whether they propagate invisibly until they cause significant problems.

Human-in-the-loop design has three components: escalation paths, override mechanisms, and feedback collection. Escalation paths define the conditions under which the AI system defers to a human rather than acting autonomously low confidence scores, unusual inputs that fall outside the system’s training distribution, or consequential actions that require explicit authorization. Override mechanisms give human users the ability to correct AI outputs or decisions after the fact, and they should be designed to make correction easy rather than awkward. Feedback collection captures the human’s correction or preference and routes it back into the quality improvement loop, so that each human intervention makes the system marginally better over time.

The appropriate level of human involvement varies by use case and evolves over time. A new AI system should start with more human involvement than seems strictly necessary more sampling, more review, more explicit confirmation steps and reduce that involvement as the system demonstrates reliable performance. This approach builds organizational trust in the system incrementally, based on evidence rather than assumption, and it ensures that the human feedback data needed to improve the system is collected during the period when it is most informative.

For customer-facing AI systems, transparency about the human-in-the-loop design is both a trust-building mechanism and an ethical requirement. Customers should know when they are interacting with an AI system, and they should understand what happens when the AI system is uncertain or wrong. Designing for transparency from the beginning making it easy for the system to say “I’m not confident about this; let me connect you with someone who can help” produces better customer outcomes and reduces the risk of trust erosion when AI errors inevitably occur.

The feedback collection component of the human-in-the-loop design deserves particular attention because it is the mechanism through which the system improves over time. Every human correction is a labeled example an input with a known wrong output (what the AI produced) and a known correct output (what the human provided). Systematically collecting, storing, and periodically reviewing these corrections reveals the patterns in the system’s failure modes: the categories of input it handles poorly, the types of reasoning errors it makes, the contexts in which it over-generates or under-retrieves. These patterns are the input to the improvement cycle adjusting prompts, updating retrieval configurations, expanding the evaluation dataset that makes each version of the system better than the last. An AI system without a feedback collection mechanism is an AI system that cannot improve, and an AI system that cannot improve is a liability rather than an asset in a market where customer expectations are continuously rising.

Architecture Evolution: Starting Simple and Growing

One of the most important and most violated principles in AI architecture is that production systems should start simpler than the team’s ambition and grow toward complexity as the use case demands it. The natural instinct when designing an AI system is to build for the sophisticated end state: a compound system with classification, RAG, and agentic components, full observability, real-time feedback loops, and multi-model routing. This instinct produces systems that are difficult to build, difficult to debug, and difficult to explain to the people who will operate them.

The architecture that is right for the first production deployment of a use case is almost always simpler than the architecture that will be right in eighteen months. The support ticket classification system should start as a single-stage classifier with a confidence threshold and a human fallback not a compound system with pre-classification intent detection, multi-step disambiguation, and agentic escalation handling. The simpler system reaches production faster, fails in ways that are easier to diagnose, and generates the operational data that reveals whether the additional complexity of the more sophisticated architecture is actually warranted.

Architecture evolution the deliberate process of growing a system from its initial simple form toward the more sophisticated form that scale and maturity require is a planned activity, not an accidental one. At each stage of evolution, the question to ask is: what specific, measured quality gap or operational constraint does the next increment of architectural complexity address? If the answer is “retrieval precision is below our target on queries in category X,” the next increment is a retrieval quality improvement perhaps hybrid search, perhaps re-ranking, perhaps category-scoped retrieval. If the answer is “the system is not meeting our latency requirements at production volume,” the next increment is a caching or batching optimization. Each architectural evolution is motivated by evidence from the current system’s operation, not by the theoretical superiority of a more complex approach.

Reliability and Failure Mode Design

Every AI architecture pattern has characteristic failure modes the ways it tends to produce wrong or harmful outputs and understanding these failure modes in advance is the prerequisite for designing against them.

RAG system failures most commonly occur in the retrieval stage: the system retrieves the wrong documents, retrieves documents that are outdated, or retrieves nothing relevant and generates a hallucination. The defenses are: retrieval quality evaluation to detect systematic retrieval failures before they reach users, freshness metadata on indexed documents to enable detection and exclusion of stale content, and no-retrieval detection logic that escalates to a human when the retrieval confidence is below threshold.

Agentic workflow failures most commonly occur when the agent’s plan is based on incorrect assumptions, when a tool call returns unexpected output that the agent misinterprets, or when the agent loops without making progress. The defenses are: step-level logging and intermediate output validation, explicit error handling for unexpected tool responses, hard termination limits, and human confirmation requirements for high-stakes actions.

Classification system failures most commonly occur on inputs that are ambiguous, that belong to edge case categories, or that are unlike the training distribution. The defenses are: confidence thresholds that route uncertain inputs to humans, regular evaluation against a held-out test set to detect accuracy drift, and a human feedback loop that provides labeled examples for the failure cases the system encounters.

Structured generation failures most commonly occur when the model produces output that violates the schema missing fields, wrong data types, semantically incorrect values. The defenses are: schema validation on every output, retry logic for validation failures with corrected prompts, and graceful degradation to a human-handling path when multiple retries fail.

Key Takeaways

• Four core architecture patterns cover the vast majority of B2B SaaS AI use cases: the RAG system (organization-specific context grounding), the agentic workflow (multi-step reasoning and action), the classification and routing system (high-volume discrete categorization), and the structured generation system (machine-readable output from complex inputs).
• Pattern selection should be driven by the nature of the task, not by technical ambition. Simpler patterns that match the task are more reliable and easier to maintain than sophisticated patterns applied where simpler ones would suffice.
• The RAG system requires careful design at every stage ingestion, chunking, embedding, retrieval, and generation and retrieval quality is the most common source of production failures. Build retrieval evaluation into the system before deployment.
• Agentic workflows are powerful but require more safety and observability investment than simpler patterns. Start with principle of least privilege for tool access, require human confirmation for consequential actions, and set explicit termination conditions.
• Compound systems production systems that combine multiple patterns require compound evaluation. Measure quality at each component interface, not just at the final output. The compounding of component-level quality determines system-level reliability.
• Human-in-the-loop design is an architectural requirement, not an afterthought. Design escalation paths, override mechanisms, and feedback collection into every production AI system from the beginning, and start with more human involvement than seems strictly necessary, reducing it as the system demonstrates reliable performance.
• Every pattern has characteristic failure modes. Design against them explicitly: retrieval failures in RAG systems, planning failures in agentic workflows, classification drift in routing systems, and schema violations in structured generation.
• Architecture should start simpler than the team’s ambition and evolve toward complexity as measured operational need demands it. Each architectural evolution should be motivated by a specific, evidenced gap in the current system’s performance not by the theoretical superiority of a more sophisticated approach.
• The evaluation dataset is the most important artifact in the evaluation architecture. Assemble it before implementation, not after. Label it with people who understand the task, version it, and grow it over time with the failure cases that production surfaces. A well-maintained evaluation dataset is what converts AI development from iterative guesswork into systematic engineering.