From tokens— to product strategy.

How to Use This Primer

You do not need to read this straight through. Pick the track that matches the decision you are trying to make, then use the glossary and sources when a claim needs verification.

Tokens — The Atoms of Language

You think in words. LLMs think in tokens. Understanding this difference is the foundation of everything else.

When you type "Hello, how are you?" into ChatGPT or Gemini, the model doesn't see five words. It sees something like this:

A token is a chunk of text — sometimes a whole word, sometimes part of a word, sometimes just a character. The model has a fixed vocabulary (think of it as a dictionary) of roughly 30,000–100,000 tokens, and every piece of text gets broken into pieces from that dictionary.

Why tokens matter for product teams

Every API call to an LLM is priced per token. Every model has a maximum number of tokens it can handle at once (its "context window"). When you're designing generative UI — a protocol where an LLM generates UI component trees — the size of that output in tokens directly determines:

• Cost — A complex card component might be 200 tokens. A full-screen layout could be 2,000. At scale, this matters.
• Speed — More tokens = longer generation time. On mobile, users feel every millisecond.
• Feasibility — If your component spec exceeds the model's output limit, it literally can't generate it.

Tokenization in practice

Different models use different tokenizers, but the patterns are similar:

Key takeaway

Tokens are the fundamental unit of LLM computation. Everything — cost, speed, capability limits — flows from token counts. When someone says "this model has a 128K context window," they mean 128,000 tokens, which is roughly a 200-page book.

Next-Token Prediction — How LLMs Think

The most important idea in modern AI is embarrassingly simple: predict the next word. That's it. Everything else — conversations, code, UI generation — is a consequence of this one trick done at extraordinary scale.

An LLM doesn't "understand" language the way you do. It's a prediction machine. Given a sequence of tokens, it calculates the probability of every possible next token, then picks one.

Here's the key insight: the model generates text one token at a time. After it picks "mat," the input becomes "The cat sat on the mat" and it predicts the next token again. This process repeats — token by token — until the model generates a special "stop" token or hits the maximum output length.

The training process (simplified)

How does the model learn these probabilities? Through training on enormous amounts of text. The process is conceptually simple:

The model doesn't memorize text. It learns patterns — statistical relationships between tokens. After seeing millions of sentences about cats sitting on things, it learns that "mat" is the most likely word after "the cat sat on the." After seeing millions of JSON objects, it learns the patterns of valid JSON. After seeing millions of code snippets, it learns programming syntax.

Training vs Inference: learning vs using

The process above — showing the model billions of examples and adjusting its parameters — is called training. It happens once (or periodically) and costs millions of dollars in compute. The result is a trained model — a massive file of numerical weights.

When you send a message to ChatGPT or Claude, the trained model runs the next-token prediction loop to generate a response. This is called inference. It happens billions of times per day and costs dollars (or fractions of a cent) per request.

This is why LLMs can generate UI

If an LLM has seen enough examples of JSON structures that describe UI components, it can predict what a valid UI component JSON should look like. Feed it a prompt like "generate a card component with a title and two buttons" and it produces token after token of valid JSON — not because it "understands" UI, but because it's seen enough patterns to predict what comes next in that kind of document.

Context Windows — The Model's Working Memory

A context window is the total amount of text a model can "see" at once — both your input and its output combined. It's the single most important constraint in building AI products.

Think of the context window as a desk. Everything the model needs to work with — your instructions, the conversation history, any documents you've provided, AND the response it's generating — all has to fit on this desk. If it doesn't fit, it falls off the edge and the model can't see it.

Context window sizes across models

Model names, context windows, and prices change quickly. Treat this table as orientation, then verify against live provider docs before using it in a spec.S1S2S3

Why this matters for product decisions

Context window size shapes every product decision in an AI system:

Temperature and Sampling — Controlling Creativity

When the model predicts the next token, it doesn't always pick the most likely one. Temperature controls how adventurous it gets.

Remember from Chapter 2 that the model produces a probability distribution over all possible next tokens. Temperature is a number that modifies these probabilities before the model makes its pick.

Other sampling parameters

Temperature isn't the only knob. Two others matter for your work:

Top-P (nucleus sampling): Instead of considering all 100,000 possible tokens, only consider the smallest set whose combined probability exceeds P. If P=0.9, the model only picks from the top tokens that together account for 90% of the probability. This prevents the model from ever picking wildly unlikely tokens.

Top-K: Even simpler — only consider the K most likely tokens. If K=50, the model picks from the top 50 most probable tokens. The other 99,950 are eliminated entirely.

Reasoning Models — When AI Needs to Think

Standard models respond instantly. Reasoning models pause, think step-by-step, and then answer. They cost 5–10x more, take seconds to start, and beat everything else on the hard stuff. The product question is when that trade is worth it.

Remember from Chapter 2 that LLMs predict one token at a time. A reasoning model does something different: before producing its visible answer, it generates internal "thinking tokens" — a private chain of reasoning that the user may or may not see.

The UX challenge

Reasoning models create a fundamentally different interaction pattern:

• Latency: 5-60+ seconds of silence while the model thinks. You need progress indicators, "thinking" animations, or visible chain-of-thought streaming.
• Cost: Thinking tokens cost money even though the user never sees them. A reasoning request can cost 5-10x more than a standard one.
• Visibility: Do you show the model's reasoning? Some users find it reassuring ("it's actually thinking about my problem"). Others find it noisy. This is a design decision.
• Effort control: OpenAI, Anthropic, and Google all now expose "reasoning effort" as a parameter. Should users control how hard the model thinks? Or should the system decide automatically?

Structured Output — Making Models Predictable

LLMs naturally produce free-flowing text. But generative UI needs valid JSON. Structured output is how we force a creative, probabilistic system to produce machine-readable data.

Without structured output, if you ask an LLM to "generate a card component," you might get:

Sure! Here's a card component for you:

The card has a title "Weather Today" and shows the
current temperature of 72°F with a sunny icon...

That's nice prose, but your UI renderer can't do anything with it. What you need is:

{
  "type": "Card",
  "children": [
    { "type": "Text", "value": "Weather Today", "style": "headline" },
    { "type": "Row", "children": [
      { "type": "Icon", "name": "sunny" },
      { "type": "Text", "value": "72°F", "style": "display" }
    ]}
  ]
}

Structured output constrains the model toward valid JSON that matches your schema. Providers differ in how strict this is, and even schema-valid output can contain wrong values, so still validate before acting.S9 There are three main approaches, and understanding the differences is critical:

