Chapter 1: What You Need to Know About AI

Probabilistic systems break the deterministic toolkit you built your career on, so you need real AI literacy. You also need to know what to ignore, because most of what sounds essential to product design is not.

You do not need the internals. You need the small set of first principles that, gotten wrong, produce product decisions that are confidently and expensively mistaken, plus the vocabulary the rest of the book assumes you can hold: where agentic AI came from, what makes it different in kind, and the handful of moving parts a 2026 product is actually built from. This chapter is that set, and an equally important list of what you can leave to the engineers. It is also the chapter that will age fastest, so the durable ideas are marked as durable and the dated ones as dated, on purpose.

Three eras, and why your toolkit broke on the third

It helps to place agentic AI on the arc it came from, because the arc explains why the methods you trust stopped working only recently. There have been three eras of applied AI, and a product manager has lived through at least the last two.

The first was predictive, or discriminative, machine learning: models that classify, score, rank, and forecast. The fraud model that flags a transaction, the recommender that ranks a feed, the churn model that scores an account. These are probabilistic too, but in a contained way: the output is a label or a number, the range is known, you can hold out a test set and measure accuracy before you ship, and the system does not act, it informs a decision a human or a rule then makes. The deterministic toolkit bent to fit this without breaking, because you could still write acceptance criteria around a measurable output.

The second was generative: models that produce content, text, images, code, rather than label it. This is where the toolkit started to strain, because the output is open-ended. There is no single correct paragraph, so “pass or fail” stopped being a real answer and “good enough, often enough” took its place. But generative AI in its first form still mostly responded. You asked, it produced, a human read the result and decided what to do with it. The human was still the actor.

The third era is agentic, and it is the one that breaks the toolkit at the root, because the system now acts. It does not produce a draft for you to use; it decides what to do, takes the action, observes the result, and continues toward a goal, in a loop, without you in it for each step. That single shift, from a system that informs or responds to one that decides and acts, is why agentic AI is a different discipline and not a faster version of the last one. Everything in this book follows from it.

What a language model actually does, and what it does not

Two words first, because the book and the bills both use them constantly. The prompt is everything you hand the model to respond to: the instruction, the question, and increasingly the retrieved documents and the running conversation, the whole input it conditions its answer on. The token is the unit the model reads and writes in, a chunk of text roughly a few characters long, smaller than a word; a page of text is several hundred tokens. Tokens matter to a PM for one practical reason: they are the unit you pay in and the unit the model’s attention is spent on. Every model call has a token cost going in (your prompt) and coming out (its response), and the architecture chapter shows why that, not the model’s sticker price, is what actually drives the bill.

Strip it to the load-bearing minimum. A model takes text (and now images, audio, more), and produces a continuation that is statistically plausible given everything it has seen. That single mechanism explains almost everything you need to predict about its behavior: it is fluent because plausible text is fluent; it hallucinates because the most plausible continuation is not always the true one, and the model has no separate sense of truth to consult; it is confident even when wrong because confidence is a property of the text it is imitating, not of its knowledge. When the model fabricates a citation, it is not malfunctioning. It is doing exactly what it always does, producing plausible text, in a case where plausible and true diverged.

Hold that and most “surprising” model behavior stops surprising you. It also tells you where the design risk lives: not in whether the model is capable, which it increasingly is, but in the gap between plausible and correct, which is yours to manage.

This is the first principle that replaces the one your career was built on. The deterministic toolkit assumed the system does what you specified: write the rule, the rule executes, the same input gives the same output, and when it breaks there is a line of logic to find and fix. A model breaks that assumption at the root, because nothing was specified, only learned, so the same prompt can give different outputs and there is no faulty line to repair. The replacement principle is simple to state and reorganizes everything downstream: the system is probabilistic, so you design for a distribution of behavior, not a guaranteed output. “It works” becomes “it works this often, fails in these ways, and here is what happens when it does.” Every later chapter, evals, oversight, drift, is a consequence of taking that sentence seriously.

The four-layer stack

A PM keeps getting confused about AI products because the conversation collapses four different things into one word, “the AI.” Separate them, because each is a different decision you own.

The reason this matters for product decisions: teams obsess over layer one, the model, which is the layer they control least and which is converging toward commodity. The product you actually design lives in layers two through four, which is where your judgment compounds and where, when something goes wrong, the cause usually is. When an agent gives a bad answer, the instinct is “we need a better model.” The cause is far more often thin context or loose orchestration.

One word in that last layer is doing double duty, and the overload is worth catching now, because it hides the failure this book returns to. “Context” in the stack above means everything the model reasons over: the documents, the data, the instructions. But in data architecture context means something narrower and deeper, the layer that describes what the data means: its ontology and semantics, the references and relationships, the knowledge-graph links that say this identifier is that customer, this code is a retired diagnosis, this number is dollars and not euros. Picture an iceberg. The value the agent reads, a purchase-order row, a patient record, a price, is the tip above the water. Below the surface is the meaning: what the field refers to, which records relate to it, what authority stands behind it, whether the entry is still true. When data moves between systems the tip travels and the meaning often stays behind, and an agent handed the tip without the context beneath it will reason flawlessly over data it does not actually understand. That gap, data arriving without its meaning, is where a whole class of agentic failure lives, and it gets a chapter of its own later in the book.

