AI PM Knowledge Graph

Every concept this course teaches, as one sky. The core is the fundamentals and the rim is the frontier. Click a star to see what it is, why it matters, and which subchapter teaches it.

Every concept this course teaches, written out in the order it is taught: what it is, why it matters, and the subchapter that covers it.

The AI PM knowledge graph changes with the job, adding concepts and redrawing connections as the field shifts.

Foundations (12)

Cost per Token
The price charged for each token a model processes or generates, where a token is a small chunk of text rather than a full word. Vendors quote it as the basic usage unit, but real spend still depends on how many input, output, cached, and repeated tokens your product creates. Why it matters: Useful for quick model comparisons, but insufficient alone when estimating customer level margin. 01.02 Make the API call yourself
Foundation Model
This is a large model trained on broad data to learn general patterns in language, code, images, or other media before being adapted to specific tasks. Teams use it as a starting layer, then shape behavior with prompts, retrieval, fine tuning, or tools instead of building task specific models from scratch. Why it matters: It changes your build versus adapt decision, including whether product advantage comes from model choice, proprietary data, or workflow design. 01.03 One token at a time
Long Context Pricing
Long context pricing is a vendor rule where requests become more expensive once the model has to read very large inputs or long conversation history. Vendors charge this way because reading more text increases memory and compute before generation starts, so product costs can jump even when answer length stays unchanged. Why it matters: It changes feature design for memory, retrieval, and chat history. If costs spike, first ask whether you are overfeeding the model. 01.04 Context windows and attention
Cost per Task
The average total spend required to complete one unit of user work, such as answering a question, drafting an email, or classifying a document. It rolls up all model calls, retries, failures, and supporting services, which makes it more decision useful than raw price per token. Why it matters: Lets you compare workflows and decide whether automation is cheaper than human handling or alternative product designs. 01.06 The AI-or-not decision
Model Card
A document that explains what a model is meant for, how it was evaluated, where it performs well or poorly, and what risks or limits matter in practice. Teams use it when selecting or approving models, because benchmark scores alone do not tell you the safe use cases, blind spots, or operating assumptions. Why it matters: It changes model selection and approval by surfacing limits that benchmark scores hide. 01.07 Read a benchmark honestly
Inference Cost
The cost of running a model to process an input and produce an output in production, usually measured per call, per token, or per completed task. It is often the largest direct cost in an AI product, but it changes with prompt length, output length, retries, model choice, and caching. Why it matters: Changes pricing, model selection, and feature scope by setting the floor under your gross margin. 09.05 Cost per successful task
EU AI Act
The EU AI Act is a European Union law that regulates AI systems based on the level of risk they create, with the toughest duties applied to high risk uses and some practices banned outright. It affects product teams through documentation, transparency, risk management, human oversight, and vendor choices, not just model behavior. Why it matters: It changes go to market, procurement, and feature design by deciding which use cases need controls, records, or should not ship in the EU. 10.06 Procurement
High Risk AI System
A category used in AI regulation for systems whose outputs can significantly affect people's safety, legal rights, or access to important services such as employment, credit, education, or healthcare. Once a use case falls into this category, the builder usually faces stricter requirements for documentation, oversight, testing, monitoring, and incident response. Why it matters: It tells you whether a use case triggers heavy compliance work and whether to avoid, limit, or redesign it. 10.06 Procurement
C2PA
C2PA is an open technical standard for attaching signed metadata to media so people and software can inspect where a file came from and whether it was edited. It supports content provenance, meaning the recorded history of creation and modification, which is useful for AI generated images, video, and journalism. Why it matters: It changes trust and disclosure strategy for synthetic media by letting you verify source claims instead of relying only on visual judgment. 11.03 Image and video generation
Deepfake
A deepfake is synthetic media, usually a voice, image, or video, that convincingly imitates a real person or event using machine learning. It matters in products because realistic fakes can enable fraud, harassment, and misinformation, which is why teams often add provenance, watermarking, or disclosure features when generating or hosting media. Why it matters: It changes abuse prevention, identity verification, and trust features, especially for media generation, sharing, or moderation products. 11.03 Image and video generation
AI Risk Management Framework
The AI Risk Management Framework is a structured approach, published by NIST, for identifying, measuring, and reducing risks from AI systems across design, deployment, and operations. It pushes teams to map how a system is used, govern ownership, test for harms, and keep improving controls as models, data, and contexts change. Why it matters: It changes launch criteria and documentation by making risk review a repeatable process instead of an ad hoc legal or safety debate. 12.06 Right-sized governance
AI Safety Level
An AI safety level is a tier in a risk framework that classifies how dangerous a model or system could be and what safeguards it therefore requires. Organizations use levels to set deployment gates, access controls, testing depth, and escalation rules, especially for frontier capabilities or misuse sensitive applications. Why it matters: It changes launch approval and control intensity. Higher levels mean slower shipping by design because the downside of being wrong is larger. 13.02 Work with researchers

Product craft (17)

Vibe Coding
A person tells a coding model what to build, accepts the generated code, and keeps moving without carefully reading or understanding how it works. This can produce working demos very quickly, especially for throwaway prototypes, but hidden bugs, security issues, and maintenance problems make it risky to promote directly into production. Why it matters: It changes whether you treat model written code as a disposable prototype or as software that needs review, tests, and ownership before launch. 01.01 The AI PM job now
Implicit Feedback
Evidence about quality inferred from behavior rather than asked directly, such as whether people accept, edit, ignore, retry, or abandon an AI output. It is useful when users will not fill out ratings at scale, but the signal is noisy because convenience, speed, and habit can look like satisfaction. Why it matters: It changes what telemetry you instrument and how cautiously you read adoption data. A rise in accepts may mean value, or may hide overreliance and bad defaults. 04.02 Discovery for AI
Model-Upgrade Drill
The model-upgrade drill re-runs a team's own frozen hard-task probe set and eval suite against a new frontier model with the harness held constant, so any change in pass rate is attributable to the model alone. Its purpose is to decide what scaffolding to stop building: a reranker, a verification loop, or a narrow fine-tune that existed only to patch a weakness the release just fixed. Why it matters: Lets a PM re-benchmark a whole system against a new model release in an afternoon and retire the workarounds the frontier has surpassed, the operational half of the capability-horizon call. 04.05 The capability horizon
Tool Approval
A checkpoint where a human must approve a proposed tool action before the system is allowed to execute it. Teams add it to tasks that can spend money, change records, contact customers, or create other real world consequences, so the model can suggest an action without having unilateral control over the outcome. Why it matters: It changes where automation stops and review begins, especially for high risk or irreversible actions. 06.03 The agent spec you own
Generative UI
Generative UI is a pattern where the model returns actual interface components, such as forms, tables, cards, or buttons, instead of only plain text. This lets the system shape the next interaction directly, but it also means product teams must constrain what the model can render and how those components behave. Why it matters: It changes whether you design a conversation, a workflow, or both. It also determines how tightly you must control layout, actions, and safety. 07.01 The four AI design patterns for a surface that
Inline Suggestion
An AI generated suggestion that appears directly inside the document, field, or editor the person is already working in, rather than in a separate chat window. It is often easier to accept, reject, or edit because it shows up at the exact point of work. Why it matters: Shapes workflow fit and acceptance rates. It changes whether AI feels embedded in the task or like a context switch to another tool. 07.01 The four AI design patterns for a surface that
Trust Calibration
Designing the experience so users rely on an AI system about as much as its actual performance deserves, neither overtrusting it nor dismissing it when it is useful. Products do this through cues such as citations, uncertainty signals, previews, and easy ways to verify or correct output. Why it matters: Guides how much evidence, friction, and automation you add. The goal is to prevent both reckless acceptance and needless double checking. 07.01 The four AI design patterns for a surface that
Automation Bias
The tendency for people to accept a system's recommendation and ignore conflicting evidence, especially when the interface makes the recommendation feel authoritative or faster than checking it. In AI products, this can cause users to miss obvious errors because the model sounded confident or matched expectations. Why it matters: Explains why simple warnings often fail. It changes review workflow design, approval steps, and when human oversight is genuinely protective versus mostly cosmetic. 07.02 Levels of autonomy
Overreliance
A user behavior where people trust model output too readily and stop checking whether it is correct, complete, or appropriate. It often appears when the system sounds confident or saves time, causing small model mistakes to flow directly into customer decisions, operations, or published content. Why it matters: Changes UX, confidence signaling, and review requirements when a wrong answer could quietly become a real-world action. 07.02 Levels of autonomy
Explicit Feedback
Explicit feedback is feedback a person knowingly gives, such as a thumbs up, star rating, correction, or written comment. It is usually sparse but high signal because the user is intentionally judging the result, unlike implicit feedback that product teams infer from behavior such as clicks or abandonment. Why it matters: It changes how you tune quality and triage issues, because a small amount of direct judgment can outweigh a large amount of ambiguous behavior data. 07.03 The four surfaces
Confidence Score
A confidence score is a number or label meant to show how sure a model is about an answer, classification, or ranking. It can help prioritize review or trigger fallback behavior, but only if the score is calibrated, meaning its levels reliably match real world correctness rather than merely sounding precise. Why it matters: It changes whether you automate, ask for confirmation, or send work to humans. It warns you not to expose certainty numbers that users will overtrust. 07.06 Claim-level citations
Inline Citation
A source reference placed directly beside a specific claim, sentence, or span of generated text so the user can see what evidence supports that exact part. It is more precise than a list of links at the bottom because it ties each statement to a source. Why it matters: Changes how users verify AI output and where trust breaks. Weak citation design makes unsupported claims look more credible than they are. 07.06 Claim-level citations
AI Disclosure
A clear notice that tells people they are interacting with AI or seeing AI generated content, and often explains what the system is doing for them. Good disclosure sets expectations about limits, automation, or data use in specific terms, which supports informed consent and reduces misplaced trust. Why it matters: It changes copy and interaction design by telling users when they need skepticism, review, or consent. 10.09 Who owns the output
Content Credentials
Content Credentials are a standard way to attach tamper evident metadata to media files that records how a photo, video, or other asset was created or edited. They support provenance, meaning a traceable history of origin and changes, so viewers can inspect claims about camera capture, human edits, or AI generation. Why it matters: It changes how you communicate authenticity and how you respond to manipulated media claims. Use it when trust depends on showing where media came from. 10.09 Who owns the output
Content Provenance
Information that records where a piece of media came from and what happened to it over time, including who created it, what tools touched it, and whether it was edited. Rather than judging authenticity by eye alone, people use provenance to trace origin and history and decide how much trust a photo, video, or document deserves. Why it matters: It changes how you handle authenticity claims. If trust depends on origin, you need capture, storage, and display of provenance, not just detectors or moderation. 10.09 Who owns the output
End-of-Turn Detection
In a voice interface, the system must decide when one speaker is done and the other should start talking. It uses signals like silence length, speaking rate, wording, and audio energy so the conversation feels natural instead of interrupting people too early or pausing so long that the assistant seems slow or confused. Why it matters: It changes perceived responsiveness in voice products. Tune it badly and users feel cut off, ignored, or forced to speak in unnatural bursts. 11.02 Voice
Voice Activity Detection
Voice activity detection is the part of a voice system that decides when speech has started and when it has stopped, separating human talk from silence or background noise. It drives turn taking, interruption handling, and response timing, so weak settings make assistants feel jumpy, laggy, or deaf. Why it matters: It changes perceived responsiveness in voice products. Tune it wrong and users get clipped, interrupted late, or left waiting before the assistant replies. 11.02 Voice