Function calling in practice

Here's what a real function calling setup looks like. This is the exact pattern that generative UI would use:

// You send this to the API alongside your prompt:
{
  "tools": [{
    "type": "function",
    "function": {
      "name": "render_ui",
      "description": "Generate a UI component tree for the user's request",
      "parameters": {
        "type": "object",
        "properties": {
          "root": {
            "type": "object",
            "properties": {
              "type": { "enum": ["Card", "Column", "Row", "List"] },
              "children": {
                "type": "array",
                "items": { "$ref": "#/$defs/Component" }
              }
            }
          }
        },
        "required": ["root"]
      }
    }
  }]
}

// The model's response is constrained to this schema:
{
  "tool_calls": [{
    "function": {
      "name": "render_ui",
      "arguments": {
        "root": {
          "type": "Card",
          "children": [
            { "type": "Text", "value": "Weather", "style": "headline" },
            { "type": "Text", "value": "72°F Sunny", "style": "body" }
          ]
        }
      }
    }
  }]
}

The schema design tradeoff

This is where design instinct becomes a superpower. Schema design is UX design for machines:

Model Variants — Choosing the Right Brain

Not all models are created equal. Choosing which model to use for which task is one of the most impactful product decisions you'll make.

Every major AI provider offers a family of models at different capability/cost/speed tradeoffs. Think of it like cars: you don't drive an 18-wheeler to get groceries, and you don't use a Smart car to haul lumber.

Model routing: using multiple models

Sophisticated AI products don't use a single model — they route requests to different models based on complexity. This is called model routing or cascading.

Multimodal AI — Beyond Text

Modern models read text, see images, hear audio, and watch video. The input box is no longer a box. The design problem is figuring out which modalities your product actually needs and which are demo candy.

Every chapter so far has been implicitly text-centric. But as of 2026, every frontier model is natively multimodal — processing text, images, audio, and sometimes video within a single inference call.

What this means for product teams

Multimodal AI enables new input patterns that were impossible with text-only models:

• Show, don't tell: Instead of describing a UI bug in words, a user can screenshot it. Instead of writing out a math problem, they photograph their notebook.
• Document understanding: Drop a PDF, invoice, or contract into the conversation. The model reads it visually, including layout, tables, and figures.
• Camera as input: Point your phone at a plant to identify it. Scan a whiteboard to digitize it. Show a product to compare prices.
• Voice + vision: Gemini Live lets you share your camera during a voice conversation. "What am I looking at?" while pointing at a building.

Function Calling — Teaching Models to Use Tools

An LLM by itself can only generate text. Function calling is how we give it hands — the ability to actually do things in the real world: check calendars, send messages, query databases, and generate UIs.

Imagine you hire a brilliant consultant who knows everything about everything — but they're locked in a room with no phone, no computer, and no internet. They can give you amazing advice, but they can't actually do anything. That's an LLM without function calling.

Function calling gives the consultant a phone. You tell them: "Here are the apps on this phone and what each one does." When they need to check something or take an action, they tell you which app to use and what to type in. You execute it, show them the result, and they continue their work.

The mechanics

The function calling lifecycle has exactly four steps. Every agentic system — including generative UI — follows this pattern:

How different providers implement it

The concept is identical across providers, but the API syntax differs slightly:

OpenAI / GPT

// Defining tools
tools: [{
  type: "function",
  function: {
    name: "get_weather",
    description: "Get current weather for a city",
    parameters: {
      type: "object",
      properties: {
        city: { type: "string", description: "City name" }
      },
      required: ["city"]
    }
  }
}]

// Model response when it wants to call a tool:
{
  "choices": [{
    "message": {
      "tool_calls": [{
        "id": "call_abc123",
        "function": {
          "name": "get_weather",
          "arguments": "{\"city\": \"San Jose\"}"
        }
      }]
    }
  }]
}

Anthropic / Claude

// Defining tools
tools: [{
  name: "get_weather",
  description: "Get current weather for a city",
  input_schema: {
    type: "object",
    properties: {
      city: { type: "string", description: "City name" }
    },
    required: ["city"]
  }
}]

// Model response when it wants to call a tool:
{
  "content": [{
    "type": "tool_use",
    "id": "toolu_abc123",
    "name": "get_weather",
    "input": { "city": "San Jose" }
  }]
}

Google / Gemini

// Defining tools
tools: [{
  function_declarations: [{
    name: "get_weather",
    description: "Get current weather for a city",
    parameters: {
      type: "object",
      properties: {
        city: { type: "string", description: "City name" }
      },
      required: ["city"]
    }
  }]
}]

// Model response when it wants to call a tool:
{
  "candidates": [{
    "content": {
      "parts": [{
        "functionCall": {
          "name": "get_weather",
          "args": { "city": "San Jose" }
        }
      }]
    }
  }]
}

Notice the pattern: the schema definition is nearly identical (JSON Schema), but each provider wraps it differently. The model's response always contains: which function to call, and what arguments to pass. Your code handles the rest.

Why tool descriptions matter enormously

The model chooses which tool to call based entirely on the description field and parameter descriptions. Bad descriptions lead to wrong tool selection. This is a product/design decision:

RAG — Giving AI Access to Knowledge

LLMs only know what was in their training data. RAG (Retrieval Augmented Generation) connects them to external knowledge at query time: your documents, your database, your company wiki.

Imagine you're taking an exam. A standard LLM takes it closed-book, answering from memory. RAG takes it open-book: before answering, it searches a library, pulls out relevant pages, reads them, and answers using both memory and the retrieved material. Most production AI assistants are open-book exams. The interesting work is in how you build and search the library.

The pipeline, end to end

RAG is usually drawn as four boxes. That hides where it actually breaks. Real systems have eight stages, split between work you do once at build time and work you do on every query.

Chunking is where most teams lose

The boringest stage in the pipeline is the one that decides whether RAG works. A chunk too big returns noisy passages with the answer buried inside. A chunk too small loses the surrounding context the model needs to interpret it. There's no universal right answer — different content shapes want different strategies.

Beyond plain vector search

Vector search alone is the 2023 baseline. The 2026 production stack adds three things:

Hybrid search combines dense vectors (good for meaning) with sparse keyword search like BM25 (good for exact matches: error codes, product SKUs, legal citations). Vectors miss "ERR_4032"; BM25 nails it. Run both, merge the results. This single change usually beats any amount of tuning to vectors alone.

