Designing an AI System

An incorrect AI answer can originate in the model, the evidence it receives, or the surrounding application. A missing contract, a misread table, and an unsupported summary require different repairs. This lesson shows how explicit component boundaries make those failures easier to locate and contain.

Start with the task requirements, then select the model and surrounding components. An application that answers questions about private contracts needs authorized data access and evidence checks regardless of which model drafts the response. Composition also adds latency, cost, and failure points, so each component should have a demonstrated purpose.

The running example is OptiVerse Travel, a fictional agency used throughout this curriculum. Booking IDs, contracts, clauses, photos, and budgets below are illustrative fixtures for designing the evidence flow; they do not establish actual trip affordability or partner availability.

Why Model-Only Thinking Breaks

Consider a question from a travel planner:

Can we build an accessible 10-day Japan itinerary for a family of four during cherry blossom season within a $13,000 to $15,000 budget, and does our Kyoto hotel partner still honor the contracted wheelchair-accessible rate?

A base language model can produce a plausible answer to that prompt, but plausibility is not the same as a correct system response.

To answer the question reliably, the application may need to:

• find the booking file JPN-2026-0417 and its existing constraints

• retrieve the relevant hotel partner contract and airline rate sheets

• extract rate tables and accessibility clauses from PDF agreements

• normalize currencies, date formats, and room-type codes

• compare contracted rates against current seasonal availability

• present the result with evidence and clear uncertainty

A model alone cannot guarantee any of those steps. They depend on access to the right data, the right sequence of steps, and checks around the model output. When those capabilities are missing, the system cannot establish the requested facts and should disclose the gap instead of filling it with unsupported recall.

Retain the distinction established in the foundations lessons:

• A model is the learned component that maps inputs to outputs.

• A system is the full application around that model, including data flow, orchestration, constraints, and evaluation.

That distinction makes failures easier to investigate. Stale information, missing internal data, or an incorrect output format can result from absent components, defects in existing components, or model behavior. Inspect the data path, supplied context, and validation results before assigning a root cause from the final answer alone.

Defining the Core Terms

Defining the core terms operationally keeps design reviews precise.

Model

A model is the statistical component that produces text, classifications, structured fields, or other outputs from an input context. In this series, that usually means a large language model, though the same system patterns can incorporate OCR models, layout models, vision-language models, or ranking models.

System

A system is the complete application that turns a user task into a result. It includes the model call and everything required to make that call useful: input handling, data access, workflow steps, error handling, output formatting, and evaluation.

Compound AI system

A compound AI system is an AI application built from multiple interacting components rather than a single monolithic model call. Those components can include models, retrieval layers, tool calls, extraction services, deterministic logic, validators, and approval boundaries for higher-consequence actions. Compositional architecture is the defining idea: capability comes from how the pieces work together rather than from model scale alone. This tutorial follows the BAIR formulation (Zaharia et al., 2024), which is influential but is not a settled technical standard.

Use the term to describe an architecture, not to predict its quality. A compound system can underperform a simpler baseline if retrieval is poor, interfaces lose information, or validation introduces errors.

Control logic

Control logic is the part of the system that decides what happens next. Whether implemented as deterministic code or model-assisted routing, this workflow layer coordinates the system and materially shapes its behavior. The next post covers pipeline design in detail.

Tool

A tool is an external capability the system can call, such as search, database lookup, PDF parsing, currency conversion, code execution, or a domain-specific booking service. Tool use is a form of system composition, not a property of the model alone.

Retrieval

Retrieval is the process of selecting relevant external information for a task from document stores, databases, booking records, or indexed partner agreements. It matters because useful enterprise answers often depend on data that should not be assumed to live inside model parameters.

Validation

Validation is any explicit check applied before an answer is accepted or shown. Treat it as a first-class design component; later posts break it into concrete pipeline checks and workflow contracts.

State

State is the information the system keeps while doing work, such as the current task stage, selected documents, extracted fields, or user constraints. This post needs only the minimal idea that some work spans multiple steps; later posts separate state from memory and durable knowledge more carefully.

What Counts as an LLM System

Even a modest production application usually has more structure than "user prompt in, model text out." A minimal LLM system often looks like this:

1. Accept and interpret the user request.

