The AI Builder Stack in 2026

Search for "how to build an AI app" and you'll find a new framework, vector database, or observability platform every week, each presented as essential. It's easy to conclude you need a dozen tools before writing a line of code. You don't. Every AI app is made of the same handful of layers, and at each one there's a sensible default that will carry you a long way.

This lesson gives you a map of those layers: models, provider APIs, SDKs, your prompt and context code, retrieval, tools, evals, observability, and hosting. For each, you'll learn what it does, what this course uses by default, and the signals that tell you it's time for something more. You'll finish with a small piece of code that keeps your app flexible as the stack changes underneath it.

The layers at a glance#

Here's an AI feature, from the user's click down to the model, as a stack. Not every feature uses every layer, but knowing where each piece sits tells you where to look when something goes wrong.

┌─────────────────────────────────────────────────────┐
│ Product UI          buttons, streaming text, review │
├─────────────────────────────────────────────────────┤
│ Feature code        prompts, context assembly,      │
│                     validation, business rules      │
├──────────────┬──────────────┬───────────────────────┤
│ Retrieval    │ Tools        │ Safety checks         │
│ search, RAG  │ your API,    │ moderation, limits,   │
│              │ MCP servers  │ output sanitizing     │
├──────────────┴──────────────┴───────────────────────┤
│ SDK layer           provider SDK or AI SDK          │
├─────────────────────────────────────────────────────┤
│ Provider API        Anthropic, OpenAI, Google, ...  │
├─────────────────────────────────────────────────────┤
│ Model               Claude, GPT, Gemini, open-weight│
└─────────────────────────────────────────────────────┘
  Alongside every layer: evals · observability · hosting

The bottom three layers are things you choose. The middle layers are code you write. The cross-cutting concerns at the bottom of the diagram (evals, observability, hosting) are what separate a demo from a product.

Models: choose per feature, not per app#

The model is the trained network that reads your input and produces output. In 2026 you're choosing among three broad groups:

• Frontier hosted models from the major labs, such as Anthropic's Claude 5 family, OpenAI's GPT-6 family, and Google's Gemini models. Most capable, pay per token, no infrastructure to run.
• Open-weight models such as Llama, Qwen, Mistral, Gemma, DeepSeek, and gpt-oss. You download the weights and run them yourself or through a hosting provider. More control over data and cost at scale; more operational work.
• Small and on-device models that run on a laptop, phone, or in the browser. Private and free per call, but limited in capability.

Default for this course: Claude Sonnet 5.5 (claude-sonnet-5-5) for most features, Claude Haiku 5.5 (claude-haiku-5-5) for high-volume simple tasks like classification and routing, and Claude Opus 5.5 (claude-opus-5-5) for the hardest reasoning. That three-tier pattern (fast, default, best) exists at every major provider, and the habit of picking a tier per feature matters more than the brand.

When to change: when your evals show a cheaper model is good enough, when data rules require self-hosting, or when another provider has a capability you need. Module 6 covers choosing, routing, and running models in depth.

Provider APIs and SDKs#

A provider API is the HTTP interface a model is served through. You send a request with messages and settings; you get back generated content and token usage. Anthropic's Messages API, OpenAI's Responses API, and Google's Gemini API all share that basic shape and differ in the details: field names, how tools are declared, how structured output is requested. Comparing Provider APIs in Module 1 walks through the differences.

You'll rarely call these APIs with raw HTTP. An SDK (software development kit, a library that wraps the API) gives you types, retries, streaming helpers, and error classes. There are two kinds:

Default for this course: the Anthropic TypeScript SDK for feature code, because it exposes everything the API can do and makes each request easy to see. The Vercel AI SDK appears where its React helpers save real work, such as streaming chat in Next.js. SDKs and Abstraction Layers writes the same feature both ways so you can judge for yourself.

Your code: prompts, context, and rules#

This is the layer most tutorials skip and the one that decides whether a feature works. It contains:

• Prompts: the system prompt and templates that tell the model its job. In a product, a prompt is code: versioned, reviewed, and tested.
• Context assembly: choosing which user data, documents, and history the model sees on each call.
• Validation and business rules: checking output against a schema and your own rules before anything reaches a user or a database.

There's no product to buy here. It's ordinary TypeScript in your repo, and Modules 2 through 4 are about writing it well. The one structural decision worth making on day one is to keep every model call behind a thin module of your own instead of scattering SDK calls across the codebase:

import Anthropic from "@anthropic-ai/sdk";
 