Two of those lower layers have a name and a 2026 standard worth knowing, because they are where the harness around the model is actually built and where the data-layer failures later in this book originate.

The context layer is most often filled by retrieval-augmented generation, RAG: rather than relying on what the model memorized in training, the system retrieves relevant documents from a knowledge base at the moment of the question and hands them to the model as context to reason over. This is how an agent answers about your company’s policies, your customer’s history, this morning’s prices, none of which were in the model’s training. The durable idea is that the model reasons over what you retrieve, so the quality of the retrieval often matters more than the quality of the model. The 2026 form is agentic RAG: the agent does not run one lookup, it runs retrieval as a loop, querying, judging whether it has enough, refining, querying again. The field’s hard-won lesson, stated in its own words, is to treat the knowledge source, not the model, as the primary investment, which is this book’s thesis arriving from a different direction. The names will change; that the agent is only as right as what it retrieves will not, which is why an entire later chapter is about the data the agent reasons over.

The tools layer is how the agent acts in the world, and in 2026 it increasingly does so through the Model Context Protocol, MCP: a standard interface that lets an agent discover what tools, data sources, and systems are available and call them without a bespoke integration for each one. By late 2025 there were thousands of public MCP servers; it became, quickly, standard infrastructure, the way a standard like HTTP or USB becomes invisible by becoming universal. For a PM the specific protocol is a dated detail and will be superseded; the durable point is that a standard tool interface is what turns a model that can only talk into an agent that can act across systems, and that every tool you connect is a new thing the agent can do and therefore a new thing it can do wrong. The harness, the loop that decides, calls tools, checks the result, and recovers, is the product. The model is the part everyone shares.

Constitution: the agent’s behavioral contract

A word you will meet constantly in 2026, in vendor docs, dev forums, and your own engineers’ pull requests, is constitution. A chatbot needs instructions. An agent needs a constitution, because it may plan, call tools, write to systems, message people, and trigger workflows without a human checking each move, and the question “how should it behave when it has discretion” has to be answered somewhere it cannot quietly ignore. The constitution is that answer: the written set of principles that governs what the agent may do, what it must never do, and how it should decide when the situation is ambiguous. It is not a prompt. It is the agent’s behavioral contract.

The term comes from Anthropic’s Constitutional AI, where a model is trained against a written list of principles it uses to critique and revise its own outputs, and the principles are values, drawn from sources like the Universal Declaration of Human Rights: be helpful, honest, harmless. Anthropic published a new constitution for Claude in early 2026 and put it in the public domain, which tells you the artifact is meant to be read, argued with, and adopted, not hidden. For an agentic product the meaning becomes more operational than pure values. A working constitution defines the agent’s purpose and scope, its hard prohibitions, the triggers that make it stop and escalate to a human, the evidence standards it must rely on, how it behaves under uncertainty, and which value wins when two collide, safety over speed, fairness over throughput. It runs from values at the top to non-negotiable constraints at the bottom, and both ends are the same document: the values are the stable frame, and the constraints are how the values become checkable.

It helps to see where the constitution sits relative to the things it is often confused with, because they are four different altitudes of the same control, not four unrelated things:

The danger, and it is the one this whole book is about, is a constitution that sounds ethical but is not operational. “Be safe, fair, and transparent” governs nothing, because nothing downstream can test it. A useful constitution is concrete enough to become test cases, refusal and escalation behavior, tool-use constraints, audit criteria, and release gates. If you cannot turn a principle into one of those, it is decoration.

Two cautions for the PM. First, stated is not enforced. The constitution declares intent; whether the agent honors it is a separate question answered by evals, guardrails, monitoring, and audit logs, which is why a later chapter argues that a boundary written as a sentence in the constitution and nowhere in the execution path is not a boundary at all. The constitution lives in the supervisory layer this book calls Channel 2: it gives the agent a stable behavioral frame, and the rest of Channel 2 tests whether the agent actually follows it. Second, the word gets overloaded. Some developer tooling, GitHub’s Spec Kit among it, uses “constitution” for a file of engineering principles (test-first, simplicity, library boundaries) that govern how the team builds, not how the agent behaves. That is a useful artifact and a real homonym; it has no purpose, prohibitions, escalation, or value-priority for the agent, so it is not the sense this book means. When an engineer says “it failed the constitution check” they may mean that build-discipline file; when this book says constitution, it means the agent’s behavioral contract.

The industry is converging on this idea fast and under several names, the agentic constitution, policy-as-code, runtime governance, and the structure underneath all of them is the one this book calls Channel 2: a declared behavioral contract for the agent, enforced where the agent acts rather than where it was prompted. Treat the constitution as the part of Channel 2 you write down first, the standing frame the rest of the supervisory layer is built to enforce. The names will multiply; the move they all describe is the same one, and it is the subject of this book.

Agent versus agentic