2. Decide whether the task needs external data or a tool.

3. Gather or prepare the needed context.

4. Call the model with a bounded role.

5. Check whether the result can be used.

6. Format the answer for the user or downstream service.

That workflow is still simple, but it already differs in kind from a single prompt: it has boundaries, explicit responsibilities, and places where failure can be detected.

Application capability is often a system property. A model may excel at summarizing text, while the surrounding system answers questions over internal partner contracts and booking records with citations and rate checks. Those are distinct claims: the first belongs to the model, and the second belongs to the architecture around it.

From Monolithic Models to Compound Systems

The early mental model for many AI products was simple: pick the strongest available model, write a better prompt, and let the model do more of the work. That approach works for experimentation, but it breaks down once tasks become knowledge-intensive, compliance-sensitive, or operationally messy.

The architectural shift is toward compound systems. Instead of expecting one model invocation to solve the entire problem, teams decompose the work:

• retrieval fetches relevant evidence

• extraction converts documents into usable inputs

• deterministic logic handles known transformations

• model steps synthesize or interpret ambiguous material

• checks decide whether the result is usable

This approach does not retreat from model capability. The model remains central, but it takes a narrower, more defensible role inside a larger workflow.

Several studies illustrate this direction. Retrieval-augmented generation combines a pretrained model's parametric memory with documents retrieved from an external index. Toolformer showed a language model learning, through self-supervision, when and how to call APIs. ReAct interleaved model-generated reasoning traces with task-specific actions and observations. Each reports gains on the tasks and baselines it evaluated. Those results justify testing composition on a suitable task; they do not rank composition above model scale in general.

For technical leaders, the implication is direct: whenever a use case depends on freshness, private data, provenance, structured outputs, or repeatable workflows, architecture reviews must cover data access, control, and evaluation alongside model selection.

The Main Components Around the Model

Exact architectures vary by product, but six component roles show up repeatedly in real systems.

Input and routing

The system classifies incoming requests and sends each down an appropriate path. A general explanatory question may only need a model call, whereas a question about a specific booking or partner contract probably needs retrieval and evidence formatting, and a document-heavy question may require extraction first.

Data access

Many high-value tasks depend on information outside the base model: partner contracts, booking databases, PDF agreements, accessibility specification sheets, or current rate information. If the system cannot access that data, answer quality is capped no matter how strong the model is.

Extraction and transformation

Preparing documents for synthesis may require parsing rate tables, normalizing field names and currencies, and linking photos to room descriptions or accessibility notes. Give those transformations explicit inputs and validation; prompting can guide a model-based step, but it does not by itself establish that the transformation is correct.

Model inference

The model handles steps where probabilistic interpretation pays off: summarizing evidence, comparing options, drafting explanations, or converting semi-structured information into a target format. Reserve the model for the steps it handles well rather than routing every operation through it by default.

Validation and guardrails

A system should be able to reject or constrain outputs that violate known requirements. If a comparison requires source citations, an uncited answer fails validation. If a rate field requires a numeric value in a canonical currency, the application checks that value before trusting it.

Presentation and provenance

Users often need to see where an answer came from, what evidence backed it, and what remains uncertain. In travel planning, provenance is often part of the product requirement, not an optional feature.

Authorization, security, evaluation, observability, and version tracking for models, prompts, tools, and data cut across every component. They are system-level controls, not additional model capabilities. NIST's Generative AI Profile is a voluntary companion to the AI RMF for incorporating trustworthiness considerations into the design, development, use, and evaluation of AI systems (NIST, 2024).

Worked Example: The OptiVerse Travel Copilot

Apply this component view to the OptiVerse Travel copilot.

The planner asks whether an accessible 10-day Japan trip for a family of four can fit within a $13,000 to $15,000 budget during cherry blossom season, and whether the Kyoto hotel partner still honors the contracted wheelchair-accessible rate under Contract KYO-H12, Clause 4.3. A model-only design runs into immediate obstacles:

• internal booking data for JPN-2026-0417 is not in the model weights and may be missing from the prompt context

• Contract KYO-H12 may hold the needed rate evidence inside a table or clause rather than plain text

• the Kyoto property may appear under variant names across booking systems