Reranking takes the top 20–100 results from the cheap retriever and re-scores them with a slower, more accurate cross-encoder model (Cohere Rerank, Voyage Rerank, or a fine-tuned encoder). Cross-encoders look at the query and document together, so they catch nuance that bi-encoder vectors miss. Typical lift: 10–30% on retrieval quality for the cost of one extra model call.

Query rewriting handles the gap between how users phrase questions and how documents phrase answers. HyDE (Hypothetical Document Embeddings) is the well-known move: ask the LLM to draft a hypothetical answer first, then embed and search using that. The drafted answer often shares more vocabulary with real documents than the original question did. For multi-turn chats, query rewriting also rolls earlier turns into a self-contained search query so retrieval doesn't lose context.

Knowledge graphs deserve a mention. When relationships matter more than passages — "who reports to whom," "what's connected to this incident" — a graph beats vectors. Most teams won't need this; the ones that do, know.

RAG vs fine-tuning vs long-context

By 2026 these are three real options, not one. Picking the wrong one costs months. The shape of the choice:

The 2026 default order: prompt engineering first, then long-context if the corpus fits, then RAG when it doesn't, then fine-tuning only if behavior is still off. Many teams skip straight to fine-tuning because it sounds sophisticated. Most regret it.

Why RAG matters for product design

RAG creates UX problems pure chatbots don't have, and the design work is what separates trusted products from suspicious ones:

• Citations are not optional. If the AI says "our refund policy allows 30-day returns," users need to see which document that came from. Inline numbered citations (Perplexity) and "based on" panels (NotebookLM) are now table stakes.
• Scope is part of the product. Tell users what the system can and can't see. "This assistant knows your support docs but not Slack" prevents the worst failure mode: confident answers about things the system never had access to.
• Retrieval latency is visible. Search adds 100–500ms before the model starts streaming. A "searching your docs…" state makes that wait feel like work, not lag.
• Empty retrieval needs its own UI. When the search finds nothing relevant, the model must say so instead of inventing an answer. This is mostly a prompt problem ("if no sources are relevant, say you don't know") but the UI should also reflect zero-source answers differently.

The Agentic Loop — How Agents Reason and Act

A single function call is useful. But real agents call multiple functions in sequence, make decisions based on results, and adapt when things go wrong. This is the agentic loop.

The difference between a chatbot and an agent is simple: a chatbot responds once. An agent keeps going until the task is done.

A real multi-step example

Let's trace through a realistic generative UI agent scenario: the user says "Schedule dinner with Alex this Friday at a good restaurant near home."

Four tool calls, each building on the last. The model maintained context across all of them, made decisions based on intermediate results, and adapted when the first time slot wasn't available. That's an agent.

MCP — The Universal Plug for AI

Function calling lets a model use tools. But who decides which tools exist and how to connect to them? That's the problem MCP solves.

MCP (Model Context Protocol) is an open standard created by Anthropic that standardizes how AI models discover and use tools across any application. Think of it as USB for AI.S4

What an MCP server exposes

An MCP server provides three things to the AI model:

1. Tools — Functions the model can call (like create_event, search_files)
2. Resources — Data the model can read (like file contents, database records)
3. Prompts — Reusable prompt templates (like "summarize this document")

Here's what a simple MCP server for a fitness app looks like:

// MCP Server: Fitness Tracker
{
  "name": "fitness-tracker",
  "version": "1.0",
  "tools": [
    {
      "name": "log_workout",
      "description": "Record a completed workout session",
      "inputSchema": {
        "type": "object",
        "properties": {
          "exercise": { "type": "string", "description": "e.g. 'bench press'" },
          "sets": { "type": "number" },
          "reps": { "type": "number" },
          "weight_lbs": { "type": "number" }
        },
        "required": ["exercise", "sets", "reps"]
      }
    },
    {
      "name": "get_weekly_summary",
      "description": "Get workout stats for the current week",
      "inputSchema": {
        "type": "object",
        "properties": {
          "week_offset": {
            "type": "number",
            "description": "0 = this week, -1 = last week"
          }
        }
      }
    },
    {
      "name": "set_goal",
      "description": "Set a fitness goal for a specific exercise",
      "inputSchema": {
        "type": "object",
        "properties": {
          "exercise": { "type": "string" },
          "target_weight": { "type": "number" },
          "target_date": { "type": "string", "format": "date" }
        },
        "required": ["exercise", "target_weight"]
      }
    }
  ]
}

Orchestration Patterns — ReAct, Chains, and Routing

There's more than one way to build an agent. The orchestration pattern you choose shapes everything: reliability, speed, cost, and user experience.

Pattern 1: ReAct (Reasoning + Acting)

This is the pattern from Chapter 8 — the model alternates between thinking and acting. It's the most common and most flexible pattern.

Pattern 2: Parallel Tool Calls

When multiple independent tools need to be called, a smart agent calls them all at once instead of sequentially:

Pattern 3: Router Pattern

A lightweight model classifies the request and routes it to specialized handlers:

Agents in Production — Trust, Control, and the Real World

The primer has covered how agents work mechanically. This chapter covers what happens when you ship them to real users — the UX patterns, trust frameworks, and protocols that make agents usable.

57% of organizations now have agents in production. But "production" doesn't mean "autonomous." The biggest lesson from 2025-2026: users want agents that are powerful but controllable. The UX challenge is designing the right level of autonomy for each context.

Six core agent UX patterns

1. Intent Preview: Agent shows its plan before acting. "I'll check your calendar, find restaurants nearby, and book one. OK?"
2. Autonomy Dial: Users can adjust how much control the agent has. Gmail's Smart Compose (draft) vs Autopilot (send).
3. Action Audit: Every agent action is logged and visible. Users can see what happened, when, and why.
4. Confidence Signals: Agent shows how certain it is. High confidence = proceed. Low confidence = ask for human input.
5. Escalation Pathways: When the agent is stuck or unsure, it hands off to a human smoothly — not as a failure, but as designed behavior.
6. Scope Cards: Panels showing what the agent can and cannot access. "This agent can read your calendar and email but cannot make purchases."

Computer Use agents

A new category: agents that literally see and control screens. Claude Computer Use operates a full macOS desktop. OpenAI's Operator controls a remote browser. Google's Project Mariner works inside Chrome. These agents take screenshots, click buttons, type text, and navigate apps just like a human would.

The UX challenge is unique: the user watches their screen being controlled by an AI. This requires real-time observation (screen sharing), permission gates before sensitive actions, and a kill switch to stop the agent immediately.

Observability — debugging an agent that thinks for itself