AI product (88)

Hallucination
A model can produce an answer that sounds confident and well formed but is not supported by facts, the prompt, or available source material. This happens because it predicts likely next words rather than checking truth, so it often appears in summarization, customer support, and search answers unless you add grounding, citations, or human review. Why it matters: It changes when you need retrieval, citations, or human review, and when a feature is too risky to automate. 01.01 The AI PM job now
Human in the Loop
A workflow design where the system pauses and asks a person to review, edit, approve, or reject a step before proceeding. It is used when mistakes are costly, rules are hard to encode fully, or you need human judgment for safety, quality, or accountability. Why it matters: Sets where automation should stop and where review is worth the added delay and labor. 01.01 The AI PM job now
Nondeterminism
Nondeterminism means the same input can produce different outputs on different runs, even when settings like temperature are turned down. In hosted models this still happens because the service processes requests in changing batches, so one impressive answer is not proof that a feature is reliable. Why it matters: It changes how you test and launch. You need repeated runs and aggregate results, not a handful of cherry picked examples. 01.01 The AI PM job now
Prompt Engineering
This is the practice of designing the instructions, examples, context, and constraints given to a model so its outputs are more useful and consistent. It often involves repeated testing and revision, because small wording changes can meaningfully alter behavior, formatting, accuracy, and safety. Why it matters: Guides whether better results need prompt changes, model changes, or product safeguards, and who should own that work. 01.01 The AI PM job now
System Prompt
A system prompt is the highest-level instruction sent with a request that sets the model's role, rules, style, and boundaries before user messages are considered. Teams use it to establish consistent behavior across sessions, though later context can still dilute or conflict with it if prompts are poorly designed. Why it matters: Defines baseline behavior and guardrails. It changes reliability, brand voice, safety posture, and how much correction later prompts must do. 01.02 Make the API call yourself
Token
A token is the small unit of text a model actually processes, which may be a whole word, part of a word, punctuation, or whitespace. Costs, rate limits, context size, and output length are all measured in tokens, so token counts matter more operationally than the visible number of words. Why it matters: Affects pricing, latency, and context budgeting. It changes prompt design, message limits, and how expensive long conversations or documents will be. 01.02 Make the API call yourself
Large Language Model
A large language model is a machine learning system trained on massive amounts of text to predict the next token, meaning a small chunk of text such as part of a word. Because it learns statistical patterns in language, it can generate, summarize, classify, and follow instructions across many tasks, though its answers come from pattern matching rather than understanding facts the way people do. Why it matters: It changes model selection and feature design: when the job needs flexible language handling, you can use one model across many workflows, but you must plan for mistakes, cost, and nondeterminism. 01.03 One token at a time
Multimodal Model
A multimodal model can accept, understand, or generate more than one type of data, such as text, images, audio, or video. Instead of treating every request as plain text, it learns relationships across formats, which makes features like image question answering, voice agents, and document parsing possible. Why it matters: Determines whether one model can power text, voice, and vision flows together. It affects UX scope, architecture complexity, and evaluation plans. 01.03 One token at a time
Tokenizer
A tokenizer is the component that converts text into tokens for the model and turns generated tokens back into readable text. Different tokenizers split the same sentence differently, which affects context usage, cost, truncation risk, and sometimes behavior when working with code, numbers, or non-English languages. Why it matters: Prevents surprise cost and truncation issues. It matters when estimating usage, supporting many languages, or moving between model families. 01.03 One token at a time
Training Data
Training data is the collection of examples a model learns from during development, such as text, images, labels, or human rankings that show what patterns to copy or prefer. Its quality, coverage, and bias shape what the system knows, what it misses, and how it behaves later, so gaps in the data often reappear as product failures. Why it matters: It changes your build versus buy and data investment decisions. When outputs fail in a consistent segment, it tells you to inspect coverage, labeling quality, and bias before tweaking prompts. 01.03 One token at a time
Transformer
A transformer is the neural network design behind most modern language models and many image and audio models. It processes many pieces of an input at once and uses self-attention, a method for weighing which earlier words or elements matter most, so it can capture long-range patterns better than older sequence models. Why it matters: Shapes model expectations and vendor comparisons. It explains why modern models handle long prompts, retrieval, and parallel training so well, and where their costs come from. 01.03 One token at a time
Context Engineering
The practice of deciding what information a model should see at each step, in what format, and in what order, given limited context space. It includes choosing instructions, retrieved documents, tool results, memory, and summaries so the model has the right inputs without unnecessary noise. Why it matters: Changes answer quality, cost, and whether the model misses key facts or gets distracted by clutter. 01.04 Context windows and attention
Context Rot
Context rot is the decline in a model's ability to recall or use the right details as the prompt grows large, even before it hits the formal context limit. Important facts get buried, competing instructions accumulate, and attention becomes less effective, so quality can fall long before the window is technically full. Why it matters: Warns against assuming bigger windows always solve memory. It changes how you manage long threads, summaries, and retrieval freshness. 01.04 Context windows and attention
Context Window
The context window is the total amount of tokenized information a model can use in one request, including instructions, prior messages, retrieved material, and often the space reserved for its reply. It functions like working memory for a single turn, setting the hard limit on how much the model can consider at once. Why it matters: Sets memory limits for product design. It determines when you need retrieval, summarization, chunking, or shorter prompts. 01.04 Context windows and attention
Self-Attention
Self-attention is the mechanism that lets each token, meaning a chunk of text, look at other tokens in the same input and decide which ones matter for interpreting it. By computing those relationships at every position, a model can track references, syntax, and dependencies across a sentence or long document. Why it matters: Explains strengths and failure modes in long or tangled prompts. It helps you reason about why wording, order, and repeated instructions change model behavior. 01.04 Context windows and attention
Knowledge Cutoff
A knowledge cutoff is the point in time after which a model has no built-in knowledge from its training data. The model may still answer recent questions by guessing, using live tools, or retrieving current documents, but without those aids its internal knowledge usually stops around that date. Why it matters: Prevents bad assumptions about freshness. It tells you when to add search, retrieval, or tools for current facts instead of trusting the model alone. 01.05 Pretraining vs post-training
Post-Training
The stage after pretraining, the broad text learning phase, where a general base model is adapted for useful behavior using methods like supervised fine tuning and preference training. This is where models learn formats, refusals, tool use, and style more than broad world knowledge, which mostly comes from pretraining rather than this later step. Why it matters: It changes how you diagnose model problems: behavior issues may need a differently post-trained model, not a better prompt or more retrieval. 01.05 Pretraining vs post-training
Pretraining
Pretraining is the initial large-scale training stage where a model learns broad patterns from massive amounts of general data before any product-specific tuning happens. This step teaches language, world knowledge, and basic task skills, and it is so expensive that only a small number of organizations usually run it themselves. Why it matters: Clarifies what a base model already knows versus what fine-tuning must add. It changes sourcing strategy and how realistic custom training plans are. 01.05 Pretraining vs post-training
Reasoning Model
A model designed to work through problems in multiple steps before answering, often using extra computation at inference time, meaning the work done when the model generates a response. It tends to do better on planning, math, coding, and tool use, but usually costs more and responds more slowly than a faster general model. Why it matters: It changes model selection and routing: use it only for tasks where better reasoning beats added latency and cost. 01.05 Pretraining vs post-training
RLHF
RLHF is a training approach where people compare model outputs, those preferences are turned into a scoring system, and the model is optimized to produce responses people prefer. In practice, it is used to make assistants more helpful, safer, and better aligned with human expectations than raw supervised training alone. Why it matters: Explains why models sound helpful yet sometimes overly cautious or flattering. It affects trust, safety expectations, and how you interpret behavior changes across model versions. 01.05 Pretraining vs post-training
Supervised Fine-Tuning
Supervised fine-tuning trains an existing model on labeled examples that show the desired input and output behavior for a task. By learning from many demonstrations, it becomes more consistent in format, tone, and task completion without changing the core pretraining process that gave it general language ability. Why it matters: Helps decide when prompting is not enough. It changes whether you invest in labeled data to improve reliability, structure, or domain style. 01.05 Pretraining vs post-training
Verifiable Rewards
A reward signal in reinforcement learning that can be checked automatically against an objective result, such as whether code passes tests or an answer matches ground truth, meaning a trusted correct answer. Because success is measurable without subjective human judgment, these rewards scale cheaply and usually train more reliably than preference scores alone. Why it matters: It changes whether you should invest in RL for a workflow: tasks with automatic scoring are far more practical to improve at scale. 01.05 Pretraining vs post-training
Benchmark Contamination
Benchmark contamination happens when benchmark questions, answers, or near-duplicates end up in training data, so a model can score well from exposure rather than genuine capability. Once contaminated, the benchmark stops being a clean comparison and overstates real ability. Why it matters: Changes whether you should trust a reported benchmark score. It matters when judging model improvements or selecting vendors. 01.07 Read a benchmark honestly
Frontier Model
A frontier model is one of the most capable general-purpose AI models available at a given time, usually built by a major lab with very large training budgets. The term is relative, not permanent, and usually implies state-of-the-art performance on difficult tasks plus higher cost, scrutiny, and operational risk. Why it matters: Guides build versus buy, pricing tolerance, and risk posture. It changes whether you pay for maximum capability or choose a cheaper, more stable model. 01.07 Read a benchmark honestly
MMLU Benchmark
MMLU is a widely used multiple-choice benchmark that tests a model across 57 subjects, from school topics to professional domains. Because it samples broad factual and reasoning knowledge, it is often cited in model announcements, though strong scores do not guarantee good performance on your product tasks. Why it matters: Gives a quick read on broad academic knowledge. It helps in market comparison, but should not substitute for product-specific evaluation. 01.07 Read a benchmark honestly
Model Benchmark
A model benchmark is a shared test set and scoring method used to compare different models on the same tasks under the same rules. Public benchmarks make claims easier to compare, but they often simplify real work and can be gamed or saturated over time. Why it matters: Helps choose among models and challenge vendor claims. It also warns you not to mistake leaderboard wins for product readiness. 01.07 Read a benchmark honestly
Fine-Tuning
Fine tuning trains an existing model further on your own examples so it follows your style, format, or task requirements more reliably. It is useful when better instructions and examples in the prompt hit a ceiling, but it requires good training data and careful evaluation, because it can improve one behavior while harming others. Why it matters: It changes the build versus buy decision for behavior control. Choose it when repeated prompts and retrieval still cannot make the model consistently act the way you need. 01.08 Attribute every failure to a layer
Retrieval Augmented Generation
A method for answering or writing with outside knowledge by fetching relevant documents at request time and passing them into the model as context. Instead of relying only on what the model memorized during training, the system grounds responses in your current data. Why it matters: Determines whether model knowledge alone is sufficient or whether fresh, source-backed information is required. 01.08 Attribute every failure to a layer
AI Agent
A software system built around a model that can decide the next action, use external tools, and keep working through multiple steps until it reaches a goal. Instead of producing one reply and stopping, it observes results, updates its plan, and continues within limits you set. Why it matters: Determines whether a task needs autonomy, guardrails, and monitoring rather than a simple prompt and response. 01.09 INTEGRATION CASE
Guardrail
A guardrail is a rule, classifier, or control that limits what the system can say or do to reduce unacceptable outcomes. Teams add guardrails around model behavior, tool use, and data access, then tune them to balance safety with false positives, user frustration, and business risk. Why it matters: It changes risk posture and user friction. Guardrails tell you what to block, where to require approval, and how much false positive pain is acceptable. 01.09 INTEGRATION CASE
Agent Loop
The recurring cycle inside an agent where the model looks at the current state, chooses an action, calls a tool, receives the result, and decides what to do next. This loop continues until the task is complete or a limit such as time, cost, or step count is reached. Why it matters: Governs timeout limits, cost ceilings, and where failures can repeat indefinitely. 03.01 Build and iterate in Claude Code
Coding Agent
A coding agent is an AI system that can do software work across several steps, such as reading files, planning edits, running tests, and fixing errors based on the results. Unlike inline autocomplete, it acts toward a goal using tools and feedback loops, which makes supervision, permissions, and rollback much more important. Why it matters: It determines which engineering tasks can be automated safely and where you need approval gates, test harnesses, or human review. 03.01 Build and iterate in Claude Code
Ghost Text
This is faint inline text that previews what the assistant thinks you may want to write next without fully committing it to the document. People can accept, edit, or ignore it, so it speeds drafting and coding while keeping the user in control more than a full auto write action. Why it matters: It changes AI UI design by offering low friction help that preserves agency, especially in writing and coding tools. 03.01 Build and iterate in Claude Code
Pass^k
A reliability measure for agents that runs the same task k separate times and gives credit only when every run succeeds. Because one flaky run makes the whole task fail, it is much stricter than pass@k, which accepts any single successful attempt, and it better matches real user experience when customers cannot quietly retry behind the scenes. Why it matters: It changes your launch bar for agent automation. Use it when you need consistency, not occasional brilliance, and when retries would still feel like failures to customers. 03.05 One output is an example; ten inputs by five r
Capability Threshold
A capability threshold is the point where performance becomes reliable enough for a real task, not just occasionally impressive in demos. Below that point, failure handling and human review dominate the design; above it, automation, pricing, and workflow redesign suddenly become practical because the system can be trusted more consistently. Why it matters: It changes timing and scope. This tells you whether to keep a human in the loop, narrow the job, or automate because performance is finally reliable enough. 04.01 Pre-data bets
Agent
An agent is a system that uses a model to decide what steps to take toward a goal, often by calling tools, checking results, and trying again. Unlike a chatbot that mainly answers in one turn, an agent can plan across multiple actions, keep state, and affect real systems. Why it matters: It decides whether you should automate a workflow or keep a simpler assistant. The term forces a call on autonomy, failure handling, and how much real-world action the product should take. 04.03 The problem-first test
Agentic Workflow
A task structure where the model plans, takes actions, checks results, and revises what to do next instead of answering in a single pass. It usually involves tool calls, intermediate reasoning, and stopping rules, so execution can branch based on what happens during the task. Why it matters: Helps you decide when one-shot generation is enough and when you need a controlled multi-step flow. 04.03 The problem-first test
Data Flywheel
This is a self-reinforcing loop where product usage creates signals about what good or bad outcomes look like, such as edits, rejects, or resolved tickets, and those signals are turned into evaluations or training data. As the system improves on measured tasks, the product becomes more useful, which attracts more usage and generates even more proprietary learning data. Why it matters: It changes what you instrument and collect. You prioritize workflows that produce unique feedback your product alone can capture and reuse. 04.05 The capability horizon
Open-Weight Model
A model with downloadable weights lets you run the learned numerical parameters on your own infrastructure or through a hosting partner instead of calling only the model maker's API. This can improve control over privacy, customization, and deployment, but it does not automatically mean the training data, code, or license terms are equally open. Why it matters: It changes vendor dependence, data handling options, and whether offline or highly customized deployments are feasible. 04.06 Build, buy, or open weights
AI Incident
A documented case where an AI system caused harm, created a serious near miss, or behaved badly enough to require escalation and learning. Examples include unsafe advice, privacy leaks, and damaging automation errors, and treating them as incidents helps teams analyze root causes, improve controls, and prevent repeated failures. Why it matters: It changes postmortem and escalation practice by turning isolated failures into organizational learning. 05.05 Launch readiness and the narrative
Evaluator-Optimizer
A pattern where one model produces a draft and another model critiques it, scores it, or suggests improvements, repeating until the result meets a bar. It can improve quality on complex tasks, but each loop adds cost, latency, and the risk that the evaluator rewards the wrong behavior. Why it matters: It changes whether you chase quality with more reasoning steps or ship a simpler flow. Use it when improvement justifies extra latency and cost. 06.01 Workflow or agent
Prompt Chaining
Prompt chaining breaks one job into a fixed sequence of model calls, where each step uses the previous step's output as input. Teams use it to make complex work more controllable, such as extracting facts before writing a summary, but every extra step adds latency, cost, and another place for errors to compound. Why it matters: It helps you choose between a simpler single call and a more reliable but slower workflow. 06.01 Workflow or agent
Reduce Agency
Reduce agency is the first and cheapest lever on an agent's cost and latency: cut the number of model calls, tool hops, and reasoning passes a task is allowed, because loop count is the biggest single driver of both. It is a product decision, not an engineering one, and it is pulled before caching, routing, or changing the model. Why it matters: Lets a PM lower cost per successful task without degrading quality by capping loops and tool hops first, rather than reaching straight for a cheaper model. 06.01 Workflow or agent
Long-Term Memory
Information stored outside a single conversation so a system can remember facts such as preferences, prior decisions, or project details across sessions. Unlike the context window, which is the temporary text a model can see right now, this memory is saved separately and retrieved later when it seems relevant. Why it matters: It governs whether personalization feels useful or creepy, and what must be editable or forgettable. It also changes architecture, because memory needs storage, retrieval rules, and cleanup. 06.02 The anatomy of an agent
Self Verification
This is a pattern where a model generates an answer, then separately checks whether the answer follows instructions, uses evidence correctly, or contains obvious mistakes. It can improve reliability by adding a second pass or critic step, but it also adds cost and latency and does not guarantee the model can catch its own deepest errors. Why it matters: It changes whether an extra checking step is worth the added latency and token cost for high risk tasks. 06.02 The anatomy of an agent
Excessive Agency
Excessive agency means giving an AI system more tools, permissions, or freedom to act than the task truly requires. Extra autonomy increases the blast radius when the model makes a mistake, follows bad instructions, or is manipulated, so the safest design is usually the least power that still completes the job. Why it matters: It changes tool design and approval flows. If read only access or human confirmation works, do not give write access and automatic execution. 06.03 The agent spec you own
Human on the Loop
Human on the loop is a supervision pattern where software acts on its own most of the time, while a person watches metrics, logs, or sampled cases and steps in only when something looks wrong or risky. Unlike human in the loop, the person does not approve every action, so scale improves but oversight must be designed carefully. Why it matters: It changes how much automation you can safely ship. Use it when full manual review is too slow, but you still need escalation paths, monitoring, and clear interrupt controls. 06.03 The agent spec you own
Agent-Computer Interface
The layer an agent works through to affect the world, including the tools it can call, the actions each tool supports, and the feedback it gets back. It is the agent version of a user interface, and its design strongly shapes reliability, speed, and error rates. Why it matters: Determines whether agents act safely and effectively or misuse tools because the interface is confusing. 06.04 Write the tool contract
Tool Misuse
This happens when an AI agent uses a real capability, such as sending email, running code, or editing records, in a way that is harmful, unauthorized, or outside the job you intended. The risk is not that the tool is fake, but that the agent applies a valid tool to the wrong target, time, or purpose. Why it matters: It changes permission design and launch scope for agents. If misuse risk is high, reduce tool access, add approvals, or narrow the job. 06.04 Write the tool contract
Unbounded Consumption
Unbounded consumption is a business and product risk where usage can grow much faster than revenue or user value, often because each additional request triggers real compute cost. AI copilots, agents, and generous free tiers are prone to it, so teams need limits, pricing, and product guardrails before scale turns growth into a margin problem. Why it matters: It changes packaging and limits. If usage is uncapped, a few heavy accounts can erase gross margin and destabilize infrastructure. 06.05 Inside the harness
Deep Research
Deep research is an agentic workflow where an AI system gathers information across many sources, follows leads, and iteratively refines a report instead of answering in one shot. It usually combines search, retrieval, note taking, and citation so the output is broader and better sourced, but also slower, costlier, and harder to verify. Why it matters: It changes whether you optimize for answer speed or investigation quality, and how much citation, review, and budget control the experience needs. 06.07 When multi-agent is worth it
Multi-Agent System
A setup where multiple agents work together on one larger job, usually with different roles such as coordinator, researcher, reviewer, or executor. The promise is specialisation and parallel work, but it also adds coordination overhead, consistency problems, and more places for errors to appear. Why it matters: Guides whether extra specialization is worth the added complexity, latency, and debugging burden. 06.07 When multi-agent is worth it
Subagent
A separate agent instance created to handle one focused subtask, often with its own prompt, tools, or temporary context, and then return a result to the parent process. This helps isolate work so the main agent does not carry every detail of every subproblem at once. Why it matters: Helps you split complex work, reduce context bloat, and localize failures to one branch. 06.07 When multi-agent is worth it
Agent Handoff
Agent handoff is when one agent passes a task, its current state, and any useful context to another agent that is better suited to finish it. This is common in multi-agent systems, but the handoff only works well if responsibilities are clear and the receiving agent gets enough information without inheriting unnecessary confusion or permission. Why it matters: It determines failure points in agent workflows, especially lost context, duplicate work, and overbroad permissions. 06.08 Agent user surfaces
Chain of Thought
A prompting pattern where the model writes intermediate reasoning steps before the final answer. It can improve performance on multi step tasks such as math, planning, or extraction by breaking the problem into smaller moves, though showing the reasoning can also add latency, cost, and opportunities for mistakes to leak into the visible answer. Why it matters: Changes prompt design, UI, and safety choices. It determines when to ask for visible reasoning, when to hide it, and whether the extra tokens are worth the cost. 06.09 Structured outputs are a decoding constraint
Model Refusal
When an AI system declines to answer or complete a request because the request breaks a safety policy, product rule, or legal constraint. A good refusal does more than say no: it recognizes genuinely risky cases, avoids refusing harmless ones, and often offers a safe alternative, which affects both safety outcomes and user trust. Why it matters: It changes policy and UX decisions by balancing false accepts against false refusals, especially in sensitive domains. 06.09 Structured outputs are a decoding constraint
Suggested Prompt
This is a prewritten example prompt shown in the interface to help users start faster and ask in ways the system handles well. It reduces the articulation barrier, meaning the difficulty of turning an intent into words, and often improves activation by steering people toward successful first use cases. Why it matters: It changes onboarding and first use by reducing blank page friction and nudging demand into tasks your product can do reliably. 07.01 The four AI design patterns for a surface that
Articulation Barrier
The articulation barrier is the gap between what a person wants and what they can clearly express to a system in words, clicks, or structured inputs. Generative products lower this barrier by accepting rough intent and iterating with the user, but they can also raise it if good results require expert prompting. Why it matters: It changes interface design: you may need examples, defaults, and follow up questions instead of a blank box. 07.03 The four surfaces
Regenerate
Regenerate is a control that asks the model to produce another answer to the same prompt. It exists because model outputs are nondeterministic, meaning the same input can produce different responses, so users can recover from a weak draft without rewriting everything, compare alternatives, or search for a better tone, structure, or result. Why it matters: It changes recovery UX. Offer it when alternative answers are useful, but pair it with version visibility so users do not lose the previous response. 07.03 The four surfaces
Long-Running Agent
An agent working on a task for hours or days, across many sessions and context windows. Why it matters: It forces decisions on memory, checkpoints and interruption, because its errors compound instead of ending with a reply. 07.04 Stream the work
Indirect Prompt Injection
A prompt injection attack hidden inside content the system reads, such as a webpage, email, or document, rather than typed directly by the user. If an agent treats retrieved text as instructions instead of untrusted data, that hidden message can override the intended task and trigger leaks, bad tool use, or unsafe actions. Why it matters: It changes how you separate instructions from data, and when you sandbox, filter, or require approval before acting on retrieved content. 07.05 The approval gate
Citation
A citation is a pointer to the source behind a claim, usually a linked passage, document, or record that a user can inspect. In AI products, citations are used to show grounding in retrieved material and make answers more auditable, but they only build trust when the source truly supports the statement. Why it matters: It changes trust features and UX. Citations tell you when users need source verification, and whether retrieved evidence is strong enough to support high-stakes answers. 07.06 Claim-level citations
Explainability
Explainability is the extent to which a person can understand why a system produced a particular output, recommendation, or action. In AI products it can come from showing evidence, rules, influential inputs, or plain language rationales, helping users judge when to trust the result even if the underlying model is complex. Why it matters: It changes how you design trust features and human review, especially for decisions that users must justify, contest, or verify. 07.06 Claim-level citations
Faithfulness
Faithfulness is whether an answer accurately reflects the information it was supposed to use, without inventing unsupported claims or twisting the source. It matters most in retrieval and summarization systems, where a response can sound fluent yet still be wrong, so teams often check citations, grounding, and source level consistency rather than style alone. Why it matters: It changes quality evaluation. A helpful sounding answer is still a failure if it is not supported by the provided source. 07.06 Claim-level citations
Grounding
Connecting a model's answer to specific source material that was provided, often by quoting, paraphrasing, or attaching citations. The goal is to reduce invention and make verification easier, especially in retrieval augmented systems where the model should answer from retrieved documents instead of relying on hazy prior knowledge. Why it matters: It changes UX and policy choices such as when to show sources, require evidence, or block unsupported answers. Without it, users may trust statements they cannot verify. 07.06 Claim-level citations
Refusal
A refusal is when the model declines to answer, comply, or take an action because the request is unsafe, disallowed, or beyond what it should do. Good refusals block harmful behavior without being vague or insulting, while bad ones either permit risky requests or reject valid user needs. Why it matters: It changes safety tuning and support burden. Refusals tell you whether the system is too permissive, too restrictive, or communicating boundaries badly. 07.07 The empty box
Safe Completion
Safe completion is a response pattern where the system refuses the harmful part of a request but still helps with the safe, legitimate part instead of giving a blank rejection. In practice, it might decline instructions for wrongdoing while offering general information, preventive advice, or a safer alternative that still moves the user forward. Why it matters: It changes refusal design. Good safe completion reduces user frustration without weakening safety policy. 07.07 The empty box
Annotation
Annotation is the process of labeling data with the information you want a system to learn from or be evaluated against, such as the correct answer, category, or error type. It turns messy real examples into structured evidence, but the labels are only useful if instructions are clear and different raters apply them consistently. Why it matters: It changes dataset quality for training and evals. Weak annotation creates false signals that make a model or feature look better or worse than it is. 08.01 Read one hundred real traces before you buy an
Trace-Level Spend Attribution
Trace-level spend attribution reads cost and latency per span, per model call, tool call, and handoff, to find where an agent's money and time actually went, so you cut the one expensive step instead of swapping the whole model. It is the diagnostic that turns a cost or latency regression into a targeted fix. Why it matters: Lets a PM diagnose a cost or latency regression to a specific span and choose a targeted fix, rather than guessing and degrading quality by reaching for a cheaper model. 09.05 Cost per successful task
AI Governance
The set of policies, roles, review steps, and controls a company uses to decide which AI systems can be built, bought, or deployed, and under what conditions. It covers issues like data access, testing, documentation, oversight, and incident response so decisions are repeatable, accountable, and not improvised team by team. Why it matters: It changes who can launch what, with which evidence, and what happens when something goes wrong. 10.04 The permission-aware retrieval layer
ISO 42001
ISO 42001 is an international standard for running an AI management system, which is the set of policies, roles, controls, and review processes a company uses to govern how it builds, buys, and operates AI. Organisations use it to show customers and auditors that AI risks are managed systematically rather than ad hoc. Why it matters: It changes enterprise readiness decisions: when you need formal AI governance, documented controls, and audit evidence to win regulated customers or reduce procurement friction. 10.06 Procurement
Watermarking
A method for hiding a subtle pattern in generated text, images, audio, or video so later checks can suggest that a specific AI system produced it. It is useful as a signal rather than proof, because editing, compression, copying, or rephrasing can weaken or remove the pattern and determined attackers may try to strip it. Why it matters: It changes whether you can later label, trace, or investigate generated media. It is not a substitute for provenance, moderation, or policy enforcement. 10.09 Who owns the output
Word Error Rate
Word error rate is the standard speech recognition accuracy metric, calculated by counting substituted, inserted, and deleted words compared with a correct reference transcript and dividing by the reference word count. Lower is better, but the same score can hide very different mistakes, so teams still inspect examples and error patterns. Why it matters: It changes model selection and acceptance criteria for speech features. It also tells you when a single average score is masking the mistakes users actually notice. 11.02 Voice
Safety Classifier
A smaller, faster model that labels or scores content for risk categories like self harm, hate, sexual content, or attempts to evade policy. Products place it around prompts, responses, and tool calls because it can make cheap real time safety decisions, even though it still needs tuning and measurement like any other classifier. Why it matters: It tells you what to block, review, or allow automatically. Its precision and recall determine whether your product feels unsafe or overcensored. 11.04 Ship a language
Toxicity
Language that is abusive, hateful, threatening, sexually explicit, or otherwise unsafe enough to harm users or violate policy in a given context. Teams track it in both prompts and model outputs, because even infrequent toxic behavior can damage trust, trigger complaints, and create serious legal or brand risk. Why it matters: It changes moderation thresholds, escalation rules, and whether a use case is safe to launch in a segment or geography. 11.04 Ship a language
Levels of Autonomy
Levels of autonomy describe how much an AI system is allowed to decide and act without asking a human at each step. A low level might only draft or recommend, while higher levels can execute tools or workflows, so teams use the scale to match oversight and permissions to the risk of mistakes. Why it matters: They determine approval gates, monitoring, and fallback design. More autonomy should mean tighter permissions and clearer human takeover. 12.02 What an agent may do without asking
Instruction Hierarchy
Instruction hierarchy is the order a model follows when different directions conflict, typically giving platform rules highest priority, then developer instructions, then user requests. It explains why a system may refuse or ignore part of a prompt, and it is central to building safe products that behave predictably across many situations. Why it matters: It tells you where to place constraints and explains failures when user requests override less important guidance. 12.03 Agent security
Jailbreak
A jailbreak is a prompt or prompt sequence designed to make a model ignore its safety rules and produce restricted content or actions. It exploits weaknesses in instruction following, so teams use red teaming, layered safeguards, and monitoring rather than assuming one system prompt will be enough. Why it matters: It changes your safety architecture and launch scope. It tells you to test adversarial behavior explicitly, not just normal user flows. 12.03 Agent security
Lethal Trifecta
The lethal trifecta is the high risk combination of access to sensitive data, access to tools or systems that can take action, and enough autonomy to pursue goals over multiple steps. When all three are present, a model mistake or compromise can escalate from a bad answer into real operational harm. Why it matters: It tells you when an agent needs much stricter controls. If data access, action access, and autonomy combine, treat it as a high risk system. 12.03 Agent security
Memory Poisoning
The act of planting false or malicious information in an agent's stored memory so it will behave incorrectly in later sessions. Because long term memory is reused over time, one bad entry can quietly change future answers, actions, or priorities long after the original interaction is gone. Why it matters: It tells you to treat memory as untrusted input, with review, expiry, and provenance checks. Otherwise an agent can repeat or act on lies across many sessions. 12.03 Agent security
Prompt Injection
Prompt injection is an attack where text the model reads contains hidden or visible instructions that try to override the system's intended rules and steer what it does next. It can arrive through user input, web pages, documents, or tool results, so any model that follows external text as instructions needs boundaries. Why it matters: It changes how much autonomy, tool access, and external content you let a model handle without checks. 12.03 Agent security
AI Red Teaming
A structured practice where you deliberately try to break your own AI system using adversarial prompts, edge cases, and realistic attack scenarios. The goal is not to show impressive demos but to uncover unsafe behavior, policy holes, or brittle defenses before launch, and to see whether your safeguards survive determined misuse. Why it matters: It changes launch readiness and risk prioritization. Use it to find the failure modes normal testing misses, especially around misuse, evasion, and harmful edge cases. 12.05 Red-team the obvious modes
System Prompt Leakage
This happens when a model exposes the hidden instructions that guide its behavior, including rules, examples, tool details, or internal business logic. The problem is not just embarrassment: once those instructions are visible, users and attackers can reverse engineer safeguards, craft prompts that bypass safety rules, or extract information the product was supposed to keep private. Why it matters: It changes how you design prompts, access controls, and red team tests. Treat prompts as exposable and protect the data or policy behind them separately. 12.05 Red-team the obvious modes
Bias Audit
This is an independent review that tests whether an automated decision system disadvantages groups protected by law, such as race, sex, age, or disability, when making decisions like lending, hiring, or triage. It compares outcomes across groups, inspects the data and rules behind them, and produces the evidence needed for legal, policy, and launch decisions. Why it matters: It determines whether a system can ship, what evidence you need, and which mitigations are mandatory. Failed audits force changes to data, thresholds, or human review. 12.06 Right-sized governance
Responsible Scaling Policy
A responsible scaling policy is a public commitment by an AI lab to add stronger safeguards when a model crosses predefined capability or risk thresholds. It links evidence from testing to concrete actions such as tighter deployment limits, better security, and more evaluations, so scaling decisions are not left to ad hoc judgment after a dangerous surprise. Why it matters: It changes ship criteria for frontier models. It gives PMs a basis for saying no to launch until specific safeguards and evidence are in place. 12.06 Right-sized governance
Elicitation
Elicitation is the practice of drawing out a model's best performance by giving it the right instructions, examples, tools, or task breakdown. It matters because apparent capability depends not only on the model itself, but also on whether your setup makes the relevant knowledge and reasoning usable in that situation. Why it matters: It changes whether poor results mean bad models or bad setup. Elicitation tells you when to improve prompting, tools, or task decomposition before writing off capability. 13.02 Work with researchers
Model Spec
A model spec is a written contract for how an AI system should behave, including which instructions win, when it should refuse, and what safety or quality standards it must follow. Teams use it to align training, prompting, and evaluation, and to separate true model failures from disagreements about the intended behavior. Why it matters: It changes how you settle debates about refusals, tone, and edge cases, because expectations are explicit before you eval or fine tune. 13.02 Work with researchers
Reward Model
A reward model is a separate model trained to score how good a candidate output is based on human preferences or other chosen signals. During alignment training, it acts like a learned judge that guides another model toward responses that rank higher on helpfulness, safety, format, or other desired qualities. Why it matters: Helps you understand what a model is being optimized for. It explains recurring biases toward certain answer styles, refusals, or formatting patterns. 13.04 The data flywheel and self-improving agents

