Google's AI Design Playbook Has Six Chapters. The Most Important One Is Missing
A close reading of the PAIR People + AI Guidebook, and an honest stress-test of all six chapters against the age of agents.
There’s a document that surfaces in every serious conversation about designing with AI, and it predates almost everything we now argue about. Google’s People + AI Guidebook, published by the PAIR team in 2019, refreshed in 2021, and quietly amended from late 2023 onward as generative AI arrived, has become one of those references everyone cites and fewer people actually reread.
I want to reread it properly here, chapter by chapter, framework by framework, because the Guidebook is a near-perfect fossil. It was written in a world where AI predicted and recommended but did not act. Hold it up against the systems we’re shipping in 2026 and you can see, with unusual clarity, exactly where human-centered design scales cleanly into the agentic era and exactly where it fractures.
This is a longer read than usual. That’s deliberate. The Guidebook deserves more than a chapter-title summary, and the agentic critique only earns its keep if it engages the actual mechanics. So: six chapters, each one read for what it really says, then stressed against a system that doesn’t just answer but takes the wheel.
A note before we start. PAIR organises the six chapters as a rough split: three rooted in UX and trust (User Needs, Mental Models, Explainability + Trust), three rooted in the technical guts of an AI product (Data, Feedback + Control, Errors). The quiet thesis underneath is that you can’t separate them: the model and the interface are one product, designed together or designed badly. That thesis has aged extraordinarily well. Some of the execution has not.
Chapter 1: User Needs + Defining Success
What it actually says. The chapter opens with a discipline most teams skip: don’t ask “can we use AI to do X,” ask “how might we solve X, and does AI solve it in a way nothing else can.” It’s blunt that a rule or heuristic often beats a model (simpler to build, explain, debug, and maintain), and it lists the situations where AI genuinely earns its place (personalisation, prediction, natural-language understanding, recognising whole classes of entities, detecting rare evolving events) versus where it doesn’t (when predictability is the value, when errors are costly, when total transparency is required).
Then comes the chapter’s real spine, two ideas worth internalising:
The automation-versus-augmentation decision. PAIR’s heuristic is elegant. Automate tasks that are difficult, unpleasant, dangerous, or need scale, and where people broadly agree on the “correct” way to do them. Augment tasks people enjoy, that carry social capital, that are high-stakes, or where the person’s preferences are too personal to delegate. Crucially, the chapter insists that even full automation should keep a human “on the loop”, able to preview, edit, or undo.
The reward function. This is the chapter’s most undervalued passage. The reward function is how the system defines right and wrong, and PAIR treats it as a design artefact, not an engineering detail: something a cross-functional team should deliberately shape, weighing false positives against false negatives, trading precision against recall, and gaming out second-order effects. Their litmus test is sharp: imagine the reward function perfectly optimised, and ask what happens to your users, their families, and society. Optimising to surface the best web page for a query is good when perfect. Optimising to hold attention all day is not.
Where agency strains it. The automation/augmentation binary was built for tasks. Agents operate on processes: multi-step chains where a single instruction triggers a cascade of sub-decisions. “Book me a table near the cinema for after the film” isn’t a task to automate or a skill to augment; it’s a small project the agent decomposes, executes, and only sometimes checks back on. The binary doesn’t dissolve, but it stops being a clean fork in the road and becomes a question you have to answer per step: which links in this chain may run unattended, and which must surface for a human?
The reward-function guidance ages better, but the stakes multiply. A recommendation’s reward function is evaluated against one output. An agent’s objective is evaluated across a trajectory, where second-order effects don’t just accumulate; they compound and interact, because each action changes the state the next action operates on. PAIR’s “imagine it perfectly optimised” test becomes both more necessary and far harder to run, because you’re no longer imagining a perfect prediction, you’re imagining a perfectly optimised sequence of actions in the world. And “human on the loop”, a single reassuring clause in the 2019 text, quietly becomes the entire design problem of the agentic era.
Chapter 2: Data Collection + Evaluation
What it actually says. This is the most technical chapter, and its logic is “translate user needs into data needs.” It walks through examples, features, and labels; the difference between using an existing dataset and building your own; the discipline of splitting training and test sets; and a genuinely good section on raters (the people who label data), arguing you should research raters with the same rigour you’d apply to end users, because their boredom, incentives, and unconscious bias flow straight into the model’s behaviour. It’s strong on fairness as a first-principles concern (representational harm, opportunity denial, disproportionate failure) and on the unglamorous reality that real data is messy and tuning never stops.
One line matters more than it first appears: the warning about compounding errors from other ML models. If you feed one model’s output into another as a training feature, the errors stack, and the further you get from the original data, the harder they are to trace.
Where agency strains it. Most teams building agentic products today aren’t training a model from scratch; they’re orchestrating a foundation model they didn’t build and can’t fully inspect. That doesn’t make this chapter obsolete; it relocates it. The “data” question shifts from what do I collect to train toward what do I put in front of the model at runtime: the context, the retrieved documents, the tool definitions, the memory, the system instructions. Data curation becomes context engineering. The principles survive (representativeness, bias, provenance, messiness), but they move from a training-time concern to a live, per-interaction one.
And that buried warning about compounding errors? In a multi-agent system it stops being a footnote and becomes the central failure mode. When one agent’s output is another agent’s input, and that agent calls a tool whose result feeds a third, errors propagate through the chain exactly as PAIR warned, only now they propagate at runtime, in production, action by action, with no clean training-data lineage to trace them back through. The rater section, meanwhile, reads in hindsight like an early sketch of everything we now call human evaluation and preference data. PAIR was describing the labelling pipeline that, scaled up, became RLHF.
Chapter 3: Mental Models
What it actually says. A mental model is a person’s working theory of how a thing behaves and how their actions affect it. The chapter’s argument is that AI breaks the static-product assumption (these systems adapt, so users need a model that includes change over time), and it offers concrete tooling for building that model: onboard in stages, set expectations before first use, explain the benefit rather than the technology, introduce features at the moment they’re relevant rather than in an up-front list, and design for low-risk experimentation so people can probe the edges safely.
It gives a clean onboarding scaffold (tell the user what this is, what it helps with, what it can’t do yet, that it will change, and how their input improves it) and a concept it calls co-learning: the user teaches the system, the system changes, and the user’s model has to update in turn.
Then the chapter does something prescient. It devotes a whole section to anthropomorphism, warning that human-like framing sets human-like expectations the system can’t meet, that people disclose more and over-rely when they mistake software for a person, and that the algorithmic nature of the thing must be made unmistakable. It’s openly nervous about a conversational AI referring to itself as “I,” because that single pronoun imports an expectation of near-perfect understanding.
Where agency strains it. This chapter doesn’t break. It gets more important, and its anthropomorphism warning lands like a prophecy. Agents are deliberately personified (they have names, personalities, first-person voices) and they act autonomously in the world. That’s precisely the combination PAIR flagged as most dangerous: maximum human-like framing fused with maximum consequence. When a system that calls itself “I” can also send the email, move the money, or merge the branch, the cost of a mismatched mental model is no longer a disappointed user; it’s an action taken on a misunderstanding.
The co-learning idea also has to stretch. PAIR’s version is a feedback loop on recommendations: you teach it your taste, it tunes. With agents, co-learning is about calibrating trust in delegation: learning what this system can be handed and what it can’t, where its autonomy is safe and where it isn’t. That’s a harder mental model to build, because the system’s competence is wildly uneven (superhuman at one step, brittle at the next), and the user has to develop an intuition for that jagged edge. The Guidebook’s instinct (set honest expectations about capability and change) is exactly right. The territory it has to cover is an order of magnitude larger.
Chapter 4: Explainability + Trust
What it actually says. The chapter’s organising idea is calibrated trust: not maximal trust, but the right trust, where users believe the system when it’s reliable and apply their own judgement when it isn’t. It names both failure modes honestly: algorithm aversion (reflexive suspicion of software) and over-trust (leaning on the system for things it can’t do). It argues that you often can’t fully explain a complex model (sometimes even the builders can’t), so you should aim for partial explanations that surface only what affects trust and decisions: data sources, general system behaviour, specific-output rationales, example-based explanations (”here are similar cases”), and explanation-via-interaction (let people poke it and watch it respond).
It’s especially good on confidence displays, laying out the options (categorical buckets, n-best alternatives, numeric percentages, data visualisations) and warning that raw numbers presume a fluency with probability most users don’t have (”what do I do with 85.8% versus 87%?”). And it ties everything to situational stakes: explain more, and prompt the user to double-check, precisely when the cost of being wrong is high.
Where agency strains it. Every technique here was designed to explain an output: a prediction, a classification, a recommendation sitting still on the screen, waiting to be accepted or ignored. Agents don’t produce outputs; they produce trajectories. Explaining “why this restaurant” is a solved-ish problem. Explaining “why I searched these three sites, discarded the first, booked the second, and am now about to enter your card details” is a different category of problem. You’re explaining a plan and a sequence of actions, some already taken, some imminent and irreversible.
Calibrated trust fractures into something more granular: trust per class of action. I might fully trust an agent to draft, partly trust it to send, and never trust it to delete, and the interface has to let me hold three different trust levels simultaneously, for the same agent, in the same session. Confidence, too, gets harder. PAIR worried about communicating one model’s confidence in one prediction. An agent’s confidence is distributed across a chain (high that it found the right flight, low that it parsed the change-fee policy correctly), and the dangerous step is often the low-confidence one buried mid-trajectory, where no one’s looking. The chapter’s deepest instinct (explain most, and force a check, when stakes are highest) is the single most portable idea in the whole Guidebook. It just now has to operate on actions in flight, not outputs at rest.
Chapter 5: Feedback + Control
What it actually says. Feedback is the channel between user, product, and team. The chapter distinguishes implicit feedback (behavioural signals from your logs: what people open, accept, reject) from explicit feedback (deliberate input: ratings, thumbs, text), warns about dual feedback where a single action carries both (a public “like” is a social act and a tuning signal, and conflating them misreads intent), and offers a genuinely useful taxonomy of why people give feedback at all: material reward, symbolic reward, personal utility, altruism, intrinsic motivation, each with its own biases.
It’s practical about time-to-impact messaging, showing how “thanks for your feedback” (which promises nothing) differs from “your next run won’t include hills” (which promises a specific, scoped change), and insists you only promise what the model can actually deliver, since feedback rarely changes output immediately.
The back half is about the balance between control and automation, and it’s the most relevant passage in the book for where we are now. People keep control, PAIR says, when they enjoy the task, feel responsible for the outcome, face high stakes, or hold a vision they can’t easily articulate. They cede control when they can’t do the task or find it unpleasant. The chapter’s safety rail throughout is the manual failsafe (always leave a non-AI way to get the thing done), plus editability (let users revise prior feedback, reset the model to its default) and easy opt-out.
Where agency strains it. This is where the fracture runs deepest, because the chapter’s model of “control” is control over what the system shows you, and agency is about control over what the system does to the world on your behalf. Those are not the same problem wearing different clothes.
“Return control to the user” assumes a clean handoff: the system offers, you dispose, and at any moment you can simply take over the single decision in front of you. But an agent three actions into a five-action plan isn’t a recommendation you can decline; it’s a process already underway, with state already changed. Handing control back means answering questions the Guidebook never had to: Can the user interrupt mid-action, or only between actions? When they take over, what’s the state of the world, and how do they even see what’s been done so far? Is there an undo, or only a stop?
Editability, in the agentic frame, splits into two distinct needs the original chapter treats as one. There’s editing a standing preference (PAIR’s version: revise your taste, reset the model) and there’s interrupting an action in flight (the agentic version: halt the thing that’s currently happening). The manual failsafe survives and arguably becomes non-negotiable, but it inverts: in a recommendation product the manual path is the boring fallback nobody uses; in an agentic product the manual path is the circuit breaker, the thing that has to work flawlessly precisely when everything else has gone wrong.
Chapter 6: Errors + Graceful Failure
What it actually says. This is the most sophisticated chapter in the book, and the one that’s quietly about the future. It starts by complicating “error” itself: in AI systems, alongside the familiar user errors and system errors there’s a third kind: the context error, where the system works exactly as designed but the user perceives a failure because the output broke their mental model or rested on a bad assumption (the classic example: a flight email silently creating a calendar event you never wanted).
It then builds a real taxonomy. Failstates (the system genuinely can’t answer). Background errors (the system is wrong but neither the user nor the system notices, the most dangerous category, requiring dedicated QA to surface “unknown unknowns”). Happy accidents (flagged as failures but useful anyway). It catalogues error sources (prediction and training-data errors, input errors, relevance errors), each with a suggested response built around returning control and inviting feedback. And it weighs error risk against situational stakes in a clean grid: novice user, low confidence, narrow success criteria, divided attention all push risk up; expertise and high confidence pull it down.
And then, in 2019, it writes the section that should make any agentic designer sit up. Under system hierarchy errors, PAIR describes what happens when multiple AI systems interact and don’t coordinate: conflicts over who’s in control, and signal crashes where several systems respond to the same trigger at once and overwhelm the user. Their examples are a smart thermostat fighting a smart meter, and multiple voice assistants all waking to the same command.
Where agency strains it, and where PAIR saw it coming. That system-hierarchy section is the multi-agent orchestration problem, described years before it became the thing half of us are paid to solve. PAIR filed it as an edge case, a tidy subsection near the end of the last chapter. For agentic systems it is the centre: who arbitrates when two agents pursue conflicting sub-goals, how you prevent signal crashes when a swarm of agents all act on one instruction, how you make the chain of control legible when no single system is obviously “in charge.” The Guidebook named the disease; it just didn’t know it was describing an epidemic.
The deeper strain is on “graceful failure” itself. The whole chapter assumes failure happens before consequence: the bad recommendation you can ignore, the wrong classification you can correct, the dead-end you back out of. The defining property of agentic failure is that it happens after action. The agent already sent the email to the wrong client, already cancelled the booking, already pushed the commit. “Prevent undue harm and help the user move forward”, PAIR’s stated goal for failstates, now has to encompass things the original text only gestures at: reversibility, rollback, transactional safety, audit trails, blast-radius containment. Graceful failure in a system that acts isn’t about writing a good error message. It’s about engineering the undo before you ever ship the do.
The seventh chapter PAIR hasn’t written
Read the six chapters this way and a shape appears in the negative space. Each one, stress-tested, points at the same missing thing. User Needs gestures at “human on the loop” without specifying the loop. Mental Models warns about personified systems that act, without saying how to govern them. Explainability can explain an output but not a plan. Feedback + Control can hand back a decision but not interrupt a process. Errors can fail gracefully before a consequence but not contain one after. The gap they circle but never enter is authority: the question of what an autonomous system may do, decide, and initiate on your behalf, under what conditions, and who answers for it when it’s wrong.
If I were drafting the seventh chapter, I’d call it Agency + Accountability, and it would have to cover the things the original six can’t reach:
Permission and its boundaries. Not a one-time consent screen but a living grant of authority: scoped, revocable, and as fluid as the trust you extend to a new colleague. What can this agent do unattended? What requires a check? What is simply off-limits, regardless of confidence?
Interruptibility and reversibility. The right to stop a process mid-flight, see precisely what’s been done, and undo it where the world allows. This is the manual failsafe reconceived as a circuit breaker, and it’s load-bearing.
Accountability assignment. When an agent acts and the outcome is wrong, the question “who is responsible” must have an answer designed in, not litigated after. The audit trail isn’t a compliance afterthought; it’s the spine of the experience.
Orchestration and arbitration. PAIR’s system-hierarchy edge case, promoted to a first-class concern: how multiple agents coordinate, how conflicts resolve, how the chain of authority stays legible to a human who needs to know, at a glance, who is doing what on whose say-so.
None of that is decoration. It’s the load-bearing structure of an agentic experience, and it’s exactly the work that didn’t exist to be written about in 2019.
This is the through-line I keep returning to in my own practice: the job has moved from designing interfaces, to designing experiences, to designing agents, and the discipline at the agent layer is orchestration, not decoration. The PAIR Guidebook is, in a real sense, the last great document of the pre-orchestration era. It taught a generation of designers to treat the model as a material and the human as the point. That lesson is permanent. What it couldn’t teach, because the technology hadn’t arrived, is how to design for a material that acts.
Read it anyway, and read it forward
So: still the best map we have? For the territory it was drawn to chart, without hesitation. The three trust chapters (User Needs, Mental Models, Explainability) are arguably more relevant today than the day they shipped, and the Errors chapter quietly predicted the multi-agent problem half a decade early. There is no better foundation in print for human-centered AI design, and anyone building these systems who hasn’t read it closely is working with a handicap.
But a map is drawn for a known landscape, and the landscape moved under it. The Guidebook will teach you how to earn trust, set honest expectations, calibrate confidence, and fail gracefully when a system recommends. It will not, yet, teach you how to govern a system that acts. That chapter we’re writing ourselves, in real time, in the products we ship this year.
So reread it. Take everything it says about the human; all of it holds. Then walk back through every chapter with the question PAIR couldn’t have asked in 2019: what changes the moment the machine stops advising and starts doing? The reward function becomes a trajectory. The mental model becomes a theory of delegation. The explanation becomes a plan. Control becomes interruptibility. Graceful failure becomes reversibility. And the whole edifice acquires a seventh load-bearing wall, authority, that nobody has finished building.
That unfinished wall is where the next decade of design work actually lives.
The People + AI Guidebook is published by Google’s People + AI Research (PAIR) team and is freely available at pair.withgoogle.com/guidebook under a Creative Commons licence. The six chapters (User Needs + Defining Success, Data Collection + Evaluation, Mental Models, Explainability + Trust, Feedback + Control, and Errors + Graceful Failure) each ship with a worksheet for turning the guidance into team practice.