A multi-step agent fails in ways a single API call doesn't. It picked the wrong tool. It called the right tool with bad arguments. It looped. It silently degraded after a model upgrade. The only way to debug any of this is a trace — a structured log of every model call, every tool call, every input, every output, in order. By 2026 this is standard infrastructure: each step gets a span, the trace tree shows the full reasoning path, and you can replay a failing run in isolation. LangSmith, Braintrust, and Langfuse are common platforms; OpenTelemetry's GenAI semantic conventions define emerging shared fields for model calls, tool calls, token usage, latency, and errors.S7 The headline rule: if you can't replay a bad run with the exact same inputs, you can't fix it. Build trace capture before you build the second tool.

Error Handling — When Agents Fail Gracefully

Agents fail. APIs time out, models hallucinate, tool calls return unexpected data. How you handle failure defines the user experience.

In a traditional app, errors are predictable: network error, invalid input, server down. In an agentic system, you get entirely new failure modes:

The graceful degradation ladder

A well-designed agentic UI should degrade gracefully through these stages:

AI Safety & Guardrails — Keeping AI in Bounds

Guardrails are the protective systems that prevent AI from generating harmful content, leaking private data, or acting beyond its intended scope. In 2026, they're also a regulatory requirement.

An LLM without guardrails will attempt anything you ask. Guardrails constrain it — blocking harmful content, filtering personal data, preventing jailbreaks, and keeping the AI focused on its intended task. Think of them as the brakes on a very powerful car.

The UX of guardrails

When a guardrail triggers, the user sees... something. What they see is a design decision that directly affects trust:

• Content blocked: "I can't help with that" — but explain why and offer alternatives.
• PII detected: The system redacts sensitive information before processing. Show what was redacted and why.
• Low confidence: The model isn't sure its answer is correct. Show confidence indicators or suggest verification.
• Action gate: Before an irreversible action (sending an email, making a purchase), require explicit confirmation.

Evaluation — Measuring If AI Actually Works

A model scoring 90% on a benchmark might still frustrate real users. Evaluation is how you close the gap between measured performance and experienced quality.

Quality is the #1 barrier to production AI — cited by 32% of teams as their top challenge. "Running evals" is the AI equivalent of usability testing: you systematically check whether the system works for real scenarios, track scores over time, and use the data to decide what to ship.

The eval process, step by step

Step 1: Define what "good" means

This is the hardest and most important step. Writing a grading rubric is the same skill UX researchers use when creating annotation guides for usability studies — and it has the same failure mode: a vague rubric produces noisy, irreproducible scores no matter how good the grader is.

// Example rubric for a customer support bot
{
  "accuracy": {
    "5": "Correct answer with all relevant details",
    "3": "Partially correct, some wrong info",
    "1": "Completely wrong or hallucinated"
  },
  "helpfulness": {
    "5": "Fully resolved the user's issue",
    "3": "Some useful info but didn't resolve",
    "1": "Useless or made things worse"
  }
}

The three grading approaches

LLM-as-judge, the careful version

Using a strong model to grade a weaker model's output is now standard. It scales. It's cheap relative to humans. And it's full of biases that quietly invalidate your scores if you're not careful.

Two practical defaults: require chain-of-thought from the judge ("explain your reasoning before giving a score") — it forces the judge to actually engage with the rubric instead of pattern-matching. And calibrate against humans periodically: have humans grade 50–100 examples, compare to the judge, and treat low-agreement criteria as untrustworthy until you fix the rubric.

Regression testing across model versions

Every model upgrade — Sonnet 4.5 to 4.6 to 4.7, GPT-4o to GPT-5, Gemini 2.5 to whatever's next — is a behavior change in production. Sometimes it's a big upgrade. Sometimes a regression on the queries that matter most to you. The only way to know is to keep a frozen golden set and re-run it on every new model.

The minimum viable version: ~200 examples that represent your real query distribution (sampled from production logs, scrubbed), with expected outputs or rubric scores. On every model upgrade or prompt change, re-run the set, diff the per-example scores against the previous run, and flag regressions before they ship. Most eval platforms (Braintrust, LangSmith, Langfuse) make this a one-click operation.

Two non-obvious things:

• Score deltas matter more than absolute scores. Going from 87% to 91% on a custom rubric tells you the change helped. Whether 91% is "good" depends on the use case.
• Watch the tail. Average score can stay flat while the worst 5% gets dramatically worse. Track p10 and p50 separately, not just the mean.

Online evals — what users actually do

Offline evals tell you the model is correct. Online evals tell you the product works. They measure different things and you need both.

• Implicit signals are usually more honest than explicit ones. Did the user accept the suggestion? Did they edit it heavily? Did they ask the same question again two minutes later? These are the real quality signal.
• Thumbs up/down is noisy on its own. Users thumb-down when frustrated for any reason, and the silent majority never clicks anything. Use it as a leading indicator and a way to surface failure cases for human review — not as your headline metric.
• A/B test prompts and models like you'd test any product change. Run two variants against real traffic, measure outcomes (acceptance rate, task completion, retention), and decide on data, not on which version "felt" better in the demo.
• Mind the gap between "accepted" and "correct." A user can accept a wrong answer because they trusted it. The METR finding (below) is exactly this gap at scale.

The five things every eval program tracks

Drop the "types of evaluation" framing — it's the wrong axis. The right axis is: what dimension of quality are you measuring, and which method gives you the cheapest reliable signal on it?

On-Device vs Cloud — The Tradeoff Triangle

Mobile platforms are increasingly running models both in the cloud AND on the device itself. Understanding this dual architecture is essential for anyone designing AI-powered experiences.

Every AI request faces a three-way tradeoff between latency, quality, and privacy. Whether you're building for mobile, web, or desktop — there is no option that wins on all three.

Practical comparison

Cost, Latency & the Performance Triangle

Every AI product lives inside a triangle: quality, speed, and cost. You can optimize two at the expense of the third. Every design decision shifts the balance.

The numbers designers should know

Prompt caching — the single biggest cost lever in 2026

Prompt caching is the rare optimization that's both massive and free. By 2026 every major provider supports it (Anthropic, OpenAI, Google), and any production app with a non-trivial system prompt that isn't using it is leaving 50–90% of input cost on the table. It deserves more than a bullet point.

What it actually does. Every API call has a prefix that almost never changes — the system prompt, tool definitions, few-shot examples, sometimes a long retrieved document. The provider runs that prefix through the model once and stores the resulting internal state on their side. When your next call arrives within the cache window, the provider skips re-processing the prefix and starts from the cached state. You're billed at roughly 10% of the normal input rate for the cached portion.

What's cacheable. Anything that's identical across calls and lives at the start of the prompt: system instructions, tool/function definitions, few-shot examples, large retrieved documents shared across users. Anything that varies per user — chat history, the user's question — has to come after the cacheable prefix.

The 5-minute TTL gotcha. Most providers expire idle caches after ~5 minutes. A product with steady traffic gets near-100% cache hits and pockets the savings. A product with bursty or low traffic mostly pays for misses. If your traffic is uneven, batch user requests through a small pool of "warm" sessions, or consider Anthropic's longer-TTL extended cache (1 hour) for high-leverage prompts.

Worked example. A support bot with a 2,000-token system prompt, processing 1,000 messages/hour at ~80% cache hit rate on Sonnet 4.6: caching saves roughly $50/day, or $1,500/month — about 90% of what you'd otherwise spend on input tokens. That's an extra ~$18K/year in margin, gained by adding one parameter to your API call.

How inference gets faster and cheaper

In Chapter 2 we defined inference as the process of using a trained model to generate output. Every response your product generates is an inference call. The AI industry has developed several techniques to make these calls faster and cheaper — and understanding them helps you make product architecture decisions.

The inference provider landscape

An important distinction: the company that trained a model isn't always the company that serves it. Meta trains Llama. But you can run Llama inference through AWS Bedrock, Together AI, Fireworks, Groq, or your own servers. This decoupling matters because:

• Price competition: Multiple inference providers serve the same model, so they compete on price and speed. Llama on Groq is faster than Llama on a generic cloud GPU.
• Portability: If you build on an open model (Llama, Mistral, DeepSeek), you can switch inference providers without changing your product. If you build on a proprietary model (GPT-4o, Claude), you're locked to one provider.
• On-premise options: For regulated industries (healthcare, finance), running inference on your own servers keeps data in-house. This is only possible with open models.