AI engineering (100)

Eval
A repeatable test for model or product behavior using predefined cases and scoring rules. Instead of relying on demos or intuition, teams run the same checks consistently over time to compare prompts, models, and system changes and to catch regressions before users do in production. Why it matters: Changes how decisions get made. It gives you evidence for shipping, rollback, model swaps, and whether improvements are real or just anecdotal. 01.01 The AI PM job now
Golden Dataset
A small, trusted set of examples with hand reviewed answers or labels that the team treats as authoritative. It is usually smaller than the full eval dataset and used often for smoke tests, because every case is well understood and obvious regressions show up quickly. Why it matters: Useful for fast checks before release. It catches embarrassing breakages early and gives teams a shared source of truth for important behaviors. 01.01 The AI PM job now
Input Tokens
These are the chunks a model reads when you send a request, created by a tokenizer that splits text, code, or images into machine-usable pieces. More input tokens mean more context for the model to use, but they also raise cost, can slow responses, and eventually hit the maximum context window. Why it matters: It changes prompt design and model choice. When requests are too expensive, slow, or hit context limits, input tokens tell you whether to shorten context, retrieve less, or switch models. 01.02 Make the API call yourself
Max Output Tokens
This setting caps how much text a model is allowed to generate in a single response, measured in tokens rather than words. It is a guardrail on cost, latency, and runaway answers, but if set too low it can cut off reasoning, truncate formats, or make the model seem less capable than it really is. Why it matters: It changes cost control and completion quality, including whether long answers fail because the model is weak or because you cut it off. 01.02 Make the API call yourself
Output Tokens
These are the chunks a model generates in its reply, produced one piece at a time as text, code, or other content is formed. Output tokens drive answer length, variable response time, and cost, which is why products often cap them or stream them to users as they arrive. Why it matters: It changes response length limits, streaming behavior, and pricing. If answers are costly or slow, output tokens tell you whether to cap generation or redesign the task. 01.02 Make the API call yourself
Streaming
This is a way of delivering a model's response piece by piece as tokens are generated instead of waiting for the full answer to finish. It does not always reduce total runtime, but it improves perceived speed and supports interfaces like live chat, typing indicators, and interruptible assistants. Why it matters: It changes response UX and latency perception, especially when faster first feedback matters more than a slightly shorter total wait. 01.02 Make the API call yourself
Temperature
This setting controls how adventurous a model is when choosing its next token, which is a chunk of text the model predicts step by step. Lower values make outputs more repeatable and conservative, while higher values increase variety and surprise, which matters in creative drafting more than in tasks that need exact, stable answers. Why it matters: It changes the tradeoff between consistency and variety, especially for evaluation, creative generation, and any workflow that depends on repeatable outputs. 01.02 Make the API call yourself
Time to First Token
The delay between a user request arriving and the first output token appearing on screen. It includes queueing, prompt processing, and startup work before generation begins, so users feel it as the initial pause even when the rest of the answer streams quickly afterward to them. Why it matters: Changes perceived speed and abandonment risk. Useful when deciding whether streaming, caching, or smaller models will make the product feel faster. 01.02 Make the API call yourself
Top P
This setting limits the model's next token choice to the smallest set of words whose combined probability reaches a chosen threshold, then samples from that set. It is another way to control randomness, often used instead of or alongside temperature, and it can cut bizarre long tail choices while keeping some variety. Why it matters: It changes output diversity and stability, especially when you want creative variation without allowing extremely unlikely word choices. 01.02 Make the API call yourself
Inference
Inference is the moment a trained model is run on new input to produce a prediction or generated response. In a product, every user request triggers inference, so this is where latency, serving cost, throughput limits, and model behavior become operational concerns rather than research results. Why it matters: It changes serving architecture and economics. Understanding inference tells you where each user request creates latency, capacity load, and cost. 01.03 One token at a time
KV Cache
A stored memory of attention computations from earlier tokens that lets a transformer generate the next token without recomputing the whole prompt. Reusing this state makes long conversations much cheaper and faster, but the cache consumes memory and can limit how many requests fit on a machine. Why it matters: Governs latency, memory use, and multi turn chat economics. It matters when choosing context length, concurrency targets, and whether prompt reuse actually saves money. 01.04 Context windows and attention
Prefill
Prefill is the stage of inference where the model reads the input prompt and builds internal state before producing any output. Longer prompts make prefill slower and more expensive, which is why large contexts, retrieved documents, and repeated instructions often hurt time to first token even before generation begins. Why it matters: It changes how much context you include and when to summarize or cache it. Excessive prefill makes products feel sluggish before any answer appears. 01.04 Context windows and attention
Prompt Caching
Prompt caching reuses the model's processing of a repeated prompt prefix, such as long instructions or shared background, across multiple requests. When supported by a provider, it reduces latency and input cost because the unchanged portion does not need to be recomputed from scratch every time. Why it matters: Improves unit economics for repeated workflows. It affects prompt structure, session design, and whether large static instructions are affordable. 01.04 Context windows and attention
Reasoning Effort
Reasoning effort is a control some models expose that tells them how much internal computation to spend before answering. Higher settings usually improve performance on complex problems by allowing more hidden reasoning, but they also increase latency and cost, so the right level depends on the value of each task. Why it matters: Lets you match model effort to task value. It changes product defaults for speed, quality, and margin on easy versus hard requests. 01.05 Pretraining vs post-training
Reasoning Tokens
Reasoning tokens are internal tokens some models use to work through a problem before showing the final answer to the user. Even when that hidden chain of thought is not exposed, it can still consume time, money, and context window capacity, especially on harder tasks or reasoning-focused models. Why it matters: Affects cost and latency forecasts for complex tasks. It changes whether deeper reasoning is worth the extra spend and slower responses. 01.05 Pretraining vs post-training
Class Imbalance
Class imbalance means one outcome is much rarer than another, such as harmful messages being a small fraction of all traffic. In that setting, accuracy can look strong even when the system misses many of the rare cases you actually care about. This is common in production. Why it matters: Changes which metrics matter and how you sample data. Ignoring it can make a weak system look production ready. 01.06 The AI-or-not decision
Confusion Matrix
A confusion matrix is the table that counts true positives, false positives, true negatives, and false negatives for a classifier. Most common metrics, including precision, recall, accuracy, and false positive rate, are derived from these counts rather than from a single top-line score. It makes tradeoffs visible. Why it matters: Prevents metric debates from getting abstract. It shows exactly which kinds of mistakes a change creates more or less often. 01.06 The AI-or-not decision
F1 Score
F1 score is a single metric that balances precision, which is how many flagged items were actually correct, and recall, which is how many of the true items you successfully found. It is useful when both false alarms and misses matter, especially in classification tasks with uneven classes. Why it matters: It changes model selection when accuracy hides the real tradeoff between catching cases and avoiding incorrect ones. 01.06 The AI-or-not decision
Model Drift
Model drift is a decline in performance over time because the real inputs, user behavior, or environment have changed from the conditions the system was trained or tested on. The model may be unchanged, but the world around it has shifted materially enough since launch. Why it matters: Tells you when to retrain, adjust prompts, refresh data, or revisit thresholds. It explains why a once-good system can degrade in production. 01.06 The AI-or-not decision
Precision
Precision measures, among all cases the system predicted as positive, how many were actually positive. It matters when false alarms are costly, such as flagging harmless content or sending users to an unnecessary human review path. A high value means the system is usually right when it raises the flag. Why it matters: Guides threshold setting when over-triggering is expensive. It is the metric behind arguments about false positives. 01.06 The AI-or-not decision
Recall
Recall measures, among all cases that truly belong in the positive class, how many the system successfully found. It matters when misses are costly, such as failing to catch policy violations, fraud, or users who need escalation. A high value means few true cases slip through unnoticed. Why it matters: Guides threshold setting when missing real cases is expensive. It is the metric behind arguments about false negatives. 01.06 The AI-or-not decision
Ground Truth
The answer or label treated as correct for a particular test case, whether it comes from verified data or expert judgment. Automated evaluation compares the model's output to this reference directly, or uses it as the anchor for measuring accuracy, recall, overlap, or other task specific scores. Why it matters: Changes how you score quality and what you can automate. If the ground truth is weak or disputed, your eval numbers will mislead you. 01.07 Read a benchmark honestly
Harness
The code around the model that loops, retries, calls tools, and decides when the model is finished with a task. Why it matters: It is where reliability is usually won or lost, so blaming the model for loops and stalls sends your team fixing the wrong thing. 01.07 Read a benchmark honestly
Held-Out Test Set
A subset of examples kept out of prompt tuning, model selection, and everyday iteration until you need a more honest final read. Because the team has not optimized against these cases, performance on them is less inflated and better reflects how the system generalizes. Why it matters: Protects against fooling yourself. It matters when making launch calls, vendor comparisons, or claims that a change truly improved performance. 01.07 Read a benchmark honestly
Failure Taxonomy
A named set of distinct failure categories that describes the main ways a system breaks in practice. Once the team agrees on these categories, it can tag incidents consistently, measure which problems are most common, and track whether fixes reduce the specific failures that matter. Why it matters: Changes prioritization. It lets you invest in the failure modes hurting users most instead of chasing a single blended quality score. 01.08 Attribute every failure to a layer
LLM Trace
An LLM trace is the full record of a single request, including the user input, prompts, retrieved context, tool calls, intermediate steps, and final output. It lets teams inspect how a result was produced instead of judging only the visible answer. This is crucial for debugging. Why it matters: Makes root-cause analysis possible. Without traces, you know an answer was bad but not whether retrieval, prompting, tools, or the model caused it. 01.08 Attribute every failure to a layer
Tool Call Accuracy
Tool call accuracy measures whether an agent chose the correct tool and passed the correct arguments or parameters for the task. It focuses on action quality inside the workflow, which means an answer can look reasonable while the underlying tool use was still wrong. Why it matters: Shows whether agent failures come from reasoning or from tool use. It changes how you design tool schemas, instructions, and safeguards. 01.08 Attribute every failure to a layer
Error Analysis
The practice of reading failed cases individually to understand what actually went wrong, rather than stopping at an aggregate score. By inspecting examples, traces, and context, teams find recurring failure patterns that suggest concrete fixes to prompts, retrieval, tools, policies, or product scope. Why it matters: Turns a bad score into an action plan. It tells you whether to fix data, prompts, UX, model choice, or the promise you are making to users. 02.02 Read the logs
Labeled Data
These are examples that have been tagged with the right answer or category, such as emails marked spam or support chats marked resolved correctly. They are used to train, fine tune, and evaluate models, and their usefulness depends on label quality, coverage of real cases, and consistent judgment from the people doing the tagging. Why it matters: It changes whether you can train or evaluate reliably, and whether low performance comes from the model or from noisy labels. 02.02 Read the logs
Eval Dataset
The collection of test cases an eval runs on, usually with inputs, expected qualities, and sometimes reference answers. Because results are only meaningful if the cases stay stable and representative, good teams version the dataset and update it deliberately rather than casually adding examples. Why it matters: Determines what your score actually means. A weak dataset hides failures, while a representative one tells you whether a change improves real user tasks. 02.04 From raw data to a golden sample
Agent Skills
These are reusable packages of task-specific instructions, example scripts, and reference files that an agent can load only when needed to perform a job reliably. Instead of cramming every rule into one giant prompt, you give the agent the skill for invoicing, triage, or research when that task appears, which improves accuracy and keeps the active context, the information the model sees, smaller. Why it matters: It changes how you package expertise for recurring jobs and when you split one general agent into specialized capabilities. 03.01 Build and iterate in Claude Code
Tool Call
A tool call is the model's structured request for an external function to run, usually including a tool name and arguments. It lets the system fetch fresh data or take actions beyond text generation, but it also creates new failure modes around permissions, bad parameters, retries, and unintended side effects. Why it matters: It changes permissions, interface design, and test coverage. Tool calls tell you where text generation becomes real-world action and therefore needs stricter controls. 03.02 Read the code you did not write
Tool Definition
The structured specification that tells a model a tool's name, what it does, what inputs it accepts, and any rules for using it. Good tool definitions make tool calling more accurate because the model can better match user intent to the right action and format arguments correctly. Why it matters: Changes tool-call accuracy, misuse rates, and how much prompt debugging you need. 03.02 Read the code you did not write
Tool Result
A tool result is the data returned after a model asks an external system to do something, such as run a search or look up an account. The model then uses that returned information in later reasoning or response generation, so format, accuracy, freshness, and ambiguity here strongly shape the final answer. Why it matters: It changes where you fix failures. If the result is stale, ambiguous, or badly structured, prompt changes will not reliably solve the problem. 03.02 Read the code you did not write
MCP Client
This is the software component inside an application that opens a connection to an MCP server and uses the tools, resources, or prompts the server exposes. MCP stands for Model Context Protocol, a standard way for models and apps to work with external capabilities without building a custom integration for each tool. Why it matters: It changes integration scope by defining how your product discovers and calls external capabilities in a standard way. 03.03 MCP first contact
MCP Host
This is the application the user interacts with, such as a chat app, editor, or agent console, that runs the model experience and connects it to MCP servers. It manages which external tools and data become available, and usually handles permissions, authentication, and how those capabilities appear in the interface. Why it matters: It changes where trust, permissions, and UX responsibility sit when external tools are added to your product. 03.03 MCP first contact
MCP Server
A program that exposes tools, data, and reusable prompt templates to an AI application using the Model Context Protocol, or MCP, which is a shared way to describe those capabilities. It sits between your systems and the model-driven app so clients can discover what is available and call it consistently. Why it matters: Determines how external systems are packaged for agent access and where authentication, permissions, and rate limits live. 03.03 MCP first contact
Model Context Protocol
An open standard for connecting AI applications to outside tools and data sources through one consistent interface. Instead of building a custom integration for every system, an application can speak this protocol and discover available actions, resources, and prompts from any compatible service. Why it matters: Affects integration speed, vendor portability, and whether tool access can be standardized across products. 03.03 MCP first contact
Remote MCP Server
This is a program that implements MCP and is reached over a network rather than running locally on the same machine or inside the same app. It lets a model use shared tools or company systems from afar, but it introduces authentication, latency, reliability, and security concerns that standardization alone does not remove. Why it matters: It changes deployment and risk decisions, especially around access control, network reliability, and whether sensitive actions should leave the local environment. 03.03 MCP first contact
Binary Eval
A binary eval judges each model output as pass or fail instead of giving it a score on a scale. This works well when the product has a clear minimum bar, such as valid JSON only, correct citation, or safe refusal, and it often makes reviewers agree more. Why it matters: It changes how you define quality gates for launch, regressions, and vendor comparisons when only meeting the bar matters. 03.05 One output is an example; ten inputs by five r
Scoring Rubric
The written criteria that define what a good, bad, or incomplete output looks like for a task. A clear rubric turns fuzzy quality judgments into something repeatable across humans or model judges, and usually specifies both the dimensions to inspect and the thresholds for scoring. Why it matters: Improves consistency and debate quality. It forces the team to state what matters, which makes eval results easier to trust and act on. 03.05 One output is an example; ten inputs by five r
Augmented LLM
An augmented LLM is a language model wrapped with extra capabilities such as retrieval, tools, memory, or business rules so it can do more than generate text from its built in knowledge. Most production AI products use this pattern because raw models lack current data, reliable actions, and product specific control. Why it matters: It changes scope and evaluation by shifting the question from model quality alone to system quality across tools, context, and orchestration. 04.03 The problem-first test
Human Annotation
A person reviews an output, trace, or example and attaches a label, score, or written judgment using a rubric, which is a shared set of grading rules. Teams use it to create training data, measure quality, and capture cases automated checks cannot judge well. Why it matters: Determines what quality data you can collect, how expensive evaluation is, and whether your metrics reflect real user expectations. 04.04 Qualify the opportunity
Zero Data Retention
Zero data retention is a vendor setting or contract term that says prompts, outputs, and related request data are not kept after the service responds. Teams ask for it when sensitive information is involved, but the exact promise must be checked because logs, abuse monitoring, and short lived buffers may still exist. Why it matters: It changes whether you can send sensitive customer or company data to a model vendor, and what legal or security objections will block launch. 04.06 Build, buy, or open weights
Guardrails
Automated checks placed around an AI system to catch risky inputs or outputs before they reach a user or trigger an action. They can block, rewrite, route to a safer path, or require human review, so the product has predictable controls even when the model itself is probabilistic, meaning it can produce different answers to similar requests. Why it matters: It decides which failures you prevent in code instead of hoping the model behaves, especially for safety, compliance, and tool misuse. 05.01 The AI PRD
Model Snapshot
A model snapshot is a fixed version of a model that will not silently change as the provider updates newer releases. Teams pin to snapshots when they need stable behavior for testing, safety review, regulated workflows, or cost control, rather than following a moving alias that may improve or regress unexpectedly. Why it matters: Supports release management and regression control. It changes how you test, roll out, and debug behavior when providers ship updates. 05.01 The AI PRD
Orchestrator Workers
A system design pattern where one coordinator breaks a goal into smaller tasks, assigns them to specialized workers, and combines the results into one answer or action. It shows up in research, coding, and operations flows where parallel work, retries, or different skills make the system more reliable or faster than one model doing everything alone. Why it matters: It changes system architecture decisions: when to split work among specialists versus keep one flow. That affects latency, reliability, and cost. 06.01 Workflow or agent
Tool Use
A model reaches outside its own text generation to call software or data sources such as search, calendars, databases, or code runners. This matters whenever the job requires fresh facts, taking actions, or exact computation, because the model decides when to use a tool and then continues based on the tool's result. Why it matters: It tells you when the model needs outside data or actions, and what permissions and approvals you must design around that. 06.01 Workflow or agent
Memory
Memory is information saved from past interactions that the system can use later, such as preferences, goals, facts, or prior tool outputs. Unlike ordinary prompt context, memory persists across turns or sessions, which can make experiences feel continuous but also introduces privacy, staleness, and poisoning risks if it is stored badly. Why it matters: It changes continuity, privacy, and recovery design. Memory tells you what to persist, when to forget, and how much bad stored state can damage future sessions. 06.02 The anatomy of an agent
Function Calling
A way for a model to return structured fields that match a predefined function or API shape instead of free form text. Your application can then safely execute the requested action, which makes tool connections more reliable than trying to parse a paragraph for arguments. Why it matters: It changes the contract between model and application, and determines whether tool execution is safe enough to automate. 06.04 Write the tool contract
Parallel Tool Use
Parallel tool use is when an AI system calls multiple tools at the same time instead of waiting for one result before starting the next. This can cut end to end latency, meaning total wait time, when tasks are independent, but it also increases coordination complexity, rate limit pressure, and the chance of conflicting results. Why it matters: It changes agent architecture. Use it when tasks are independent and time sensitive, but avoid it when order matters or tool costs can spike. 06.04 Write the tool contract
Token Burn
This is wasteful spending of tokens, the text units a model reads or writes, without improving the result enough to justify the cost. It shows up in bloated prompts, repeated context, unnecessary retries, and long agent loops, and it hurts both margins and latency. Why it matters: It changes prompt design, model choice, and agent limits by showing where cost and delay rise without creating more user value. 06.05 Inside the harness
Document Chunking
Before documents can be retrieved for a model, they are usually split into smaller passages so search can return the relevant section instead of a whole file. The split size matters because tiny passages lose context, while large ones pull in unrelated text, waste the limited text space a model can consider in one call, and make source backed answers less precise. Why it matters: It changes retrieval quality, latency, and cost. Bad splits are a common hidden cause of hallucination even when the source document actually contains the answer. 06.06 Context as a budget
Embedding
An embedding is a numeric representation of text, images, or other data where items with similar meaning end up near each other in a vector space, which is a mathematical layout of points. Products use embeddings for semantic search, recommendation, clustering, and retrieval because systems can compare meaning without requiring exact keyword matches. Why it matters: It changes how you build search and retrieval, especially whether similarity by meaning matters more than exact terms. 06.06 Context as a budget
Memory Tool
A memory tool is a tool an AI agent uses to save and retrieve information outside the immediate context window, the limited amount of text it can attend to at once. It lets the system remember preferences, prior facts, or intermediate work across turns, but poor memory quality can store stale, sensitive, or misleading information. Why it matters: It changes personalization and continuity. You need clear rules for what gets stored, when it expires, and how users can inspect or correct it. 06.06 Context as a budget
Semantic Search
Semantic search retrieves information by meaning rather than exact word overlap. It usually turns queries and documents into embeddings, then finds nearby matches and may rerank them, so a search for "cancel my plan" can find content titled "end subscription" even when the same keywords are missing. Why it matters: It changes search quality goals. It helps when users describe intent in many ways, but it needs evaluation for relevance and false matches. 06.06 Context as a budget
Vector Database
A vector database stores embeddings, which are numerical representations of meaning, so a system can quickly find items that are semantically similar to a query. It is commonly used in retrieval systems for AI products, where documents, tickets, or knowledge base articles are indexed and later searched by similarity rather than exact keywords. Why it matters: It changes retrieval design. Choose it when meaning based matching matters more than exact text matches or traditional filters alone. 06.06 Context as a budget
Agentic Retrieval
Agentic retrieval is a retrieval approach where the model actively decides what to search, which documents to open, when to refine the query, and when it has enough evidence to answer. Instead of one fixed lookup step, it runs a small research loop, which can improve hard questions but adds latency, cost, and more ways to fail. Why it matters: It tells you whether a hard question needs exploration instead of a single search, and whether the quality gain is worth extra latency and spend. 06.07 When multi-agent is worth it
Agents as Tools
Agents as tools is a design pattern where a main system calls another agent the way it would call a calculator, search service, or code runner. The called agent handles a narrow subtask and returns a result, letting the main workflow reuse specialized reasoning without giving every component full autonomy. Why it matters: It changes system architecture by letting you isolate risky or expert work in bounded components instead of making one giant agent do everything. 06.07 When multi-agent is worth it
Lead Agent
A lead agent is the coordinating agent in a multi agent system that decides what sub task to do next, which specialist to call, and how to combine the results. It plays the planner and traffic controller role, which can improve complex workflows but also adds orchestration overhead and another place errors can compound. Why it matters: It changes how you decompose work. Use one when tasks need planning and delegation, not when a single prompt is enough. 06.07 When multi-agent is worth it
Task Time Horizon
Task time horizon is the length or complexity of task an agentic system can complete reliably end to end at a target reliability. It is the frontier success metric for long-running agents, replacing per-answer accuracy, because reliability compounds multiplicatively across steps and a system that is 95 percent reliable per step fails most 40-step tasks. Why it matters: Lets a PM state the task length a long-running feature must finish reliably, which then sets the run contract, the returning-user briefing, and the cost per successful task. 06.07 When multi-agent is worth it
Agent2Agent Protocol
An Agent2Agent Protocol is a standard way for one software agent to ask another agent for work, pass context, and receive results without custom one off integrations each time. It defines message formats, capabilities, and handoffs so specialized agents from different vendors or teams can cooperate inside a larger workflow. Why it matters: It changes build versus buy decisions for multi agent features by reducing integration cost and lock in. 06.08 Agent user surfaces
Constrained Decoding
Constrained decoding is a generation method that limits what the model can output at each step so the final answer matches a required structure, such as valid JSON or a fixed set of labels. Instead of hoping a prompt is followed, the system blocks invalid next tokens during generation, which improves reliability for downstream code and automations. Why it matters: It changes whether structured outputs are safe enough to parse automatically or still need cleanup and retries. 06.09 Structured outputs are a decoding constraint
JSON Mode
JSON mode tells a model to return valid JSON syntax instead of free form prose. It is useful when another system needs to parse the response automatically, but it mainly guarantees format, not that the right fields, values, or business logic are present, so many teams pair it with stronger schemas and validation. Why it matters: It changes output handling. Use it for machine consumption, but do not mistake valid brackets for correct answers. 06.09 Structured outputs are a decoding constraint
Structured Outputs
Structured outputs make the model return data that matches a predefined schema, such as fixed JSON fields, data types, or allowed values, rather than free text. That makes responses far easier for software to parse reliably, which is why this pattern is common in extraction, tool use, and workflow automation. Why it matters: It changes whether downstream code can trust the shape of a response enough to automate the next step. 06.09 Structured outputs are a decoding constraint
Trace Data Model
The trace data model is the structured tree a production run must emit: one nested span per model call, tool call, and handoff, each carrying inputs, outputs, model and prompt version, token count, cost, and latency, plus a stable trace id and parent-span id. Teams design it before the build because evaluability cannot be retrofitted once traffic has run and the data is gone. Why it matters: Lets a PM write the instrumentation spec before the build so error analysis, evals, and cost per successful task have the fields they need, and a failed run can be reproduced later. 08.01 Read one hundred real traces before you buy an
Annotation Queue
An annotation queue is the organized backlog of examples waiting for human labeling, review, or re review in an AI workflow. Teams route items into queues based on priority, uncertainty, policy area, or customer impact so raters can produce the ground truth, meaning the reference answer used for training or evaluation. Why it matters: It changes which data gets labeled first, which directly affects model improvement speed, evaluation coverage, and operations cost. 08.02 Name the failure from one taxonomy
Trajectory Evaluation
Trajectory evaluation scores the sequence of steps an agent took, not just the final answer it produced. Reviewers or code checks inspect actions like retrieval, planning, and tool use, which is important because a lucky answer can hide a broken process. Why it matters: Helps decide whether an agent is actually reliable or only sometimes ends up correct. It changes where you debug and what you reward. 08.02 Name the failure from one taxonomy
Offline Evaluation
Offline evaluation measures a system on a fixed dataset before or alongside release, without exposing changes to live users. Because the same cases can be rerun quickly and cheaply, teams use it for rapid iteration, safer regression checks, and comparing model or prompt variants. Why it matters: Decides whether a change is worth taking to production. It catches obvious quality drops before users pay the price. 08.03 First golden set
Synthetic Data
Synthetic data is artificially generated data that imitates the structure or patterns of real data instead of being collected directly from actual users or events. Teams use it to test systems, train models, or cover rare cases when real examples are scarce, expensive, or sensitive, but it can mislead if the generated cases are cleaner or simpler than production reality. Why it matters: It changes how you bootstrap evaluation or model training when real data is missing or restricted. It also raises the risk of overestimating performance on neat, unrealistic examples. 08.03 First golden set
Code-Based Eval
An evaluation that checks outputs with deterministic rules, such as exact match, schema validation, assertions, or regular expressions, instead of relying on human reviewers or another model. It is fast, cheap, and repeatable, but only works when correctness can be specified clearly enough in code, so it is strongest for structured tasks and known edge cases. Why it matters: It changes how you build eval coverage by letting you automate frequent regression checks where pass or fail is unambiguous. 08.04 Pay for the cheapest evaluator that can see th
LLM as a Judge
An evaluation approach where a second language model scores or ranks outputs using instructions and a rubric. It lets teams grade large volumes of open ended answers more cheaply than human review, though the judge can have its own biases and should be calibrated. Why it matters: Changes how you scale evaluation. It is useful when human review is too slow, but it also requires bias checks and spot audits. 08.04 Pay for the cheapest evaluator that can see th
Reference-Free Evaluation
This is a way to judge output quality when there is no single known correct answer to compare against, such as summaries, advice, creative drafts, or multi step agent behavior. Instead of exact answers, you score traits like usefulness, safety, faithfulness, or task completion using humans, rubrics, or judge models. Why it matters: It tells you how to evaluate work that has no single right answer. Choose rubrics, pairwise judgments, or human review instead of pretending ground truth exists. 08.04 Pay for the cheapest evaluator that can see th
Pairwise Comparison
A judging method that shows two candidate outputs for the same input and asks which one is better. People and model judges often find this easier and more reliable than assigning absolute scores, especially when quality is subjective or small differences are hard to define in advance. Why it matters: Helps when ranking prompts or models. It is often better for close calls than single answer scoring, but it does not tell you why one won. 08.05 Write the criterion
Position Bias
A judge's tendency to prefer whichever answer it sees first, regardless of quality. Why it matters: It forces you to shuffle candidate order in any comparison, or your reported winner is an artefact of ordering. 08.05 Write the criterion
Self-Preference Bias
This is a failure in model based judging where a judge model scores its own outputs more favorably than equally good answers produced by another model. It matters when you use one model to grade another, because the benchmark can turn into brand loyalty rather than a fair comparison. Why it matters: It changes which judge model you trust for comparisons. If present, cross model benchmarks can favor the grader's family rather than the better output. 08.05 Write the criterion
Verbosity Bias
This is a judging bias where longer answers receive higher scores simply because they are longer, not because they are more accurate, useful, or faithful to the prompt. It shows up in human and model based evaluation, especially when the rubric is vague, and can quietly reward rambling over clarity. Why it matters: It changes judge design and rubric wording. If unchecked, your eval will reward long answers instead of good ones and push the product toward unnecessary text. 08.05 Write the criterion
Inter-Annotator Agreement
Inter-annotator agreement measures how consistently different human reviewers label the same item when working independently from the same rubric, meaning the same written grading criteria. High agreement suggests the task is well defined, while low agreement usually means the rubric, labels, or task itself is ambiguous. Why it matters: Tells you whether to trust human labels. Low agreement means your eval may be measuring reviewer confusion instead of model quality. 08.06 Validate the judge
True Positive Rate
True positive rate is the share of real positive cases that a system correctly flags as positive. It is the same metric as recall in binary classification, so a low true positive rate means many genuine cases are being missed even if the system looks accurate overall. Why it matters: It changes detector and guardrail tuning. This metric tells you how many real positives you are catching versus letting slip through. 08.06 Validate the judge
Eval-Driven Development
This is the practice of turning a bug report or desired behavior into an evaluation first, then only changing the prompt, model, or tool setup after you can measure the result. The new test joins your regular eval suite, so every future change is checked automatically in continuous integration, the test run that happens on each update, and fixes must keep passing known cases. Why it matters: It changes release decisions: you stop shipping prompt or model tweaks on vibes and require proof that fixes work without breaking old behavior. 08.07 Offline and online evals
LLM Observability
The practice of instrumenting a live AI product so you can inspect prompts, outputs, tool calls, costs, latency, and failure patterns over time. It extends normal monitoring to the model's actual behavior, usually with traces, meaning linked records of each step, so teams can debug regressions that standard app logs miss. Why it matters: It changes incident response and iteration speed by making model failures visible instead of anecdotal. 08.07 Offline and online evals
Online Evaluation
Online evaluation measures system performance on live production traffic, either by scoring sampled interactions or by comparing variants with real users in the product. Because it observes changing inputs, edge cases, and downstream outcomes like satisfaction or conversion, it is the best read on how a model behaves after launch rather than on a fixed test set. Why it matters: It changes launch and rollback decisions. It catches real world failures and behavior shifts that offline benchmarks can miss. 08.07 Offline and online evals
Sandbox Replay
Sandbox replay stands up a recorded or simulated stand-in for each state-changing connector so an agent can run end to end in CI, asserting the action it would take and resetting between runs, so no real write ever leaves the test boundary. It is how an agent that writes to a system of record is tested without mutating live data. Why it matters: Lets a PM specify how a write-capable agent is exercised in CI, so the eval gate covers the action path and not just the read path, before the agent touches a customer system. 08.07 Offline and online evals
State-Changing Action
A state-changing action is a tool call that writes to a system of record, such as opening a ServiceNow incident, closing a Zendesk ticket, or issuing a refund, whose side effects cannot be rolled back, as opposed to a read-only action. Classifying every tool as read-only or state-changing is what decides which calls need approval, which need a sandbox in CI, and which set the agent's blast radius. Why it matters: Lets a PM declare, before the build, what an agent may touch without asking and what a CI sandbox must simulate, which sets the approval gates and the blast radius. 08.07 Offline and online evals
RL Environment
The setup in reinforcement learning where a model or agent acts, observes what happened, and receives rewards, which are signals about how well it did. It includes the task rules, available tools, and stopping conditions, so changing the environment changes the behavior the system learns. Why it matters: It changes training design: if the rules, tools, or reward are wrong, the system will optimize the wrong behavior. 08.08 Evaluate an agent
Model Routing
The decision logic that chooses which model handles a request instead of sending every request to one default model. Products use it to match easy tasks to cheaper or faster models and harder tasks to stronger ones, improving cost, latency, and quality when the router can reliably tell what level of capability the task needs. Why it matters: It changes your cost quality tradeoff by deciding when premium capability is worth paying for. 09.04 Diagnose a drop when the treatment is nondeter
Model Cascade
This serving pattern sends a request to a smaller, cheaper model first, then passes only uncertain or failed cases to a stronger model. The handoff is controlled by a threshold, such as a confidence score, meaning the system's estimate of likely correctness, or a verification check, so you preserve quality on hard tasks while reducing average cost and latency on easy ones. Why it matters: It changes your serving policy: you can hit a quality target without paying frontier-model prices on every request. 09.06 Cost levers and the operating point
Ingestion Pipeline
The repeatable workflow that takes source content, cleans and parses it, splits it into chunks, creates vector embeddings, which are numeric representations of meaning, and stores the results for retrieval. It is the quiet foundation of retrieval systems, because bad ingestion creates stale, missing, or poorly searchable knowledge no matter how good generation looks. Why it matters: It changes where you debug bad answers in retrieval augmented products. If coverage, freshness, or parsing is wrong, prompt tweaks usually will not save you. 10.02 Support handoff flow
GPU Utilization
The percentage of time a graphics processing unit, or GPU, is doing useful computation instead of waiting idle while it still costs money. For teams serving their own models, utilization depends on traffic shape, batching, and memory limits, and it strongly affects cost per request and how much capacity a fleet can deliver. Why it matters: It changes hosting decisions such as batching, autoscaling, and whether to self host at all. Low utilization can erase any savings from cheaper model weights. 10.08 Hosted
Quantization
Quantization compresses a model by storing its weights, the numbers learned during training, using fewer bits than full precision formats. This usually reduces memory use and can speed up inference, especially on smaller or cheaper hardware, but aggressive compression can hurt output quality or make some tasks behave less reliably. Why it matters: It tells you whether a model can fit your latency and cost target without unacceptable quality loss. 10.08 Hosted
Small Language Model
This is a language model compact enough to run on limited hardware, often inside a customer's own environment rather than a shared cloud service. It usually gives up some broad reasoning and world knowledge, but in return you get lower latency, lower cost, easier private deployment, and more control over where data stays. Why it matters: It changes model selection when privacy, on-premise deployment, responsiveness, or unit economics matter more than maximum capability. 10.08 Hosted
Image Tokens
Image tokens are the units a model that understands images and text uses to represent visual input inside its context window, the limited working memory for a request. Higher resolution images, more pages, or more pictures usually consume more tokens, which raises cost and can leave less room for text instructions or output. Why it matters: They change the true cost of visual features and whether large images crowd out needed text context. 11.01 Documents are not text
Optical Character Recognition
Optical character recognition is a method for turning text inside images, PDFs, and scanned documents into machine readable characters instead of leaving it trapped as pixels. Systems first find where the text is, then identify the letters, making the content searchable, copyable, and usable by downstream workflows or AI models. Why it matters: It changes whether document content can be indexed, retrieved, or automated. Poor OCR can silently break search, extraction, and any model pipeline built on those documents. 11.01 Documents are not text
Audio Tokens
Audio tokens are the units a model uses to represent sound for pricing, context limits, or internal processing, similar to how text models use text tokens. In speech products they matter because a minute of conversation turns into many such units, which affects latency, memory, and the cost of transcription, understanding, or speech generation. Why it matters: It changes pricing and architecture for voice features because long calls can consume far more compute than short text exchanges. 11.02 Voice
Inter-Token Latency
The average time between one generated token and the next during streaming output. It shapes how smooth and fast the answer appears after it has started, and often depends on model size, hardware, decoding settings, and whether the system is sharing capacity across many requests. Why it matters: Changes reading experience for long answers. Useful when tuning model choice or infrastructure for smooth streaming rather than faster starts. 11.02 Voice
Speech-to-Speech Model
A speech-to-speech model takes spoken audio as input and returns spoken audio as output, rather than converting speech to text and back in separate steps. This can make conversations feel faster and more natural, but it also makes moderation, debugging, and transcript-based evaluation harder than in text-first voice systems. Why it matters: It changes the voice stack choice. You trade lower latency and natural turn-taking against weaker observability, moderation, and transcript control. 11.02 Voice
Diffusion Model
A diffusion model is a type of generative model that learns to create images, audio, or video by reversing a process that gradually adds noise to training examples. At generation time it starts from noise and denoises step by step into a coherent result, which is why it is common in image generation systems. Why it matters: It changes which media experiences are feasible, what latency to expect, and which safety controls are needed for generated imagery. 11.03 Image and video generation
SynthID
SynthID is a watermarking method for AI-generated media that embeds a subtle signal in content so later systems can help identify it as machine made. It supports provenance, meaning evidence about where content came from, but it is not perfect proof because edits, cropping, compression, or re-recording can weaken the signal. Why it matters: It changes how confidently you can claim AI provenance. It supports disclosure and trust, but should not be your only authenticity control. 11.03 Image and video generation
Input Guardrail
An input guardrail is a check on user input, retrieved content, files, or tool results before they reach the model. It can block prompt injections, meaning malicious instructions hidden in content, strip personally identifiable information, validate structure, or route risky requests away from automation, reducing the chance that unsafe instructions enter the workflow at all. Why it matters: It changes what requests are allowed into automation at all. Good input checks stop many incidents before the model reasons over bad instructions. 12.04 Guardrails in the request path
Output Guardrail
A check placed after a model generates something, but before a user sees it or a system acts on it, to catch unsafe, incorrect, or badly formatted responses. Teams implement these with rules, classifiers, or secondary models that block, rewrite, route to a human, or ask for regeneration when the answer violates policy. Why it matters: It tells you when to block, edit, or escalate a response instead of shipping raw model output. 12.04 Guardrails in the request path

Related