• prices and availability windows may be stored in inconsistent formats

• the planner needs an evidence-backed answer, not a fluent guess

A compound system splits the work into narrower responsibilities.

First, routing identifies the request as a grounded comparison task rather than open-ended chat. Retrieval then gathers candidate partner contracts, rate sheets, and accessibility specification sheets. Where key evidence lives inside PDFs, an extraction path pulls rate-table fields, clause references, and photo set ACC-09 as supplementary visual evidence (photos alone cannot establish entrance dimensions, live room assignments, or fit for a specific wheelchair). Normalization reconciles property names and currencies. Only then does the synthesis model compare contracted rates against current seasonal pricing and draft a response.

The exact pipeline will vary. The result is still an AI application built around models, but its useful behavior comes from how the components coordinate:

• the retriever brings in relevant evidence

• the extraction path turns irregular documents into structured inputs

• the control layer keeps the stage sequence coherent

• the synthesis step interprets the assembled evidence

• the validation and presentation layers decide what can be shown

In a compound AI system, the model is situated inside a workflow rather than replaced.

For a concrete boundary test, supply booking_id=JPN-2026-0417, contract_id=KYO-H12, and contract_status=not_found. The expected output is a qualified proposal with rate_status=unverified and no asserted contracted amount. Even when Contract KYO-H12 is present, if no current inventory confirmation covers the requested room and dates, the expected status remains availability_unconfirmed: a contract establishes terms within its scope, but it does not by itself prove available inventory or total-trip affordability.

Monolithic Versus Modular Thinking

Treating modular architecture as a temporary workaround until models improve misreads the engineering problem in many contexts.

A more capable model may reduce how often a pipeline needs special handling, but it does not remove the need for system boundaries. Private data still requires access controls, fresh information still requires retrieval or another external source, structured business processes still require orchestration, and high-stakes use still requires evaluation and validation.

Modular design also sharpens debugging. When a travel copilot answer is wrong, the team can isolate the fault:

• Was the wrong contract or rate sheet retrieved?

• Did the table parser drop a column?

• Did currency conversion use the wrong date?

• Did synthesis overstate weak availability evidence?

• Did validation miss an uncited claim?

Those questions are much harder to answer under a monolithic "just prompt the model harder" approach. Modular systems add interfaces to maintain and are not automatically simpler, but they are often easier to inspect, test, and repair.

Hands-On Exercise

Create a table with these columns: failure fixture, owning component, observable signal, and control point.

Start with one worked row:

Complete rows for these fixtures:

• the wrong hotel contract is retrieved;

• the table parser drops the accessible-room column;

• the model produces a fluent comparison with no supporting clause;

• the final renderer labels a recommendation as a confirmed booking.

Do not assign every row to "the model." Each row must name an owner able to emit an inspectable signal and an application control able to stop propagation.

Deliberately Broken Case

Assume the synthesis prompt contains this instruction:

If Contract KYO-H12 is unavailable, infer the most likely partner rate and continue without mentioning the gap.

This instruction delegates evidence availability, business policy, and abstention to prose inside one prompt. Repair the design by making retrieval return an explicit not_found state, enforcing a policy rule against unsupported rates, and running synthesis only over a validated evidence packet. The prompt may explain the resulting gap to the user; it must not stand in for the missing authority or evidence.

Common Misconceptions and Failure Modes

Teams adopting compound architectures often trip over four recurring misconceptions.

Misconception 1: A better model removes the need for system design

Stronger models improve step quality, but they do not remove architectural requirements. If the task needs proprietary data, evidence tracking, or schema guarantees, a model upgrade does not make those requirements disappear.

Misconception 2: Prompt engineering is the main path to system quality

Clear prompts improve behavior within a bounded step, but they rarely substitute for missing data paths, parsers, or validators.

Misconception 3: Any multi-step AI workflow is an agent

Not every composed system is agentic. Many useful AI products are mostly pipelines: deterministic control logic sets the sequence and calls models at selected steps. Later posts describe assistants, agents, and autonomy boundaries more precisely.

Misconception 4: Retrieval and validation are optional add-ons

For many production tasks, retrieval and validation are core architecture. Without retrieval, the system may answer from stale or irrelevant knowledge; without validation, it may present unsupported claims with unjustified confidence.