// One client for the whole app. It reads ANTHROPIC_API_KEY from the environment.
export const anthropic = new Anthropic();
 
// Features pick a tier, not a model ID. Swapping models is a one-line change.
export const MODELS = {
  fast: "claude-haiku-5-5",
  default: "claude-sonnet-5-5",
  best: "claude-opus-5-5",
} as const;
 
export type ModelTier = keyof typeof MODELS;

It's a few lines, but it means "upgrade every feature to the new model" or "move triage to the fast tier" is a one-line diff rather than a search across the codebase.

Retrieval and tools: connecting the model to your world#

A model only knows what's in its training data and what you put in the request. Two layers connect it to your app's data.

Retrieval finds the relevant pieces of your data and adds them to the prompt. That usually means embeddings (lists of numbers that represent meaning, so similar text has similar numbers) stored in a vector store and searched by similarity, often combined with keyword search. When retrieved documents are handed to the model to ground its answer, that's RAG, retrieval-augmented generation.

Default: Postgres with the pgvector extension, so your vectors live next to the rest of your data. Anthropic doesn't offer embedding models, so you'll use another provider for embeddings (Voyage AI, OpenAI, Google, or an open-weight model). Module 5 covers all of this, including when you don't need retrieval at all because the documents fit in the context window.

Tools let the model ask your code to do something: look up an order, search the knowledge base, create a ticket. You describe each tool with a name and a JSON schema; the model asks to call it; your code runs it and returns the result. The Model Context Protocol (MCP) is an open standard for packaging tools so any compatible AI client can use them. Module 4 covers tool use inside features and where MCP fits into a product.

Evals, observability, and hosting#

These cross-cutting layers are what make a feature trustworthy in production.

Evals are automated tests for AI behavior: a set of real inputs, the qualities a good output must have, and checks (code-based or model-graded) that score each run. They're how you know a prompt change made things better rather than different. Default: start with a dataset file and a script in your repo. Dedicated eval tools are worth adding once you have many features and want dashboards and history. Module 9 builds the whole system.

Observability means recording every model call: inputs, outputs, model, token usage, latency, and errors, linked to the user request that triggered it. Without it, "the summary was wrong yesterday" is impossible to debug. Default: structured logs from your own wrapper (sketched below), with a trace ID per request. LLM observability platforms and OpenTelemetry-based tracing are the next step; Logging and Tracing LLM Calls covers both.

Hosting is where your code runs. AI calls are slow by web standards (seconds, not milliseconds), so watch serverless function timeouts and move long or bulk work to background jobs. Default: a Next.js app on whatever platform you already use, with a job queue for slow work. An LLM gateway (a proxy that sits between your app and providers to add fallbacks, rate limits, and spend tracking) becomes useful once you call several providers.

Here's the start of the observability habit: wrap your model calls so each one logs what you'll need later.

import Anthropic from "@anthropic-ai/sdk";
import { anthropic, MODELS, type ModelTier } from "./ai.js";
 
type CallOptions = {
  feature: string; // e.g. "ticket-summary", so you can group costs and errors by feature
  tier: ModelTier;
  system: string;
  messages: Anthropic.MessageParam[];
  maxTokens?: number;
};
 
export async function callModel(opts: CallOptions): Promise<Anthropic.Message> {
  const started = Date.now();
  const model = MODELS[opts.tier];
  try {
    const response = await anthropic.messages.create({
      model,
      max_tokens: opts.maxTokens ?? 4000,
      system: opts.system,
      messages: opts.messages,
    });
    console.log(
      JSON.stringify({
        event: "llm_call",
        feature: opts.feature,
        model,
        stopReason: response.stop_reason,
        inputTokens: response.usage.input_tokens,
        outputTokens: response.usage.output_tokens,
        ms: Date.now() - started,
      }),
    );
    return response;
  } catch (err) {
    const status = err instanceof Anthropic.APIError ? err.status : undefined;
    console.error(JSON.stringify({ event: "llm_error", feature: opts.feature, model, status, ms: Date.now() - started }));
    throw err;
  }
}

The feature tag is the important part. Months from now, when you're asking which feature drives your bill or which one fails most, you'll need every call labeled by the feature that made it.

The default stack, summarized#

Resist adding a layer before you feel the pain it solves. A framework you don't need is one more thing to debug when a model update changes behavior.

Next: Your Builder Setup: Node, TypeScript, and API Keys — set up the project and playground you'll use for every exercise in the course.