When self-hosting open models beats APIs (and when it doesn't)

By 2026 open models — Llama, Mistral, DeepSeek, Qwen — are competitive with closed frontier models on most non-frontier tasks. That makes "should we self-host?" a real question instead of an obvious no. The answer is still usually no, but the exceptions matter.

The hidden cost of self-hosting isn't the GPUs. It's the ops team. Running production inference well — autoscaling, monitoring, model upgrades, security patching, handling traffic spikes — is a full-time SRE function. Most teams that try it eventually move back to a hosted inference provider (AWS Bedrock, Together AI, Fireworks, Groq) which gives them the open-model portability without the ops burden. The genuinely-self-hosted population is small and specialized.

AI-Generated UI — From Model Output to Rendered Interface

Everything in this book converges here. Generative UI takes an LLM's structured output and transforms it into rendered interface components — React on web, SwiftUI on iOS, Jetpack Compose on Android, or any other renderer.

Let's trace the full journey — from a user's voice to pixels on screen — using everything we've learned:

The generative UI schema (conceptual)

At its core, generative UI defines a tree of components. Each component has a type, properties, and optional children. The model generates this tree, and a platform renderer turns it into native UI:

// generative UI response for "Show my workout stats"
{
  "root": {
    "type": "Column",
    "children": [
      {
        "type": "Text",
        "value": "This Week's Workouts",
        "style": "headlineMedium"
      },
      {
        "type": "Card",
        "variant": "elevated",
        "children": [
          {
            "type": "Row",
            "mainAxisAlignment": "spaceBetween",
            "children": [
              { "type": "Text", "value": "Sessions", "style": "labelLarge" },
              { "type": "Text", "value": "4 of 5", "style": "bodyLarge" }
            ]
          },
          {
            "type": "LinearProgressIndicator",
            "progress": 0.8,
            "color": "primary"
          }
        ]
      },
      {
        "type": "Card",
        "variant": "outlined",
        "children": [
          { "type": "Text", "value": "Top Exercise", "style": "labelLarge" },
          { "type": "Text", "value": "Bench Press — 185 lbs × 5", "style": "titleMedium" },
          {
            "type": "Button",
            "label": "View Details",
            "action": { "type": "navigate", "target": "workout_detail" }
          }
        ]
      }
    ]
  }
}

Notice: the component names (Column, Card, Row, Text, Button, LinearProgressIndicator) map to standard UI primitives available in any framework — React, SwiftUI, Compose, Flutter. The style tokens (headlineMedium, labelLarge) map to a design system. The renderer walks this tree and emits native components for whatever platform you target.

Skills & Customization — Teaching AI How You Work

Out of the box, an LLM is a generalist. Skills, instructions, and project configs are how you turn it into a specialist that knows your tools, your conventions, and your workflow.

Every major AI provider has built a system for customizing how their models behave. The names differ but the core idea is the same: give the model persistent context about how you want it to work, not just what you want it to do right now.

Think of it as a spectrum from simple to powerful:

Layer 1: System Prompts

The simplest form of customization. A system prompt is a set of instructions sent to the model before the user's message. Every API call can include one. It tells the model who it is and how to behave.

// System prompt example
{
  "system": "You are a senior UX researcher. When analyzing user feedback,
             always identify the underlying need behind the stated request.
             Format findings as: Observation → Insight → Recommendation.",
  "messages": [
    { "role": "user", "content": "Users keep asking for a dark mode toggle." }
  ]
}

System prompts are powerful but have a key limitation: they're ephemeral. Every new conversation starts from scratch unless you manually include the system prompt again. They also eat into your context window (Chapter 3) since they're sent with every message.

Layer 2: Custom Personas & Reusable Behaviors

The next step up: save your system prompts as reusable personas that persist across conversations. Each provider has a different name for this:

Layer 3: Project Configs — Codebase-Aware Context

This is where things get interesting for people who work in code-adjacent roles. Project configs give the AI persistent knowledge about a specific project, its conventions, and its structure.

The pattern was popularized by AI coding tools and is now spreading to broader AI workflows:

CLAUDE.md vs plan.md

In Claude Code's workflow, there's an important distinction between two types of files:

The two work together: CLAUDE.md tells the agent how to work in this project. plan.md tells it what to work on right now. One is stable, the other is ephemeral.

Layer 4: Skills — Modular, Executable Capabilities

Skills go beyond instructions. A skill is a packaged capability that the AI can execute, not just follow. Skills combine instructions, tool definitions, and sometimes code into a reusable module.

The key difference between a skill and a system prompt: a system prompt says "you are a UX researcher." A skill says "when the user asks you to analyze feedback, here's the exact process to follow, here are the tools to use, here are examples of good output, and here's how to format the result." Skills are procedural, not just descriptive.

How the major providers approach skills

Each AI provider has a different philosophy and architecture for customization. Understanding these differences matters because they shape what you can build and how portable your workflows are.

The key differences that matter

Portability

Claude's approach is file-based: CLAUDE.md and skill files live in your repo. If you switch tools or providers, those files still work as documentation. A Custom GPT lives on OpenAI's platform. If you leave, you lose it. Google's Gems are tied to your Google account.

Composability

Claude's skill system is modular. You can have a "create-docx" skill, a "design-doc" skill, and a "frontend" skill, and they compose together in the same session. The model reads whichever skill files are relevant. OpenAI's Custom GPTs are monolithic: one GPT, one system prompt, one set of tools. You can't easily mix GPTs together.

Tool integration

This is where MCP (Chapter 9) becomes the differentiator. Claude uses MCP as the universal protocol for connecting to external tools. OpenAI uses GPT Actions (custom API integrations defined per-GPT). Google uses Extensions (pre-built connectors to Workspace apps). MCP is open and any tool can implement it. GPT Actions and Extensions are vendor-specific.

Where this is heading

The lines between these approaches are blurring fast. MCP is being adopted beyond Claude (Cursor, Windsurf, and others now support it). OpenAI is moving toward more composable tools. Google is opening up Gemini's extension system.

The convergence point: a world where you define your team's AI configuration once (conventions, tools, knowledge, workflows) and it works across any AI tool your team uses. We're not there yet, but the trajectory is clear. The teams investing in structured AI customization now will have a significant advantage as these systems mature.

Memory and Personalization

Customization (above) is what you tell the AI. Memory is what the AI learns about you over time. Every major provider now has a memory system: ChatGPT stores facts across conversations, Claude encrypts and exports memories, Gemini imports histories from competitors.

It helps to name the layers, because they have different shelf lives and different governance needs:

• Working memory — the current conversation. Lives in the context window. Disappears when the chat ends.
• Episodic memory — facts about specific past interactions ("user mentioned they're allergic to peanuts on March 3"). Time-stamped, often retrieved when topically relevant.
• Semantic memory — durable facts about the user ("works in product management at a fintech," "prefers terse responses"). Accumulates and gets summarized over time.

The UX patterns for memory are standardizing: transparency (see what the AI remembers), editing (correct or delete memories), scoping (global vs project-specific), staleness management (refresh outdated info), and portability (export and import between providers).

AI Product Archetypes — Choosing the Right Pattern

Not every AI feature should be a chatbot. There are distinct product patterns, each with different UX, architecture, and user expectations. Choosing wrong costs months.

Every AI product maps to one of six archetypes. The archetype determines the interaction model, the trust requirements, the latency budget, and the failure modes you need to design for.

The copilot vs agent decision

The most common product debate in 2026: should this feature be a copilot (AI assists, human decides) or an agent (AI acts, human supervises)? The answer depends on three factors:

• Reversibility: Can the action be undone? Reversible actions (drafting text, suggesting code) → copilot is fine. Irreversible actions (sending emails, deploying code, making purchases) → needs agent-level guardrails or stays as copilot.
• Risk: What's the cost of a mistake? Low risk (wrong autocomplete suggestion) → copilot. High risk (wrong medical advice, wrong financial transaction) → copilot with strong verification, or don't use AI at all.
• Frequency: How often does the user do this task? Daily repetitive tasks benefit from agent automation. Rare high-stakes decisions benefit from copilot augmentation.

Same need, six implementations

The best way to understand archetypes: take one user need and see how each pattern handles it differently.

How products evolve across archetypes

Products don't stay in one archetype. They evolve along a predictable path — usually from lower autonomy to higher:

Context Engineering — The Prompt Is the Product

Prompt engineering was about writing good instructions. Context engineering is about designing the entire information environment the model sees — and it's now the most important product decision in AI.

The term "context engineering" was popularized by Andrej Karpathy in 2025 and has since become the standard framing. The insight: what matters isn't just the prompt — it's everything in the context window. System instructions, retrieved documents, conversation history, tool outputs, and examples all shape the model's behavior.

The system prompt is the product spec

In traditional software, the product spec becomes code. In AI products, the product spec is the system prompt. Want the bot to be concise? That's a prompt instruction. Want it to always cite sources? Prompt instruction. Want it to refuse certain topics? Prompt instruction. The system prompt is the single most leveraged artifact in an AI product — and iterating on it is how you ship improvements without changing any code.

Prompt techniques every PM should know

Before and after: prompt quality matters

Prompt iteration as product development

• Version control: System prompts live in the repo, in code review, and in PRs. Every change is tracked, reviewable, and reversible. A prompt change is a product change — treat it like one.
• A/B testing: Run two prompt variants against real traffic. Measure outcomes (acceptance rate, task completion, retention) using the online evals from Chapter 17. Decide on data, not gut.
• Regression testing: Every prompt change runs against the golden eval set before merge. Score deltas are visible in the PR. Anything that drops the worst-case quintile gets a second look.
• Drift detection: Even a frozen prompt drifts when the underlying model upgrades, or when the data distribution shifts. Re-run your eval suite on a schedule (weekly is normal), alert on score deltas, and re-tune before users notice.
• Collaborative editing: PMs, designers, researchers, and engineers all contribute. It's the most cross-functional artifact in the product, and it tends to live in whichever doc the team will actually open — the repo, a Notion page, the eval platform.

AI Business Models — How AI Products Make Money

Traditional SaaS costs almost nothing per additional user. AI products spend real money on every API call. That single fact rewrites pricing, margins, and which features are worth shipping at all.

The fundamental economic difference: serving one more user on Figma costs Figma almost nothing. Serving one more query on ChatGPT costs OpenAI real money — model inference, compute, and API fees. This marginal cost per request is what makes AI product economics different from everything that came before.

Pricing models in the wild

Unit economics designers should understand

• Cost per query: A single GPT-4o API call costs ~$0.01-0.05. At 1M queries/day, that's $10K-50K/day in API costs alone. Every design decision that increases response length or triggers additional API calls affects this directly.
• The output tax: Output tokens cost 3-8x more than input tokens. A verbose AI response costs significantly more than a concise one. "Be helpful and thorough" in a system prompt is literally expensive.
• Gross margin: Traditional SaaS: 80-90% gross margin. AI products: 50-65% gross margin. The difference is inference cost. This is why AI startups need to be much more careful about feature scope.

Worked example: unit economics of a support bot

Moats & Defensibility — What's Yours When Everyone Has AI

When every product can access the same foundation models, what makes yours defensible? The models are commoditizing. The value is moving to the layers above and below.

Here's the uncomfortable truth: if your product's value proposition is "we use GPT-4o to do X," your competitor can ship the same thing in a week. The model is an API call. The moat is everything else.

The six AI moats

1. Proprietary data: Data the model was fine-tuned on or that your RAG pipeline accesses. Bloomberg built BloombergGPT on proprietary financial data no competitor has.
2. Data flywheel: User interactions improve the product, which attracts more users, generating more data. Every Spotify listening session makes recommendations better.
3. Workflow integration: When your AI is deeply embedded in the user's daily workflow, switching costs are enormous. Cursor's deep IDE integration makes it painful to leave.
4. Distribution: Reaching users first. Apple Intelligence ships on every iPhone. Google AI is in every search. Distribution > technology.
5. Domain expertise: Understanding the problem deeply enough to build the right eval suite, the right guardrails, and the right UX for a specific vertical. Harvey (legal AI) knows law; a general chatbot doesn't.
6. Compounding context: The longer a user stays, the more the system knows about them. Memory, preferences, project history. Switching means starting from zero.

The moat audit: evaluating your product

Developer Experience for AI — Designing for Builders

AI developer products have unique DX challenges: non-deterministic outputs, complex debugging, and the need to "try before you buy." The playground isn't a nice-to-have — it's the product.

When a developer evaluates an AI API or tool, they go through a predictable journey: try it in a playground → read the docs → build a prototype → hit edge cases → decide to commit or abandon. The DX at each stage determines conversion.

The AI developer journey

What makes AI DX different

• Non-determinism: The same input can produce different outputs. This breaks traditional testing assumptions. Developers need tools to evaluate quality ranges, not exact matches.
• Prompt as code: The system prompt is part of the application logic but it's natural language, not code. Version control, diff tools, and review processes need to accommodate this.
• The playground is the sales pitch: Developers decide within 5 minutes of trying a model whether to invest further. Anthropic Console, OpenAI Playground, and Google AI Studio are competitive weapons.
• Cost visibility: Every API call costs money. Developers need real-time cost tracking, budget alerts, and the ability to set spending limits. Surprise bills kill trust.

Time to wow: the single most important DX metric

How quickly does a developer go from zero to a working demo? This determines adoption more than any feature list. The target: under 5 minutes for a "hello world" equivalent.

AI-specific API design decisions

• Streaming vs batch: Always offer streaming. Users perceive streamed responses as 40-60% faster. Non-streaming feels broken in 2026.
• Non-determinism: The same input can produce different outputs. API contracts should document this. Provide seed parameters for reproducibility when possible.
• Async for agents: Multi-step agent tasks can take minutes. Use webhooks or polling, not blocking HTTP requests. Show progress during long operations.
• Cost transparency: Return token counts and cost estimates with every response. Developers shouldn't need a calculator to estimate their bill.

The AI Ecosystem Map — Where Everything Fits

The AI landscape has dozens of layers and hundreds of companies. Understanding where your product sits — and who the adjacent players are — is essential for strategic positioning.

Build vs buy at each layer

The strategic question for any AI product: which layer are you in, and who are you depending on? If you're an application, you depend on model providers. If you're a model provider, you depend on compute. Every layer has leverage over the ones above it and dependency on the ones below.

The Demo-to-Production Gap — Why AI Products Break at Scale

The demo always works. Production is where AI products fail. Understanding this gap is the difference between a successful launch and an embarrassing one.

Every AI product team has experienced this: you build a prototype, demo it to leadership, everyone is amazed. Then you ship it to real users and it immediately breaks in ways you never anticipated. This isn't a bug — it's a fundamental property of AI systems.

Why demos lie

• Curated inputs: Demos use carefully chosen examples. Real users type misspelled queries, send ambiguous requests, and use the product in ways you never imagined.
• Small scale: 10 demo queries work. 10,000 real queries hit edge cases, rate limits, and failure modes you've never seen.
• Non-determinism: The demo query that produced a perfect answer might produce a terrible one on the next run. AI outputs vary.
• Missing context: Demos happen in a controlled environment. Production has network latency, concurrent users, stale caches, and upstream API failures.

The production readiness checklist

Model regression: when the ground shifts under you

Your product runs on a model you don't control. When the provider updates that model, your prompts can break without any change on your end. This has happened to nearly every AI product team.

Data Flywheels — How AI Products Get Better Over Time

The most powerful AI products aren't the ones with the best model on day one. They're the ones that learn from every user interaction and compound that learning into a better product.

A data flywheel is a self-reinforcing loop: the product generates data from user interactions, that data improves the product, the improved product attracts more users, and more users generate more data. This is the core growth loop for AI products.

What data to capture

• Explicit feedback: Thumbs up/down, ratings, corrections, "this was wrong" reports. Highest signal, lowest volume.
• Implicit feedback: Did the user accept the suggestion? Did they edit the AI's output? Did they retry the query? Did they complete their task? High volume, needs interpretation.
• Failure cases: Queries where the AI failed, hallucinated, or was rejected. These are the most valuable training signals — they show exactly where the product is broken.
• Usage patterns: Which features get used, which get ignored, what times of day, what sequence of actions. This shapes product roadmap, not model quality.

Closing the loop: from thumbs down to better product

The privacy tension

Collecting user data for improvement creates a tension with user expectations of privacy. Different companies handle this very differently:

The trust implication: products that DON'T train on user data can advertise that as a feature. Products that DO train on data get a better flywheel but face privacy scrutiny. This is a genuine strategic tradeoff, not a clear right answer.

When NOT to Use AI — The Most Valuable Skill

The best AI PMs are the ones who kill AI features that shouldn't exist. Knowing when a lookup table, a rule, or a simple search is the right answer is rarer and more valuable than knowing how to build with LLMs.

Every chapter in this primer has implicitly said "here's how AI does X." This chapter asks the opposite question: when is AI the wrong tool?

The replacement test

For any proposed AI feature, ask: "what would this look like without AI?" Often the non-AI version is faster, cheaper, more reliable, and good enough:

Researching AI Products — When Users Can't Tell You What They Want

Traditional user research asks "what do you need?" AI product research is harder because users can't articulate needs for a technology they don't fully understand. The methods have to change.

Nobody asked for "next-token prediction." They asked for "help me write faster." The translation from human need to AI capability is a skill most product teams haven't developed yet.

What's different about AI research

Research methods that work for AI

• Wizard of Oz with AI: Before building, fake the AI with a human behind the scenes. Have a researcher manually generate responses in real-time. This tests whether the capability is valuable before investing in the technology.
• Prompt prototyping: Build a clickable prototype that calls a real LLM API. Takes hours, not weeks. Test with 5-10 users. You're testing the interaction pattern, not the model quality.
• Comparative evaluation: Show users the AI's output alongside a human's output (or alongside the current non-AI experience). Ask: "Which is more helpful?" This grounds evaluation in comparison, not abstract ratings.
• Failure case interviews: Show users examples where the AI fails. Ask: "How bad is this? Would you stop using the product if this happened?" This calibrates your quality bar to user tolerance.
• Longitudinal trust studies: Trust changes over time. A user who loves the AI on day 1 might distrust it by day 30 after encountering a few failures. Study trust over weeks, not sessions.

The delta question

The most important research question for any AI feature: "What's the delta?" Not "is the AI good?" but "is the AI better than what exists today?" If the current experience is a blank text field and the AI fills in a draft, the delta is huge. If the current experience is a well-designed template library and the AI generates slightly different text, the delta is small. Ship features with big deltas. Kill features with small ones.

Trust Calibration — Designing the Right Level of Trust

The goal isn't maximum trust. It's calibrated trust — users trust the AI exactly as much as it deserves to be trusted. Over-trust and under-trust are both product failures.

This is the most nuanced design challenge in AI. Every product sits somewhere on a trust spectrum, and getting the calibration wrong has real consequences.

The trust design toolkit

Trust calibration by domain

Decisions Under Uncertainty — The AI PM's Core Skill

Traditional PMs ship features that work or don't. AI PMs ship features that work 92% of the time and need judgment calls about the other 8%. This chapter is about building that judgment.

Every AI product decision lives in a fog of uncertainty that traditional product decisions don't have. The model might hallucinate. The model provider might change the model. The cost might be unsustainable. A competitor might ship the same thing next week. Here's how to navigate that fog.

The launch threshold framework

Communicating uncertainty to stakeholders

The hardest part of being an AI PM isn't the technology — it's translating probabilistic reality into language that leadership, legal, marketing, and sales can act on.

The gray area decisions

The decisions that define your career as an AI PM aren't the easy ones. They're the ones where there's no clear right answer:

• Should your AI writing tool help students write essays? It's not illegal. It might be unethical. It's definitely revenue. Where's your line?
• Your AI hiring tool works great on average but performs worse for certain demographics. Overall accuracy is higher with AI than without. Ship or don't ship?
• A user is clearly having a mental health crisis in your chatbot. Your AI isn't trained for this. Do you respond? Redirect? Shut down?
• Your competitor shipped your roadmap feature using a newer model. Do you accelerate, pivot, or differentiate?
• The model provider raised prices 30%. Absorb the cost, pass it to users, switch providers (6 weeks of migration), or simplify the feature?

These have no textbook answer. They require product judgment built from experience, values, and deep understanding of your users and business. The primer gives you the technical foundation. The gray areas are where you earn your title.

How an AI Feature Ships — The End-to-End Process

This chapter connects all 33 previous chapters into a single workflow. Here's how a team actually goes from "we should add AI" to a shipped, monitored, improving feature.

Who does what

AI features blur traditional roles. Here's how responsibilities are shifting in 2026:

The emerging "AI builder" role

The lines between PM, designer, and engineer are blurring on AI teams. Microsoft reorganized in 2025 around a unified "Applied AI" function that merges traditional PM and engineering under a single "builder" role. Google's DeepMind product teams have designers writing prompts and PMs reviewing eval results. Startups like Vercel ship AI features where a single person handles prompt design, eval, and UX — because with API-based AI, you don't need separate specialists for each step.

The implication: the most valuable people on AI teams are T-shaped — deep in one discipline, but able to contribute across the prompt-eval-UX loop. A designer who understands evals. A PM who can write and iterate prompts. An engineer who thinks about trust patterns. This primer exists to build that cross-disciplinary fluency.

Production Addendum: The Parts Teams Forget

The workflow above gets the feature shipped. The checklist below keeps it from becoming a beautiful demo that quietly leaks data, loses trust, or collapses when the model changes.

Practical Templates

Glossary — Quick Reference

Every term from this primer, in one place. Reference this whenever a concept from an earlier chapter comes up.

Further Reading — Go Deeper

Curated resources to continue learning. Organized by section. The sources below are also the live references for volatile claims like pricing, context windows, regulatory timing, and model capabilities.

Sources & Fact-Check Notes

AI facts age quickly. Any number tied to model price, context window, latency, benchmark score, legal deadline, or provider feature should be rechecked before publishing externally.

Foundations (Ch 1-8)

• Andrej Karpathy's "Intro to LLMs" — 1-hour video. The single best explanation of how LLMs work, from the former head of AI at Tesla.
• Anthropic's prompt engineering docs — Official guide to writing effective prompts. Practical, not academic.
• Simon Willison's blog — The best ongoing commentary on LLM capabilities, updated weekly.

Agents (Ch 9-13)

• Anthropic's MCP documentation — The spec, SDKs, and a growing list of official MCP servers.
• LangChain's "State of AI Agents" report — Survey of agent engineering patterns, tools, and production challenges.
• Lilian Weng's "LLM Powered Agents" post — Deep technical overview of agent architectures. More engineering-focused.

Production (Ch 14-21)

• Hamel Husain's eval guides — The most practical writing on building evaluation systems for AI products.
• Anthropic's public system prompts — Study system prompts as product artifacts.
• Smashing Magazine's AI UX coverage — UX patterns for trust, control, and accountability in agent interfaces.

Product & Strategy (Ch 22-29)

• a16z AI coverage — Market maps showing where investment and value are flowing in AI.
• Stratechery — Strategic analysis of AI's impact on tech business models.
• Lenny's Newsletter and Podcast — Interviews with AI PMs at product-led companies.

Judgment (Ch 30-35)

• NNGroup's AI UX research — Ongoing research on trust calibration and AI usability.
• Anthropic's Responsible Scaling Policy — A decision framework for capability thresholds. Applicable beyond safety.
• METR's developer productivity study — Essential reading on measuring whether AI actually helps.