Two words the book uses constantly are worth separating, because they are not the same thing and the title of this book turns on the difference. An agent is the thing: a system that decides what to do next, takes the action, observes the result, and continues in a loop toward a goal, as opposed to a tool, which does what you invoke and stops. A chatbot that answers is a tool. A system that reads the ticket, updates the record, emails the customer, and escalates if needed is an agent. Agentic is the adjective for the property that makes it one: autonomy, the pursuit of a goal across multiple steps, the model choosing and acting without a human in the loop for each move. A product is agentic to the degree that it acts on its own between the points where a human checks it. The distinction matters because you can bolt an “agent” into a product and still owe none of the new design work, if a human approves every step it is barely agentic, or you can build something deeply agentic, acting many times before anyone looks, and owe all of it. The supervision problem, the speed problem, the accountability problem, the whole of this book, scales with how agentic the system is, not with whether you called the feature an agent.

One more thing about shape, because the singular “the agent” in this book is a simplification worth naming. Real agentic systems are usually not one agent but several working as a group: an orchestrator that routes the task, specialist agents that each own a piece, agents that call other agents as tools. A customer-service system might have one agent that classifies the request, another that drafts the reply, a third that checks it against policy, coordinated by a fourth. And those agents need not run on the same model: a cheap, fast model can do the classification while a frontier reasoning model handles the hard judgment, each agent matched to the type and complexity of its work, which is model routing applied inside the system rather than across requests. Those models are not interchangeable parts. Each has its own characteristics, its own way of handling ambiguity, its own quirks, and each is updated on its own vendor’s schedule, at its own interval. So a system built from several models is a system whose pieces can change independently, at different times, without anyone on your team choosing the moment.

This is the common production pattern, not the exception, and it adds failure modes a single agent does not have: an error in one agent propagates to the others, the cost multiplies with every agent in the chain, and accountability diffuses across a team where no single agent owns the outcome. This book talks about “the agent” in the singular throughout, deliberately, because every principle here, the boundary, the supervision, the audit, the human system, applies to each agent in a group and to the group as a whole; the unit is easier to think about one agent at a time, and the supervisory problem only compounds when there are many. When your system is a team of agents, read “the agent” as “each agent, and the team.”

The Supervision Paradox, in preview

One idea will recur so often it deserves planting now. Bainbridge’s irony of automation: the better the automation, the worse the human gets at the job of catching it when it fails, because they stopped practicing, and the rarer and harder the cases where they must. Your supervisory design improves the normal case and degrades the abnormal one, which is the only case that needed a human. Part V develops this into the core of the human-system problem. Carry it from here: every time you hand work to an agent, you are also changing what the human supervising it can still do.

What you can safely ignore

As important as the literacy is the discipline of not chasing the rest. For product design in 2026, you can safely ignore training architecture, tokenizer mechanics, attention-implementation details, fine-tuning internals, and most of the benchmark horse race. They are real engineering concerns; they are not your decisions, and time spent mastering them is time not spent on the layers you own.

The current literacy floor is smaller than the noise suggests. You need: the capability tiers (flagship, mid, budget) and roughly what each costs; the reality that context windows are large now, so the constraint is the model’s effective attention, not window size; when a reasoning model is worth its latency and cost and when it is overkill; the hosted-versus-self-hosted choice, which for regulated work is now a real option because capable open-weight models exist; model routing, sending each task to the cheapest model that can do it; and the observability primitives, what you can measure about a model in production. One shift belongs on this list because it reframes where your effort goes: the field has moved from prompt engineering, optimizing how you ask, to context engineering, optimizing what the agent is given to work with, which sources it can see, which are current, how much fits in a turn. Prompt phrasing is a perishable interface skill; deciding what the agent gets to reason over is durable product work, and it is most of the data-layer problem this book takes up later. That list is the whole minimum. Everything past it, for your purposes, is someone else’s expertise, and treating it as yours is a way of avoiding the harder product work this book is actually about.

A note on dating, since this chapter ages fastest. The specific model names, prices, and protocols in your head right now, the current flagship, today’s token cost, MCP itself, will be wrong or renamed within a year or two. What will not: the three-era arc, the probabilistic first principle, the four layers, the agent-versus-agentic distinction, retrieval deciding what the model reasons over, a standard tool interface turning a model into an actor, and the supervision paradox. Learn the current tools the way you learn this quarter’s competitors: necessary, perishable, and not where your durable skill lives.

The same goes for the frameworks, not just the tools. A burst of named methods is arriving around the ideas in this book, spec-driven development, the agentic constitution, policy-as-code, runtime governance, and more will have appeared between this writing and your reading. This book names the ones with real momentum where they illustrate something durable, and otherwise lets them go, because the bet here is structural: the supervisory layer, Channel 1 and Channel 2, the behavioral contract and its enforcement, is the thing the vocabulary keeps circling. When you meet a term this book did not name, the test is the one to apply: ask what it does for the agent’s behavior and where it is enforced, and you will usually find it is one of these moves under a new label. Stay connected to the names; stay anchored to the structure.

Take one agent on your own roadmap and try to name all four of its layers out loud. The one you stumble on, the layer you can describe least precisely, is the layer your quality problems will come from, and it is almost never the model.