Predictable failure modes follow when these boundaries are ignored:

• answering tool-dependent questions without calling the required tool

• relying on stale or incomplete parametric recall

• failing to ground answers in authorized internal records

• emitting outputs that drift from required schemas or currencies

• omitting provenance on claims that require citations

• failing to abstain when supporting evidence is insufficient

These failures can originate in the model, the surrounding components, or the handoffs between them. Trace each observed defect to the component and control point that can contain it, rather than blaming the model and the surrounding system indiscriminately.

Useful AI capability is often assembled: the system earns its usefulness by separating concerns and giving each component a role it can actually perform.

Exit Criteria

Your artifact is complete only if:

• every fixture has exactly one primary observable owner;

• every component boundary names an inspectable input and output;

• unsupported evidence, malformed extraction, and business-rule failure stop before presentation;

• the direct-model-call path is retained for a genuinely simple explanatory request;

• changing a model version does not silently change retrieval, authorization, or validation policy.

Knowledge Check

Answer without looking back.

1. What makes a compound AI system different from a single model call?

2. Why is a model upgrade unable to solve private-data access by itself?

3. Which component should own a wrong currency-conversion date?

4. What two properties must every failure fixture have in the artifact?

Answer Key

1. Multiple interacting components and explicit control boundaries contribute to the task result.

2. Access to private data requires authenticated data paths and authorization outside model parameters.

3. The normalization component, paired with a validator before downstream synthesis.

4. One observable owner and one control point that can contain the failure.

For the four hands-on rows, use these reference mappings: wrong contract → retrieval owner, property/contract mismatch signal, block the evidence packet; missing column → extraction owner, required-column coverage failure, reject the parse; unsupported comparison → synthesis owner, missing claim-to-clause support, withhold that claim; confirmed-booking label → presentation owner, status differs from the authoritative booking record, render only the recorded state. Other implementations may place checks differently as long as the observable signal and containment point stay explicit.

What This Post Is Not

Some tasks are simple enough for a direct model call plus light formatting, and they do not need an orchestration stack. Once a task depends on external knowledge, structured evidence, multi-step control, or verification, however, it has entered systems territory.

Compound systems are also not synonymous with agents. Agent loops are one control pattern within the broader space of AI systems, relevant when a task genuinely requires flexible multi-step decisions rather than a fixed pipeline. Many useful applications do not start there.

Where the Series Goes Next

This architecture-first view sets up the rest of the series.

Post 2 examines reliable LLM pipelines and control logic: decomposing work into typed stages, keeping deterministic logic where rules are clear, and catching semantic errors before synthesis.

Post 3 focuses on grounding through retrieval-augmented generation: fetching relevant evidence, preserving provenance, and abstaining when evidence is weak, contradictory, or missing.

Later lessons widen the evidence boundary further, moving into layout-aware document intelligence when tables and page structure carry meaning, and into multimodal evidence handling when images themselves become evidence.

Those topics share a design principle: when a task depends on external evidence, tools, or controlled actions, assign those responsibilities to explicit system components around the model, and keep the direct-model path for tasks that do not need them.

Sources and Further Reading

This post draws on the following primary and practitioner sources:

• BAIR. "The Shift from Models to Compound AI Systems." Core framing for modern AI applications as systems assembled from models, retrieval, tools, control logic, and validation. bair.berkeley.edu/blog/2024/02/18/compound-ai-systems

• Lewis, P., Perez, E., Piktus, A., et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." Primary reference for generation conditioned on retrieved external evidence rather than only model parameters. arxiv.org/abs/2005.11401

• Schick, T., Dwivedi-Yu, J., Dessì, R., et al. "Toolformer: Language Models Can Teach Themselves to Use Tools." Reference for model-directed tool-use behavior as one ingredient in compound systems. arxiv.org/abs/2302.04761

• Yao, S., Zhao, J., Yu, D., et al. "ReAct: Synergizing Reasoning and Acting in Language Models." Reference for interleaving language-model reasoning traces with actions and observations. arxiv.org/abs/2210.03629

• National Institute of Standards and Technology. "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile." System-level risk, evaluation, and trustworthiness framing for generative AI deployments. nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence