Demonstrate Over Tell

In the last year, the machine side of almost every exchange in a working organisation became effectively unlimited.

An agent will write you a three-thousand-word analysis before you've finished your coffee. Every meeting is recorded, transcribed, summarised and mined for actions. Status reports draft themselves. Research digests arrive overnight. Whole company websites get built by agents that were given an idea and nothing else. Output stopped being the constraint on anything.

The human side didn't change. It's the same pair of eyes, the same working day, the same number of things a person can hold in their head at once. And almost none of that output is read the way it was written.

This book is about the place where those two meet — the moment the machine's output lands in front of a person. I've come to think it's the most neglected point in the whole AI stack. Everyone has an opinion about models, prompts, agents and governance. Almost nobody owns the receiving end. That's why the fixes we reach for when nobody reads the output tend to make things worse.

Reading didn't move

The research on how people read screens has been saying the same thing for a long time, and it has never been more relevant than now. In Jakob Nielsen's early studies, the headline was blunt: "79 percent of our test users always scanned any new page they came across; only 16 percent read word-by-word."¹ A decade later, Nielsen analysed 45,237 page views and estimated that "on the average Web page, users have time to read at most 28% of the words during an average visit; 20% is more likely."²

Be precise about that last figure, because it's easy to misquote. It isn't a measure of comprehension. It's a time budget: the most a person could have read, given how long they stayed. That makes it worse news for AI output, not better. A time budget doesn't care how good your three thousand words were. Most of them were never in the running.

The same research found that people scan in shapes — the F-pattern is "the default pattern when there are no strong cues to attract the eyes towards meaningful information," and "when people scan in an F-shape, they miss big chunks of content based merely on how text flows in a column."³ Put a wall of AI-generated prose in front of a busy person and what they take away is decided less by what you wrote than by where the line breaks fell.

Chris, who I work with, has his own version of this. He doesn't read things. He skim-reads. As far as he's concerned, writing more than about twenty words to him is pretty useless. That's Chris's rule, not a law of nature — some people read more, and so does Chris when something's worth it. But as a description of what happens at the receiving end of most AI output, it's more accurate than anything in the vendor decks.

What the receiving end looks like today

If you look at what AI actually delivers to people in most organisations right now, four defaults turn up again and again.

The summary of the summary

A meeting is transcribed. The transcript is summarised. The summary is too long, so it's summarised again. Then someone asks for "just the key points". Each step feels like progress. I don't think it is. Summarising in increasing levels just means you've lost anything that was useful there. The architecture that fixes this has a chapter of its own (Chapter 6); for now, notice that the instinct behind it — nobody reads it, so make it smaller — is the instinct this book argues against.

The to-do list nobody follows

The natural end of the summary chain is the action list. Chris wants it more and more summarised, and then he wants to-dos out of it. And I know people don't follow the to-dos, so that's pretty useless too. The list looks like accountability. It's usually a set of sentences that happened to be shaped like tasks, owned by nobody. (You'll see widely quoted figures for how many meeting actions never get done. I haven't found one with a traceable source, so I won't use one. The shape is familiar enough without a number.)

The wall of prose

Ask an agent a question with three plausible answers and you'll get five paragraphs that walk through all three, with the recommendation somewhere near the bottom. My standing request, whenever I have options to discuss, is this:

"Don't wall-of-text me. Write me a web page about it and let's discuss it."

— Scott Farrell

I'll tell the story behind that line properly in Chapter 11. What matters here is what it's asking for: not less, but differently shaped.

The complete page that communicates nothing

Agents now build websites, and the early ones were correct, complete and dull. Every section present, every benefit stated, and nothing that let a visitor see what the business actually did for them. Chapter 9 is the story of how that changed, and it's the story that gave this book its title.

The cost moved downstream

There's a name now for one version of this problem. Researchers from BetterUp Labs and the Stanford Social Media Lab called it "workslop": "AI generated work content that masquerades as good work, but lacks the substance to meaningfully advance a given task." The mechanism they describe is the important part: "The insidious effect of workslop is that it shifts the burden of the work downstream, requiring the receiver to interpret, correct, or redo the work."⁴

To be fair to that research, it's about output that lacks substance, not output in the wrong shape. But the shape of the cost is the same, and it's the shape this book is about: the sender saves effort, and the receiver pays for it. My argument goes one step further. Even good AI output charges the receiver when it arrives as a description they have to rebuild in their own head. You can have entirely correct, substantive, well-written output that still costs its reader more than it should — because of how it was handed over, not what it said. That cost has a mechanism, and it's the subject of the next chapter.

The misdiagnosis

When people don't read AI output, the universal response is "make it shorter". Shorter summaries. Tighter bullet points. A TL;DR on top of the TL;DR.

Shortening reduces how much there is to read. It doesn't reduce the work of understanding what's there. A three-line summary of a complex trade-off still has to be rebuilt in the reader's head — they just have fewer pieces to rebuild it from. Often the pieces that went missing were the ones that made it make sense: the objection that changed the decision, the constraint that ruled out the obvious option, the moment someone said "no, that won't work because…". Shortening is a length fix for a problem that isn't about length.

Depth isn't the enemy

It would be easy to read all this as "short content wins". It doesn't, and I'd like to rule that out early. I don't mind reading things that are valuable. I sometimes listen back to a detailed description from AI — twenty minutes of it — and immerse myself in it. When I have the time, that's one of the best ways I know to understand something properly. The trouble is that I don't always have the time, and neither does anyone else. A wall of text makes you pay the whole twenty minutes up front just to find out whether it was worth paying.

The objective is not to abolish depth. It is to stop making a wall of text the price of admission.

Everything in this book keeps the depth. The recording, the transcript, the full analysis, the long-form explanation — none of it gets thrown away. What changes is what a person meets first, and whether they can get from there to the depth when they want it.

Change the scoreboard

If length is the wrong diagnosis, the metrics built on it are the wrong measures. Most organisations evaluate their AI by what it produces — words generated, summaries delivered, tasks extracted, reports drafted, time saved producing them. Those are all measures of the sending side. None of them tells you whether anything landed.

Each word in that measure is doing work.

Correct, because a fast wrong understanding is worse than a slow right one. A beautifully presented page that leaves someone confidently mistaken hasn't communicated; it's misinformed efficiently. Chapter 8 is about how you tell the difference, because it's harder than it sounds.

Shared, because communication runs in both directions. The human has to understand what the machine meant, and the machine has to understand what the human meant back — including when the human's answer is "no, not that". Most AI systems design the outbound half and forget the reply. Chapter 5 is the reply.

Human effort, because that's the scarce input. The machine's effort is cheap and getting cheaper. A person's attention isn't.

Here's what this scoreboard replaces:

• Words generated — counts the sending, not the landing.
• Summaries produced — a summary nobody opens is still counted.
• Tasks extracted — counts the extraction, not the commitment.
• Pictures shown — decoration counts as much as meaning (Chapter 3 says why that's a problem).
• Time in the app — long dwell can mean confusion.
• "Looks professional" — a page can look finished and tell the reader nothing.

The economics underneath

There's an economic argument under all this, and I've made it before at a larger scale. The Mature Token Law says the scarce budget in an AI-native organisation was never the tokens: "Spend machine cognition lavishly. Spend human attention ruthlessly." The machine side of the budget should be generous; the human side should be protected, and the job is converting one into the other.

This book is that law applied at the one place most teams never look: the moment the output meets a person. Drawing a whiteboard image for every subject of a meeting costs machine effort. So does generating five candidate reasons for why someone rejected an image, or rendering a small demonstrated moment instead of a paragraph of claims. Every move in this book spends machine effort to save human effort. That is exactly the trade you want to be making.

One move, three places

Over the last year I've been circling the same idea in three different places without noticing they were the same idea. The whiteboard makes the idea's relationships visible. The demonstrated moment makes the service experience visible. The shared canvas makes the current understanding visible — and correctable. In all three, the machine stops handing a person a description of the thing and starts handing them something they can recognise.

If length isn't the cost, what is? That's the first question, and the answer is the idea the rest of the book stands on.

There are two ways to receive the same thing.

You can read a description of it and build it yourself — hold the first sentence in mind while you read the second, work out how the parts relate, imagine what it would be like to use, and arrive, eventually, at a picture of the thing. Or you can see it, and recognise it.

Look at the two panels above and ask which you'd rather be handed at four o'clock on a Thursday. They contain the same information. One of them costs you something to understand and the other one doesn't.

Every move in this book is a move from the first way to the second. This chapter is about why the first way is so expensive — and why the fixes we usually apply don't make it any cheaper.

The tax, defined

Two properties make it dangerous.

The first is that the sender doesn't feel it. When an AI writes five paragraphs comparing three options, generating those paragraphs cost it almost nothing, and it has — in whatever sense a model has anything — the whole comparison available at once. The reader doesn't. They have to reassemble the comparison one sentence at a time. The cost of that reassembly lands entirely on them, and it never shows up on the sender's side of any ledger.

The second is that shortening doesn't refund it. This is the point Chapter 1 left hanging. A three-line summary of a complex trade-off still has to be rebuilt in the reader's head; it just gives them fewer pieces to rebuild it from. You haven't removed the tax. You've made it harder to pay.

Why prose charges it

Prose is linear. It gives you one thing, then the next, then the next. Relationships between things — this depends on that, which is owned by someone else, unless the other thing happens first — arrive as narration. The reader has to hold the early parts in working memory while the later parts arrive, and then assemble the structure the writer had in their head all along.

For some kinds of meaning, that's fine. An argument is linear; so is a story. But most of what AI now sends people isn't an argument. It's a comparison, a process, a set of responsibilities, a status across many moving parts, an experience a customer would have. Those things have a shape, and prose flattens the shape into a line that the reader has to fold back up.

Prose also happens to be the machine's cheapest output format and the human's most expensive input format. That asymmetry is why it's the default. Nobody chose it. It's just what comes out.

Larkin and Simon wrote it down in 1987

None of this is new to cognitive science. In 1987, Jill Larkin and Herbert Simon published a paper called "Why a Diagram is (Sometimes) Worth Ten Thousand Words". Its central observation reads, almost word for word, like a definition of the reconstruction tax:

"Diagrammatic representations also typically display information that is only implicit in sentential representations and that therefore has to be computed, sometimes at great cost, to make it explicit for use."

"Computed, sometimes at great cost." That's the tax. The information is there in the sentences; the reader has to do the work of pulling it out.

What a diagram does differently, they explain, is organise information by location: "much of the information needed to make an inference is present and explicit at a single location," and "problem solving can proceed through a smooth traversal of the diagram, and may require very little search." The part I find most useful is their explanation of why. Diagrams can be better "not because they contain more information, but because the indexing of this information can support extremely useful and efficient computational processes."⁵

Read that carefully, because it's the opposite of the popular version. A picture isn't worth a thousand words because it holds more. It's worth more because it has already done some of the reader's work for them. The layout pre-pays the computation.

Recognition is the refund

If reconstruction is the expensive operation, recognition is the cheap one — and the usability literature has a well-worn explanation for why. "Recognition is easier than recall because it involves more cues: all those cues spread activation to related information in memory, raise the answer's activation, and make you more likely to pick it."⁶ It's one of the standard usability heuristics: "Minimize the user's memory load by making elements, actions, and options visible."⁷

Put simply: when you can see the thing, the thing supplies the cues. When you have to build it from a description, you supply them yourself. Recognition is what the reader gets to do when the writer has done the building.

I've written before about a small version of this for personal memory, in The Recognition Loop — a system that hands you one small cue at the right moment and lets your own memory do the remembering, rather than narrating your life back to you. The same principle runs through this whole book at a larger scale. The machine's job is to prepare something the person can recognise. The person's job is the recognising.

What a whiteboard actually does

Here's the version of this everyone already knows.

When you're in a meeting and someone gets up and starts drawing ideas on a board, it's for a reason. You've learned it's a way to get a lot of meaning across without just sitting there, monotone, boring, giving a speech. Nobody teaches that. People who've spent enough time in meeting rooms just learn that at a certain point in an argument you stand up and pick up a marker.

The easy explanation — the one I started with myself — is that a picture tells a thousand words, so images must be a higher-bandwidth channel. It's instructively wrong. Look at what's actually on a good whiteboard. It's mostly words. A whiteboard isn't an alternative to text. It's text, spatial arrangement and relationships working together. The words are still there; they've been placed. This box is the goal. These two branch off it. This dotted line is the trade-off between them. That circled bit is the thing nobody has an answer for yet.

David Kirsh, writing about how people use physical space to think, sorted the ways into three: "spatial arrangements that simplify choice; spatial arrangements that simplify perception; and spatial dynamics that simplify internal computation."⁸ A whiteboard does all three. Grouping options side by side simplifies choosing between them. Lines, boxes and proximity let you see relationships instead of inferring them. And moving things around while you talk — rubbing out an arrow, circling a box — lets the room compute together on the board instead of separately in their heads.

(As an aside: Larkin and Simon went looking for the origin of "a picture is worth ten thousand words", which Bartlett's lists as a Chinese proverb. "On inquiry," they wrote, "we find that the Chinese seem not to have heard of it."⁵ The saying was never quite right, even about where it came from.)

The shape of the thought

I've made a version of this argument before, about machines. In The Skeleton of a Visual I described feeding image generators the quote they were meant to illustrate as a slab of prose, and getting mediocre results — then giving them the original structure the quote came from, and watching both generators improve. The conclusion was that "the shape of a thought is a first-class representation, distinct from both its prose and its rendering." Destroy it into a slab, and "you're asking the model to reconstruct what you threw away."

This book turns that argument around. People are no different. When a machine that already had the shape — the comparison, the dependencies, the sequence — hands a person a slab of prose, the person pays to rebuild the structure the machine threw away. It's the same bill, sent to a human.

Machine-native in the middle, human-native at the edges

There's a mirror image here worth being precise about, because it's easy to get tangled.

For a model, text is home turf. I've argued that at length: when a problem is really text wearing pixels, serialise it back into structured text, because models reason more sharply there — "Show the model a map, not a picture." That same work said "the image isn't the product" — about quote cards being judged by a model, where the words were the product and the picture was just a rendering of them.

For a person, the native medium is different — especially for experience. People think in terms of screens and tick boxes and checklists and text messages. That's what using something actually looks like to them. A paragraph describing a product is a translation of that experience into a medium the reader then has to translate back.

In Agent-Native Computing I put it this way: "native is a relationship between a thinker and a problem, and never a property of the thinker alone." The same logic applies at both ends. Design the middle of the system for the machine — structured text, maps, skeletons. Design the edges for the human — the things they can recognise. This book lives at the edge.

So there's no contradiction between "show the model a map, not a picture" and "show the person the moment, not a description". Each is the right representation for its reader. And as Chapter 4 will show, the demonstrations that work best for people still carry their words. They just put them somewhere the reader can see them working.

Where the tax shows up

Once you start looking for the reconstruction tax, it's everywhere AI output meets a person. Four places matter most, and each gets a chapter.

Before any of those, though, there's a fence to put up. The conclusion most people draw from everything in this chapter is "so, make it visual". That conclusion is half right, and the wrong half is expensive.

So, the obvious next move: make everything visual.

It's the conclusion almost everyone draws from the last chapter, and it's the conclusion I drew myself for a while. If people won't read, give them pictures. If prose charges a tax, draw diagrams. If a whiteboard beats a speech, put whiteboards everywhere.

Half of that is right. The other half is how organisations end up with pages of stock photography, reports with an icon next to every bullet, and infographics so dense they need their own summary. The research on this is unusually clear: the wrong picture is worse than none, and structure isn't automatically an improvement either. So before the rest of the book tells you what to show people, this chapter puts a fence around what "visual" is allowed to mean.

Decoration gets ignored

I've said for a while that if you put images on a web page, they're really hard to scan past and not look at. That's true — for a particular kind of image.

Nielsen Norman Group's eye-tracking work made the distinction sharply. People "pay attention to information-carrying images that show content that's relevant to the task at hand," and they "ignore purely decorative images that don't add real content to the page." Their summary line is blunter: users "ignore fluffy pictures used to 'jazz up' web pages."¹⁰

So my observation needs a qualifier I didn't have at first. Images are hard to scan past when they carry something the reader is looking for. Put in an image that carries nothing, and people learn — within a page or two — to skip it. The eye is ruthless about decoration.

Or worse than ignored

If decoration were merely ignored, it would be harmless padding. The learning research says it's often worse than that.

Richard Mayer's work on multimedia learning has tested this repeatedly. The coherence principle — "people learn more deeply from a multimedia message when extraneous material is excluded rather than included" — "was supported in 23 out of 23 experimental tests, yielding a median effect size of 0.86." In one study, students learned the same lesson with instructive graphics, decorative graphics or "seductive" graphics (interesting but irrelevant), and "the instructive group outperformed the seductive group (d = 1.13…) and the decorative group (d = 0.61) on a subsequent test."¹¹

The same chapter makes a point that should worry anyone designing for busy people: "extraneous material is most damaging when it is most likely to increase cognitive load beyond the learner's cognitive capacity."¹¹ In other words, decoration does the most harm exactly when your reader is already stretched — which, for someone skimming AI output between meetings, is all the time.

Structure isn't automatically a win either

It's tempting to conclude that the answer is structure: tables, grids, frameworks, anything but paragraphs. That's closer, but still not right.

Peter Cheng ran experiments using the same kind of pulley problems Larkin and Simon had analysed, giving people the information as a diagram, a table or sentences. The diagram won, sometimes dramatically: "Solutions with the diagrams were up to six times easier than informationally equivalent sentential representations." But the table didn't: "the tabular representation was not better overall than sentential representation."¹² And the diagram's biggest relative advantage was on the simplest problem — where it made a symmetry obvious that the other formats left buried.

That result is worth sitting with. A table is a format. It organises information into cells, which is sometimes exactly what's needed and sometimes just prose chopped into boxes. What made the diagram win wasn't that it was "structured". It was that its structure matched the structure of the problem, so the thing the solver needed to notice was sitting in plain sight.

Larkin and Simon, to their credit, said the same thing about their own title: "None of these points insure that an arbitrary diagram is worth 10,000 of any set of words. To be useful a diagram must be constructed to take advantage of these features."⁵ The "sometimes" in their title was doing real work.

The infographic trap

Put those findings together and you get a failure I see constantly in AI-generated material: a wall of text converted into a dense infographic. Every sentence of the original becomes an icon, a number, a coloured box. It looks like communication. It hasn't necessarily solved anything. The reader still has to work out which of the fourteen boxes matter and how they relate — the same reconstruction, now with colour.

The usability heuristics have a line for this: "Every extra unit of information in an interface competes with the relevant units of information and diminishes their relative visibility."⁷ An infographic that includes everything makes nothing visible.

Liking it isn't the same as getting it

There's one more trap here, and it's the one that makes the others hard to notice.

A 2026 study of 204 people compared text explanations of an AI's reasoning with graph-shaped ones. The graphs "do not help uniformly: they improve trust calibration for verbal reasoning yet feel more cognitively demanding and less satisfying; for visual reasoning, they impair calibration yet feel more engaging and helpful."¹³ Read that twice. Where the visual version helped, people found it harder and less satisfying. Where it hurt, they found it more engaging.

If you judged those formats by what people said they liked, you'd have picked wrong both times. That finding is important enough that Chapter 8 builds the book's whole approach to measurement around it. For now, hold on to the implication: you can't tell whether a visual is meaning or decoration by whether people enjoy it.

What whiteboard lines are really doing

If decoration hurts and generic structure doesn't reliably help, what's the whiteboard from Chapter 2 doing right?

Mayer's research has a name for it. The signalling principle says "people learn more deeply from a multimedia message when cues are added that highlight the organization of the essential material" — supported "in 24 out of 28 experimental tests."¹¹ The arrows, the boxes around related ideas, the dotted line marked "trade-off", the circle around the open question — those aren't decoration. They're signals about organisation. They're why a hand-drawn board with a dozen words on it can carry an hour of argument, and a polished slide with fifty can carry nothing.

The arrangement question

So here's the fence. Before anything is made visual, ask one question:

What arrangement makes the relationship or choice easiest to inspect?

Not "should this be a picture?" Not "can we add a diagram?" The question is what the reader is trying to do, and what arrangement would put the thing they need to notice in plain sight. Here's how that plays out for five common reader tasks.

Take the first row. Three vendor options described in three paragraphs force the reader to hold option one's cost in mind while reading option three's risk. The same three options in columns, with cost, risk, lock-in and effort as rows, let them compare by looking across a line. Nothing was added. The information was placed.

The second row: a governance process described as "proposals are raised by the product team and reviewed by risk, with final approval resting with the steering group unless the change is minor" makes the reader build an org chart from clauses. A small map — three boxes, two arrows, one exception marked — shows it.

The third row: a process written as narrative hides where things can go wrong. Steps with the state at each ("submitted", "waiting on finance", "approved") show where it stalls.

The fourth row is the subject of the next chapter.

And the last row matters as much as the others, because it keeps this book honest. For argument, qualification, careful definition, legal wording or a single correct answer, a well-made paragraph is the right arrangement. Prose doesn't disappear under anything in this book. It becomes the depth behind whatever the reader meets first — a structure Chapter 6 makes explicit. Sometimes the answer will still be one excellent sentence.

Meaning includes access

One last point of lineage. When I wrote about publishing in an attention-scarce world, I was careful to say that the argument "does not argue that short content is inherently superior. That claim is lazy and usually false." The visual version of that laziness is decoration. Decoration is the visual equivalent of padding: it takes up the reader's attention and gives nothing back.

The test for any visual is the same as the test for any sentence. What work does it save the reader? For relationships, the answer is usually a diagram. For choices, a comparison. For argument, prose. And for the thing most AI output is actually trying to convey — what something is like to use, what a service actually does for someone — the answer has a name.

Demonstrate over tell.

That's the name. It's four words long, which matters, because it's short enough for a person to remember and a model to act on. In the website trials you'll meet in Chapter 9, those four words were the nudge that changed the output of every model we tried. This chapter is about what the words mean precisely — because the precise version is not quite the one most people hear.

Most people hear "use visuals". The demonstration that works is something slightly different, and the difference is the whole point: it's words placed inside a recognisable situation, where they show something happening.

The principle

I got there by a ladder, and it's worth showing the rungs, because most organisations are standing on one of the lower ones and think they're at the top.

The first three rungs are all still telling. A benefit statement — "save hours every week" — is an assertion the reader has to take on trust and then imagine. Fewer words is the same assertion, shorter. An image of a smiling person next to the assertion is decoration, as Chapter 3 showed. Only the fourth rung changes what the reader is being asked to do. Instead of imagining the product from claims about it, they watch a moment of it and complete the rest themselves.

Don't make the customer construct an imaginary product from your description. Let them see a useful moment of it happening.

Words inside a situation

Here's the detail that makes the principle precise. The demonstrations that work are not wordless. A message thread is words. A filled-in form is words. A marked-up document is words. What changes is that the words are arranged as an event the reader can watch, instead of as claims the reader has to believe.

That's why a demonstration can carry specifics a picture alone never could — a name, a time, an amount, a result. It's also why "demonstrate over tell" isn't in tension with anything Chapter 2 said about text being the model's home turf. The words are still doing the work. They're just doing it where the reader can see them working.

Look at what the right-hand version does that the left can't. It shows that the firm actually reads your transactions (the query about $412). It shows what "on time" means (a date). It shows the reader the one thing they'll be asked to do. None of that is asserted. It's all just there.

The miniature worked example

There's a name for the kind of demonstration that works best on a page, and it's worth having, because it tells you what to aim for.

The term borrows from education research, where the evidence is strong. The "worked example effect" is "the widely replicated finding that novice learners who are given worked examples to study perform better on subsequent tests than learners who are required to solve the equivalent problems themselves" — and a meta-analysis put the effect size at 0.52. The explanation is the reconstruction tax in teachers' language: "unguided problem-solving places a heavy burden on working memory."¹⁴

A first-time visitor to a company's homepage is a novice in exactly this sense. So is an executive seeing a new process for the first time, or a customer trying to work out what a service does. Give them a worked example and they don't have to solve the puzzle of what you're offering. They watch it solved.

The same research carries a warning that matters later in this book. The effect fades with expertise: "the heavy use of worked examples becomes less and less effective as learners' expertise increases, eventually becoming redundant or even counter-productive."¹⁴ Someone who already knows the product doesn't need the demonstration; someone who was in the meeting doesn't need the whole meeting explained. Chapter 6 turns that into a design rule for summaries.

The usability world said the web version of this more than twenty years ago. From Nielsen's homepage guidelines: "Don't just describe what lies beneath the homepage. Specifics beat abstractions, and you have good stuff. Show some of your best or most recent content." And on images: "it's almost always best to show photos of real people actually connected to the topic, rather than pictures of models."¹⁵ Specifics beat abstractions. A demonstration is a specific.

Where this sits in what I've written before

Two earlier pieces of mine come at this from other angles, and it's worth saying how they connect rather than re-arguing them.

In Specimen, Not Prescription I wrote about opening a sales conversation with a fifteen-second silent video of a before-and-after, followed by a short working product. "There is no voiceover to argue with. There is only a before-and-after the room can complete in their own language." And: "The video creates recognition. The app creates belief." Demonstrate over tell is that move carried inside a single page — the reader completes the demonstration in their own language, and nobody has to argue with a claim.

And in The Three Parts, defining what a minimum viable company should show, I included "an example of what a customer would receive", because "a site can tell you what is promised. The sample lets you judge what that promise amounts to." That definition matters in Chapter 9, where those companies' websites are the whole story.

A family of seven moves

"Demonstrate" is one move. When I was working through why some agent-built pages were so much better than others, I noticed it wasn't the only one. Being visual over text is a complex thing, and demonstrate over tell is probably just one part of it. There are other angles.

The most useful way to organise them turned out not to be by visual style — photos, diagrams, tables — but by the work each one saves the reader. Every move below answers a question the reader would otherwise have to answer by reconstruction.

Treat these as candidate moves to try, not a checklist to impose on every page. Most outputs need one or two. Here's each in a little more detail — what it looks like, and when it's the wrong move.

1. Show it happening

The representative exchange. A plumbing business doesn't say "fast, transparent quotes". It shows the thread: a photo of a leaking tap from the customer, a reply with a fixed price and two time slots, a thumbs-up, a confirmation with the plumber's name. The visitor has watched the service work in four lines. Wrong move when there is no moment a customer ever sees — pure infrastructure, say. Then the right move is usually number 3: show how the parts connect.

2. Make the difference visible

The same situation, before and after, with the difference that matters exposed. A weekly report that used to be twelve bullets of activity becomes "three things changed since last week", each with an arrow from where it was to where it is. The reader doesn't have to diff two versions in their head; the diff is the content. Wrong move when the "before" is a straw man. If nobody's current process actually looks like your before, the comparison insults the reader instead of informing them.

3. Show how the parts connect

A responsibility map, a dependency diagram, a short sequence. This is the move for governance, architecture, approvals and handovers — anything where the reader's real question is "who does what, and what depends on what?" Chapter 9 has a governance page that went from paragraphs to a responsibility diagram and became readable at a glance. Wrong move when the relationships are simple enough for one sentence. "Finance approves anything over $10,000" doesn't need a diagram.

4. Start in their world

Open with an artefact the reader already handles: their invoice, their roster, their inbox, the form they fill in every month. A payroll service shows a rostered week with the weekend penalty rates already calculated and one line flagged for review — something a small-business owner recognises instantly as their own Tuesday-night job. The recognition is the hook. Wrong move when the "familiar" artefact is a stock one nobody in the audience actually uses — a generic spreadsheet is not anyone's world.

5. Make the alternatives comparable

Options side by side, organised around the same distinctions: three vendors in columns, with cost, lock-in, effort and what breaks first as rows. The reader compares by looking across a line. This is the move behind my standing request to agents for a web page instead of a wall of text when there are options to discuss. Wrong move when the options genuinely differ on dimensions that don't line up. Forcing incomparable things into a grid manufactures a false precision; say they're different in kind.

6. Give me something to react to

A concrete proposal with handles — accept this part, change that part, reject this with a reason. This is the move that turns communication from a broadcast into an exchange, and it works in a direction most systems forget: from the human back to the machine. It's the whole of the next chapter.

7. Let me inspect the claim

A compact view that opens into the example, the evidence or the fuller explanation behind it. The reader gets the claim at a glance, and the route to check it is one step away. It's the move that makes every other move honest, and it's the architecture of Chapter 6.

Behind all seven is one working question, and it's the question I'd want every AI system that produces output for people to ask before it writes a word:

Where are we making the reader do unnecessary interpretive work — and what representation would remove it?

Sometimes, as Chapter 3 said, the honest answer is a well-made paragraph. Often it's one of the seven.

The honesty rule

Demonstrations are powerful because readers complete them. That's also what makes them dangerous. A demonstration can imply things that aren't true — that the service already works this smoothly, that the feature exists, that the result is typical — without ever stating them. So the move comes with a rule.

Microsoft's guidelines for human–AI interaction draw exactly this line. "Guideline 1: Make clear what the system can do." And separately: "Guideline 2: Make clear how well the system can do what it can do."¹⁶ A demonstration answers the first. It says nothing about the second. In The Three Parts I put the same warning another way: "A demonstration is valuable on its own terms. Trouble begins when its appearance is allowed to imply the other states" — the states being idea, demonstration, working foundation and customer-tested operation.

Three practical consequences:

1. Make illustrative examples recognisable as examples

   Label them. Every mock-up in this book carries an "Illustrative" tag for exactly this reason. Readers don't mind being shown an example; they mind finding out later that an example was dressed up as a record.

2. Never demonstrate what isn't there

   If the service can't yet send the confirmation text, don't show one. A demonstration of a feature that doesn't exist is a misrepresentation with good typography.

3. When the claim matters, give it a route to evidence

   Pair the demonstration with move 7: the compact view opens into the proof — the case, the data, the terms. Explanation up front; substantiation one step behind.

Move 6 is the one that doesn't stop at the reader. It asks something back — and in most AI systems, the way it asks is the worst part of the whole experience.

Sooner or later, every AI system asks a person "why?"

Why didn't you like that draft? What should change? What did you mean? It's a reasonable question, and almost every system asks it the same way: an empty text box, a blinking cursor, and perhaps a thumbs-down icon that captures nothing at all.

Look at what that box asks of a person who has just said no. They had a reaction — something felt off. Now they have to turn that reaction into an explanation, from nothing, on the spot, in words the machine will understand. That's a composition task. It's recall, with no cues. It's the reconstruction tax again, charged on the way back instead of on the way out.

Most people don't pay it. They type "not quite right", or "make it better", or nothing. The system learns nothing, the next attempt misses the same way, and everyone concludes the AI "doesn't get it". Often the AI never had a chance. The reply channel was designed to fail.

From recall to recognition, on the way back

Chapter 2 made the case that recognition is cheap and recall is expensive. The same logic applies to the reply. An open "why?" is a recall task. A set of offered reasons turns it into recognition.

This is old wisdom in interface design. "A menu system is the most classic example of a recognition-based user interface: the computer shows you the available commands, and you recognize the one you want." And the same research on search suggestions: they "partly transform the query-generation task from one of recall to one of recognition."⁶

In Look Mum No Hands, writing about AI proposals that people approve or reject, I said "Rejection isn't failure—it's feedback… When a user rejects a proposal, capture why." I still think that's right. What I've learned since is how to capture why: don't ask the person to write it. Have the machine prepare the candidate whys, and let the person recognise theirs.

Assisted articulation

There's something slightly more going on than a menu, and it's worth naming precisely.

A traditional menu lists fixed commands; everyone sees the same options. Assisted articulation generates the options for the thing that was just rejected. Shown an image of an empty office for a cleaning company, the candidate reasons might be "no people in it", "doesn't show the actual cleaning", "feels like a real-estate listing". Shown a draft email, they might be "too formal for this client", "buries the ask", "sounds defensive". The machine is proposing possible meanings of the person's "no" — and the person, who couldn't have written any of them from scratch in five seconds, can often recognise one immediately.

That's the part I'd underline. The benefit isn't only speed. The machine is helping a human say something they might otherwise struggle to express. It's articulation, assisted.

There's research behind this in an unexpected place: recommender systems. Researchers have long studied "critiquing" interfaces, where people give feedback on recommended items — and one branch of that work has the system suggest the critiques. In one 44-person study, users "more frequently picked suggested critiques in the second system, and significantly saved their task time and interaction effort." The same survey notes that suggested critiques "can perform as explanations and help users be familiar with the product domain" — and that users "can be then stimulated to express more preferences."¹⁷

That last line is the articulation part. Suggestions didn't just save effort; they drew out preferences people wouldn't otherwise have expressed. In The Three Parts I made a related point about any kind of offer: "Record attraction and objection separately. A broad yes or no discards information." A thumbs-down is a broad no. A picked reason is information.

The escape hatch

The same research contains the warning that makes this safe to use. Suggested critiques aren't always right. The best prediction accuracy the survey reports is 66.9%, which means "the critique suggestions are unable to precisely match to users' intended criteria all the time. In the failure situations, because users have no chance to build critiques on their own, they would have to take more effort."¹⁷

Read that carefully. When the suggestions miss and there's no way out, the menu costs more than the empty box would have. A menu that can't be escaped doesn't assist articulation; it replaces it. The person picks the nearest wrong reason, the system learns something false, and the next attempt misses in a new direction.

Each hatch does a different job. "Several at once" stops the menu forcing a single cause onto a mixed reaction. "None of these" tells the system its candidates were wrong — valuable in itself. "Not sure yet" is an honest answer that shouldn't be converted into a guess. "My own words" is the path for the reason nobody anticipated, and it's where the best new candidate reasons come from next time.

What to do with a "no"

Two rules about what happens after the pick.

A picked reason is evidence about this moment, not a permanent preference. Someone who rejects an image as "too formal" for one page may want exactly that formality on another. Don't promote a single situational rejection into a rule about the person. Structured feedback isn't automatically better data for training a system, either; one study of fine-grained feedback on generated images found it "can lead to worse models for a fixed budget, in some settings."¹⁸ The human-side benefit — helping someone say what they mean — is the one this chapter is about. What you do with the data afterwards needs its own care.

Feed it back at the right layer. Different reasons mean different fixes. The routing I described in Look Mum No Hands still holds, and a reason menu makes it almost automatic, because each generated reason can carry its layer with it:

This is also where design guidance and this chapter meet. Microsoft's human–AI interaction guidelines include "Guideline 9: Support efficient correction. Make it easy to edit, refine, or recover when the AI system is wrong" and "Guideline 15: Encourage granular feedback. Enable the user to provide feedback indicating their preferences during regular interaction with the AI system."¹⁶ A reason menu with an escape hatch is one of the cheapest ways I know to do both.

The shared object

Step back from the rejection menu and something bigger comes into view. Once a person can react to parts of an output — not just the whole — the output stops being a message and starts being an object. A diagram is no longer the illustration accompanying the answer. It becomes the thing the conversation is about.

And that changes what people can say. Here are three sentences that are nearly impossible to say about a paragraph and completely natural to say about something visible:

• "That part is right."
• "Not that relationship."
• "Keep this, but change those two things."

Each of them points. Pointing is cheap — much cheaper than describing. In Specimen, Not Prescription I put it this way: "Adversarial contact with a concrete object is higher-resolution than polite agreement with a vague sentence." A person who can point at the wrong part of a diagram tells you more in three seconds than a person trying to describe what's wrong with a paragraph tells you in three minutes.

The research on this comes from studies of people working together on physical tasks, and the numbers are striking. Darren Gergle, Robert Kraut and Susan Fussell had pairs complete puzzles, sometimes with a shared view of the work area and sometimes without. With an immediate shared view, "the pairs were approximately 30% faster." The mechanism is the pointing: with a shared view, people could say "the one on the left" instead of "the piece with the red stripe on the left and the white box in the lower right corner with a green stripe running through it."¹⁹

The same study found something just as important about timing. "A 3-s delay in updating the shared visual information considerably reduced its benefits." With the delay, pairs were "only 7% faster" than with no shared view at all.¹⁹

Those were human pairs doing jigsaw-style puzzles, not people working with an AI, so they support the mechanism rather than any particular AI interface. But the mechanism is exactly the one that matters: a shared object makes reference cheap, and the object has to be live for that to work. It's why, when I built a shared canvas for working with AI, I built it on a fast–slow split — a quick agent that keeps the conversation moving and a slower one that does the digging. The part that talks doesn't need to think, and the part that thinks doesn't need to talk fast; the design "decoupled the latency of turn-taking from the latency of actual cognition." On a canvas, that means the object stays live while the thinking happens.

Four rules for a shared object

1. Keep it still long enough to inspect, challenge and change it

   If the whole object regenerates every time one part changes, the person has to re-read everything to find what moved. That's the reconstruction tax, reintroduced by the interface.

2. Show what changed

   When the slow agent adds or revises something, mark it — a highlight, a small "updated" tag. A diff you can see is cheaper than a diff you have to compute.

3. Give every part an identity under the pixels

   Store object identities and structured relationships beneath the visual, so that a click or "that one" means exactly the same thing to the person and to the machine. The AI shouldn't have to infer from pixels what the human pointed at.

4. Put handles on the parts

   Accept, change, reject-with-reason — at the level of a part, not just the whole. In Look Mum No Hands the shared surface between human and AI included "Feedback Handles — Where to correct when wrong." On a shared object, the handles live on the parts.

Depth by moment, not by person

One last thing the canvas taught me, and it's about the reader rather than the object.

It's tempting to sort people into types. Chris is a skimmer; he doesn't read past twenty words. I'm someone who'll listen to twenty minutes of detailed AI explanation. Design for each type, and everyone's happy.

Except that I'm also the person who can't stand a wall of text on a busy afternoon, and Chris reads plenty when something's worth it. The same person wants a glance in one moment and immersion in the next. So the right design principle offers different depths for different moments, rather than classifying someone permanently as a reader or a non-reader.

Making those three depths available for things that aren't live — the summary someone opens next week, the report someone reads on the train — is an architecture problem, and it's the next chapter.

Every team makes the same three requests of its AI, usually in this order.

"Can you summarise that?" The transcript of an hour-long meeting becomes a page. The page is still too long, so: "Shorter?" It becomes a paragraph. Nobody acts on the paragraph, so: "Just the actions?" It becomes five bullet points, each beginning with a verb.

Now ask two questions about what's left. First: what happened in that meeting? Not what was decided — what happened. Who argued for what, what changed someone's mind, which objection got parked rather than answered. Second: if you needed to know, could you get back to it?

For most organisations the honest answers are "we don't know any more" and "not easily". The recording may exist somewhere, but nothing in the five bullet points leads to it. The summary chain didn't just compress the meeting. It cut the route back.

Compression isn't the enemy

I want to be careful here, because it's easy to overshoot. My own first reaction to Chris's request for more summarising was blunt: summarising it in increasing levels just means you've lost anything that was useful there. That's true of the chain. But the precise version is more useful than the blunt one.

Compression itself is not the enemy. A diagram is selective too; so is a whiteboard; so is every good title. You'll compress. The problem is losing the route back, or allowing the compressed view to become the only surviving account. A short view with a way back to the source is one of the most useful things you can give a busy person. A short view that has replaced the source is how organisations forget on purpose.

So the design question isn't "should we summarise?" It's "when someone reads the short version and needs more, can they get it — in one step?"

Why the chain fails

I've written about the mechanics of this before, in Your Company Speaks Five Languages, about how a project's story degrades as it passes from technical team to project manager to marketing to sales. "Humans must compress. The failure is not compression itself. It is which axes survive — and what happens when the next hop re-compresses the wreckage." Each hop keeps what matters for its own job and loses what the next reader needed, and "Later hops often polish the wreckage into prettier language. Prettier is not more faithful."

The fix there was a change of topology. Instead of a chain, where each version is made from the previous version, make every version directly from the preserved source, so that "nobody is ever more than one hop from the truth."

That book applied the idea across audiences. The same topology applies across formats. A meeting doesn't have to become summary, then shorter summary, then actions. It can become a drawn board, a set of exact quotes, links into the audio, and a list of commitments — each made from the recording, none made from another.

The rule

The depth is everything that was said and shown — preserved and addressable. The doorway is what a person meets first. Most teams do the reverse of this rule: they change the depth (by summarising it away) and keep the doorway (a block of text). The recording gets deleted to save space; the paragraph at the top of the page stays exactly as unreadable as it always was.

What a doorway is made of

A good doorway has four parts. Each has a job, and each is there because of something earlier in this book.

1. One recognisable object per subject

   The drawn shape of that part of the discussion — the options, the trade-off, the owner, the open question. One per subject, not one per meeting, because subjects are what people come back for. Nobody searches for "the Tuesday meeting"; they search for "what did we decide about pricing".

2. A few exact quotes

   Verbatim, attributed and timestamped, and chosen for disagreement, decision and commitment rather than for eloquence. Quotes carry what a drawing can't: who said it, and how strongly. "I'm not signing off on per-seat pricing until finance has seen the churn numbers" does work that no arrow can.

3. The open questions, marked

   Circled on the board or listed under it. A summary that shows only conclusions lies by omission; the open question is often the most important thing on the page.

4. Routes back

   Each quote opens in its transcript context. Each subject links to the audio at the moment it started. The full recording and the original artefacts — whiteboard photos, documents shown — are kept.

What the doorway deliberately leaves out is the paragraph that usually sits at the top of a summary: "The team discussed pricing options and agreed to proceed with further analysis." That sentence charges the full reconstruction tax and preserves none of the fidelity. It's the part everyone skims and nobody trusts.

The established name for this

Interface designers have a name for keeping depth behind a small first view: progressive disclosure. Jakob Nielsen's formulation is as good as any: "Initially, show users only a few of the most important options. Offer a larger set of specialized options upon request." And it "improves 3 of usability's 5 components: learnability, efficiency of use, and error rate."²⁰ Journalism has an older one — the inverted pyramid, written so that "readers can stop reading at any point on the page and still come away with the main point."²¹

In Look Mum No Hands I described three layers for AI proposals — a first layer of about five seconds to scan, a second of about thirty seconds, and a third "as long as needed" — with one non-negotiable rule: "Progressive disclosure requires that Layer 3 exists. You can hide it, but not remove it." Those three layers are the glance, inspect and immerse of Chapter 5. The doorway is Layer 1 for anything that summarises. The summary chain is what happens when someone removes Layer 3 to make Layer 1 shorter.

People reach for the route back

The best external evidence I've found comes from Microsoft researchers who built and evaluated an AI meeting-recap system. Their starting observation will sound familiar: "fixed-length summaries often fail to meet diverse needs, such as quick overviews or detailed insights." And then the finding: "Better context improves meeting recall. All participants used the ability to expand the 'context' of a summary into the original dialog… Many participants also requested deep links to video recordings to review the discussion quickly."²² One participant put it simply: "If there was a way to link to the meeting for each of these notes, I could watch the relevant parts of the video based on the notes."

It was a small qualitative study — seven participants inside Microsoft — so treat it as a signal, not a measurement. But look at what the people reached for, unprompted. Not a better summary. The route back.

The same paper cites earlier research with a warning worth keeping: people who skimmed meeting transcripts ended up "missing the high-level picture of meetings while being overconfident in their recall."²² Confidence and understanding come apart — a theme Chapter 8 takes up properly. And it offers a principle that could stand for this whole book: "the most useful representation of the summary will be the one that matches the structure of the task that the participants hope to achieve from the recap." That's the arrangement question from Chapter 3, arrived at independently.

Recovery and teaching are different jobs

There's a subtlety in how a doorway works, and it decides who a doorway is for.

For someone who was in the room, a drawn board works as a cue. They already have the hour — the examples, the objections, the changes of direction. The board gives them a shape they recognise, and the recognition brings the rest back into reach. That's the mechanism of The Recognition Loop: a small cue, and then the person's own memory does the work. "We are trying to hand the rememberer a key while they are still standing at the door."

For someone who wasn't there, the same board is a set of boxes and arrows. They have nothing to recover. Remember the expertise-reversal effect from Chapter 4: worked examples matter most to novices and least to experts. It applies directly here. The participant is the expert in that meeting; the newcomer is the novice, and the newcomer needs more of the worked example — quotes that state the decision in words, a short "decided / still open" caption, the audio doing more of the work.

The picture can be a key to the conversation without being a replacement for the conversation.

That's exactly why the depth has to stay. A doorway designed for recovery will fail a newcomer unless the route to the source is right there. Chapter 10 shows what that looks like in a real meeting archive, including the moment a single image brought an hour back for the two people who'd been in it.

To-dos are a different product

Back to Chris's to-do list, because it's the end of the chain and the part most organisations defend hardest.

I know people don't follow the to-dos. Here's why, I think. An extracted task list is not yet an agreed commitment. When an AI extracts actions from a transcript, it finds sentences shaped like tasks — "we should look at the churn numbers", "someone needs to talk to legal" — not agreements. Nobody said "yes, I'll do that by Friday". So nobody owns it, and nobody does it. The list looks like accountability and functions as a record of good intentions.

The fix is to separate the two products. Keep the meeting's knowledge in the doorway, navigable. Put commitments in their own view: only the work someone actually accepted, each with an owner, a completion condition and a review point, and each linked to the moment in the recording where it was agreed.

Originals are the source

One more thing belongs in the depth, and it's easy to lose. Many meetings produce physical artefacts — a whiteboard someone photographed, a sketch on paper. When an AI generates a clean board from the transcript, it's tempting to treat the clean version as the record. Keep the photographed board as the source; keep the cleaner board as an interpretation people can check. The original may carry crossings-out, groupings and arrows that never made it into anything anyone said aloud.

That's a small case of a rule I've argued for at the scale of whole archives in Keep the Bronze: keep the raw layer, immutable and cold, and build the useful views on top, because "deletion is the only irreversible operation in the whole stack." The doorway can be regenerated any time from the recording and the originals. The recording can't be regenerated from the doorway.

Beyond meetings

Meetings are the clearest case, but every AI summary is a doorway decision.

• Research digests — the digest is the doorway; the papers stay one click from each claim.
• Customer-call notes — Gong, which sells conversation capture and so has an interest in the point, reports that "an average sales call generates about 6,000 words of conversation, but only 30 to 60 words typically make it into the CRM."²³ Whatever the exact ratio, the note is a doorway with no door.
• Status reports — the doorway is what changed and what needs a decision; the detail sits behind it (Chapter 12 rebuilds one).
• Briefing packs — the ask and the options up front; the evidence one step behind.

In every case the test is the same: can the reader get from the short version to the source in one step, and is the source still there?

Everything so far has been about what people are handed — out, back, and kept. The last doctrine question is about the other reader in the system. How do you get a machine to produce any of this, without writing it a rulebook it will follow straight into a worse result?

The agent's output disappoints, and you do what everyone does. You add instructions.

Specify the sections. Specify the order. Rounded cards, image on the right, these three brand colours, a headline under eight words, a list of things never to do. The prompt passes a page, then two. The output becomes more obedient. It rarely becomes better, and fairly often it gets worse — tidier, more uniform, and duller than what you had before you started.

That's the question Chapter 6 ended on: how do you get a machine to produce the things this book has been describing, without writing it a rulebook it will follow straight into a worse result? My answer has three parts, and none of them is "more rules".

One qualification first. This is about communication work — output whose job is that a person understands something. If the output feeds another machine and must match a schema exactly, prescribe the schema. I'll come back to where that line sits. For everything whose target is "the reader gets it", the reflex is backwards.

Aim: name the move, not the layout

Why would four words beat a page? Because they're doing a different job. Prompt quality isn't prompt quantity. A move-nudge changes the kind of solution the model goes looking for. "Demonstrate over tell" sends it hunting for a moment it can show. A layout prescription — rounded cards, image right, five sections — specifies an implementation before the model has found the communication idea, and caps the result at the quality of whoever wrote the specification. If the specifier isn't a designer, that cap is low. I'm not a designer. That's precisely why I stopped writing layouts into prompts.

In Chapter 9 you'll see this happen in the wild: across the agent-built websites, the over-prescriptive prompts produced worse pages, and four words of move-nudge changed the output of every model we tried. Here's the doctrine that result supports.

I like to do everything by nudge. I've written about nudges before in a different setting — retrieval signals in a knowledge system — where I defined one as "a small, frequent, advisory prior fed to exactly one judgment layer," one that "biases a choice without forbidding any option or forcing one." That book was about search, not prompting, but the stance carries over. A move-nudge tilts the model toward a kind of answer. The model stays the judge of how.

The model-makers are saying the same thing

This is also the core of what I called The North Star Prompt: "Tight intent, loose method." Most bad prompts, I wrote, "get this backwards: vague on purpose, suffocating on procedure." And the diagnosis of why people over-prompt: "dictating the creative parts because dictating feels safer, when it's what's holding the quality down." The field notes in that book include a cheap model that got better the moment I stopped instructing it: "The less prescriptive run, on medium, is pure gold compared to what we had before."

What this book adds is specific. For communication work, the one sharp sentence of intent should name the move the reader needs. Not "make it great". Not "make it visual". The move.

The companies that build these models are converging on the same advice from their side.

Look at where "demonstrate over tell" sits against that last piece of advice. It isn't a hex code, and it isn't "make it nice". It names a kind of move, precisely enough to act on and loosely enough to leave the model room. It's also a positive instruction — do this — rather than a list of don'ts. That's the altitude.

There's also a measured result from a quite different field that points the same way. Researchers running long AI discovery searches found that "explicit directional guidance consistently underperforms its unguided counterpart," because strong guidance "tends to over-constrain the search space and impede diverse exploration."²⁷ That was algorithm discovery, not design, and I've discussed it more carefully in The Exemplar Ratchet. But the shape is familiar: tell a capable searcher too precisely where to look, and it looks in fewer places.

Wording steers — both ways

One report from inside Anthropic shows both the power and the danger of a few well-chosen words. Prithvi Rajasekaran, building a harness that generates and evaluates frontend designs, found that "the wording of the criteria steered the generator in ways I didn't fully anticipate. Including phrases like 'the best designs are museum quality' pushed designs toward a particular visual convergence."²⁸

Read that two ways. First: a few words moved every output. That's exactly why a move-nudge works — you don't need a page to steer a capable model. Second: a few words collapsed the variety. Everything drifted toward one look. That's the danger, and it has a name later in this chapter. The difference between the two outcomes is what the words point at. "Museum quality" names how the output should look. "Demonstrate over tell" names what the reader should be able to do. Aim at the reader's need, not at an aesthetic.

Eyes: let it see what it made

The second part is simpler to state and easier to neglect. An agent that can't look at its output the way a reader will is communicating blind. It can verify its HTML is valid. It can't verify the experience.

I put this more vividly a year ago, writing about giving agents tools: "The problem: The agent never saw what it built. It's like asking a blind person to paint a portrait. They can follow instructions ('use red here, blue there'), but they can't see if the result actually looks right." Give it eyes, and "The agent becomes a designer, not just a coder."

An agent that can't see its page is painting blind — it can follow instructions, but it can't tell whether the result communicates.

Anthropic's own engineering reports make the same point with evidence. Giving Claude browser-testing tools "dramatically improved performance, as the agent was able to identify and fix bugs that weren't obvious from the code alone." And the limitation that proves the rule: "Claude can't see browser-native alert modals through the Puppeteer MCP, and features relying on these modals tended to be buggier as a result."²⁹ What the agent couldn't see, it got wrong. In the design work, the evaluator was given a browser so it could navigate "the page on its own, screenshotting and carefully studying the implementation before producing its assessment."²⁸

In The Skeleton of a Visual I described why rendering and screenshotting beats generating a picture directly, even when the picture is slightly prettier: you own what you rendered, so you can check it. The screenshot path "closes the loop — generate, flatten, verify." Some checks are mechanical — did every word survive, is anything clipped or overlapping, is the contrast readable. Some are judgement — does this communicate? Eyes are what make the second kind possible at all.

Canvas: let it compose what it imagines

The third part is about expression. A model can have the right idea and still be unable to realise it, because the tools around it only allow one kind of output — a 16:9 image, a stack of text blocks, a fixed template.

Eyes and canvas are the two halves of the same fix. Screenshots improve what the agent can inspect; composition tooling improves what it can express. Chapter 9 has a small, concrete example of both: one harness that couldn't take screenshots until it was fixed, and a wide 2.4:1 image the tooling had to be extended to produce.

The harness matters exactly where it limits seeing or expressing

Put aim, eyes and canvas together and you get a rule about agent harnesses that I've found more useful than either of the usual positions.

One camp says the harness — the scaffolding of tools, loops and context around the model — is everything. The other says it barely matters; the model does the work. For communication work, the evidence I have points somewhere more specific. Harness differences matter exactly where they limit what the agent can see or express. Once every harness can screenshot and compose, the model and the direction it's given dominate the result.

That has a practical consequence. Don't choose a harness on its feature list. Check that it gives the model eyes and a canvas. Then spend your effort on the aim.

The template trap

Now the danger the "museum quality" story warned about.

When a nudge works, it tends to work everywhere at once. In Chapter 9 you'll see "demonstrate over tell" produce the same expression across every model: a thread of text messages laid over a photograph. That was the right expression for the site where it first appeared. If it becomes the expression for every site, the discovery has turned into the next boring template.

The family resemblance should be visible value, not identical chat bubbles.

The same goes for the canvas. Enabling a wide 2.4:1 image was valuable. Making that ratio compulsory would be a different decision entirely — one more rule that caps the result at someone's first good idea.

The sharpest test I know for telling a principle from a template comes from Generative Design Patterns, where the bar for a reusable pattern is "Short enough for a human to carry; precise enough for an AI to regenerate." The regenerate test asks whether "an agent, given only the card plus a local domain sketch, [can] produce something a third party recognises as a family member." And a warning worth pinning above any prompt library: "Length is not compression. Completeness is not generativity." A good move-nudge passes: given a new company, it regenerates something recognisably in the family and fitted to that company. A layout template fails: it produces a clone.

Where to stay prescriptive

None of this means never specifying anything. In The North Star Prompt I drew the line at outputs that feed a machine and must match a schema, tasks with a single correct answer, and constraints that are safety- or correctness-critical. For communication work, the must-be-exactly parts look like this:

A practical pattern from the same book: let the model compose freely in one pass, then check the must-be-exactly parts mechanically in a second. The first pass gets the benefit of the model's judgement; the second makes sure the facts survived it.

A preview of the nudge card

Chapter 13 gives builders the full kit. Here's the shape of it — the seven moves from Chapter 4, rewritten as one-line nudges.

And then you have to find out whether it worked. That turns out to be harder than it sounds, because what people like and what they understand come apart — and so does what a model thinks of its own work.

Here is the finding that should unsettle anyone who judges communication by how it feels.

Chapter 3 mentioned a 2026 study in which 204 people were shown AI reasoning either as text or as a graph. The headline, in the researchers' own words: "In each modality, the format that better supports calibrated decisions is not the one users prefer."¹³ In both kinds of task they tested, people liked one format and made better-judged decisions with the other.

Sit with what that implies. If you had run that study the way most organisations evaluate their AI output — a satisfaction survey, a thumbs-up count, a "which do you prefer?" — you would have chosen the worse format both times, confidently, with data to back you.

That's the problem this chapter solves. Everything else in this book produces outputs that feel better to receive. Some of them will actually be better, and some won't. You can't tell which by asking people how they feel.

Three sources of false confidence

The preference trap isn't the only one. There are three, and they reinforce each other.

People prefer what helps them less — at least some of the time, as the study above shows.

Machines flatter their own work. Anthropic's engineers, building a harness to generate and review designs, noticed it directly: "When asked to evaluate work they've produced, agents tend to respond by confidently praising the work—even when, to a human observer, the quality is obviously mediocre."²⁸ If the same model that made the output also grades it, you've learned mostly what the model thinks of itself.

Readers over-rate their own understanding. The meeting research in Chapter 6 found people who skimmed transcripts "missing the high-level picture of meetings while being overconfident in their recall." Skimmers don't feel like they missed things. That's what makes skimming feel efficient.

Three sources, one pattern. The feeling of having understood is cheap and plentiful. It is not the thing.

What a fixed judge is for

There's a useful instrument that often gets mistaken for a measure of understanding: the fixed judge. You hold a reviewer steady — a panel of people with a scoring guide, or an AI model with a frozen rubric — and run variants past it. Because the judge doesn't change, the scores let you compare the variants against each other. Version B beat version A on the judge's criteria.

That's genuinely valuable. It's how you find out which of twelve prompts produces better pages, or whether a change made things worse. The website trials in Chapter 9 used exactly this kind of judge, and it's how the most important findings in this book surfaced.

But a judge's score is not evidence that a reader understood anything. It tells you what the judge rewards. If the judge is a model, it tells you what a model rewards. The step from "the judge preferred B" to "customers understand B better" is an inference, and it's the inference the preference research warns about. So the rule is simple:

The comprehension test

Here's a test you can run next week, on any output, with a handful of people. It has three measures. For each one: what you show, what you ask, and what counts.

A few notes on each, because the details decide whether the test tells you anything.

Time to a correct explanation

Write the answer key first — one line stating what a reader should understand from this output. If you can't write that line, the output has a bigger problem than its format. Then don't explain anything before you ask; the point is what the output communicated, not what you did. Accept the reader's own words. You're checking the understanding, not the vocabulary. Compare two versions of the same content with different readers, so nobody sees both.

Corrections that improve the result

This measure is the reply channel from Chapter 5, tested. A good output makes it easy to say where it's wrong. Count the corrections that would genuinely improve it — not every quibble. And watch the escape hatch: if the only corrections people make are ones you offered them, you may be measuring your menu rather than their understanding. The best signal is a useful correction nobody anticipated.

Recovery of the source

This is the doorway from Chapter 6, tested. The short version should lead somewhere true. Can the reader find the passage, the figure, the moment in the recording? And having found it, can they see what the doorway smoothed over? A doorway that people can't get through, or that hides the disagreement that mattered, fails this measure no matter how good it looks.

The cold-arrival reader

The simplest version of the test is a protocol I described in The Exemplar Ratchet: the cold-arrival reader. "The cold-arrival reader arrives with no context on purpose, often in a customer's voice." After "about twenty seconds with the page", you ask two questions: "What does this company do for you?" and "What would you do next?" If they can't answer, "that finding comes from the reader — not from your need to win an edit war." And the reason it's so useful inside teams: "That is evidence about a reader, not your opinion. It depersonalises critique."

Those two questions were written for websites, but the shape adapts to anything AI produces for people.

You can use a fresh AI session as a cold reader too — a model with no context from the authoring conversation, given only the output and the two questions. It's a cheap way to catch obvious confusion before a person ever sees the thing. But treat it as a screen, not a verdict. A model reading a page is not a customer reading a page, and the research above is a warning about exactly that kind of substitution.

Test people who were there, and people who weren't

Chapter 6 argued that a doorway does two different jobs: it helps someone who was there recover the discussion, and it has to help someone who wasn't there construct an understanding from scratch. The test should check both.

Run the same material past both groups — people who were in the meeting or already use the product, and people who weren't and don't. Expect the doorway to do very well with the first group; that's what recognition is good at. Watch the second group closely. That's where you'll find out what the doorway needs to carry for newcomers, and whether the route to the depth is short enough.

Where you can, compare three versions of the same content: the wall of text, a structured page, and a source-linked doorway. The two-week method in Chapter 14 turns this into a schedule, with the results that would tell you it isn't working.

Fold honesty into the test

Chapter 4's honesty rule — a demonstration explains, evidence substantiates — can be tested directly. Add one question to any test of a demonstrated output:

"What do you now believe this can do?"

Then compare the answer with what it actually can do. Any gap is a demonstration implying something it shouldn't. That gap is invisible to a satisfaction survey. It's often visible in one question.

The one rule

All of this comes down to a single standard, and it's the reason the scoreboard in Chapter 1 says correct shared understanding rather than just understanding.

This is how you read that scoreboard. Correct understanding, per unit of human effort, measured by what people can actually explain, correct and find — not by what they say they liked.

Part I, at a glance

That's the doctrine. None of it arrived as doctrine. It came out of three systems I built before I had words for any of it — and the first of them, the one that gave this book its name, began with a batch of agent-built websites that were correct, complete and dull.

I went away and left it for a couple of hours.

When I came back, the most amazing-looking website the agents had ever built was sitting on my screen. I couldn't believe it. It wasn't a little better than the others. It was in a different category. I interrupted the loop that had made it and told it: yep, that's your gold standard now.

And then I sat there with a problem I hadn't expected. I knew it was better. I could not tell you why.

This chapter is how I found out — and what finding out taught me about communicating with people, which turned out to be a much bigger subject than websites.

Companies that build their own websites

Some context first. We've been building what we call minimum viable companies — MVCs. They're completely agent-built. They start with a company idea, and then they work out their own marketing, build their own website and so on.

I've defined the term more carefully in The Three Parts: a minimum viable company is "a small company-shaped model that makes an offer and its work inspectable. It should show the customer-facing proposition, an example of what a customer would receive, how the work would be performed and the assumptions still supporting the model."

Read that definition again with this chapter in mind. An example of what a customer would receive. The definition already demanded a demonstration. The website is where that example should live — the first thing a visitor meets. And at first, the websites didn't have one.

The boring sites

The websites were coming out a bit on the boring side. They looked like someone doing an introductory HTML course. They weren't quite that bad, but they were pretty boring.

It's worth being precise about what "boring" meant, because it wasn't that they were broken or ugly. They were correct. Here's the shape of a typical one, reconstructed:

Every block on that page charges the reconstruction tax. The headline names a category. The paragraph asserts benefits. The icon cards could describe a plumber or a bank. The image is decoration. Nothing on it lets a visitor watch the service do anything. It's complete, correct and uncommunicative.

In hindsight this is exactly what Anthropic describes when it warns that "without guidance, models can default to generic patterns" — the safe choices that dominate the web the models learned from.²⁵ At the time I just knew they were dull.

A man who can't judge design

Chris had made some more interesting websites in his own ChatGPT sessions and shared them with me. I tried to work out why they were good.

I should be honest about my qualifications here, because they turn out to be the point of the story. I'm not a graphic artist or a website designer. I'm not a brand expert. I struggle to say what makes one page better than another. Some days I struggle to even judge which looks better.

That matters, because it rules out the obvious fix. If you can't articulate what good design is, you can't write it into a prompt. Any specification I wrote would have been capped at my own idea of good — and my own idea of good was precisely the thing in short supply. Whatever happened next was going to have to come from somewhere other than my instructions.

The loop

So I set up a loop and let Claude Code run it, in the style of auto-research. I gave it a few different ways to try. Extract the brand, content, structure and page design from the good websites we'd seen, put that into the prompting as something generic, try a few variations, build the websites, have it update the marketing, and see if they got better. If that didn't work, just try to build better-looking websites from what it had learned — and if one of those worked, reverse-engineer it. I told it to vary the harnesses, vary the models and vary the prompting as it went.

Crucially, I told it to keep a static judge — the same evaluator every time — testing the websites on how good they looked, how interesting they were, how well they communicated, and a few other things I can't now remember. Two criteria I do remember adding. What's in it for me — make sure we're explaining to the customer what they get out of it. And use imagery to communicate.

Then I went away for a couple of hours.

The gold standard, and the mystery

Here's what I came back to.

The fantastic one had a shallower, wide image across the hero — the band across the top of the page. On the right-hand side, some people pouring cups of tea: the people and the product. On the left, faked-up text messages, styled and laid over the top of the image. Below that, the rest of the site. But it was the hero that did it.

For a while I couldn't work out why it looked so good. The explanations a non-designer reaches for — the colours, the photograph, the whitespace — are the ones that don't hold up, because pages that didn't work had those too. It looked amazing and I had no theory of why.

"It's demonstrating it"

So I asked. Claude, looking at it, said: it's because it's demonstrating the product.

That "Oh!" is the moment this book started. Everything I'd been circling for months — whiteboards after meetings, web pages instead of walls of text, reasons offered when you reject an image — clicked into one shape.

Read the hero element by element and you can see why the diagnosis is right.

That's the miniature worked example from Chapter 4, found in the wild before I had a name for it. This happens, the service responds, this is what I get. The visitor completes the product in their own head without being asked to imagine anything. And look at what the winning visual is made of. It isn't a picture instead of words. It still carries its words — in the messages — placed inside a situation the visitor recognises.

The nudge

What I did next is the part I'd most like builders to take from this chapter.

I like to do everything by nudge. We'd already been experimenting with more and less prompting, and more and less prescription in the prompting — spelling out sections, layouts and treatments versus leaving the model room. The over-prescriptive sites were coming out bad. So I didn't write the discovery into a specification. I didn't tell the agents to put text messages over a photograph. We went with less prescription, and one nudge.

Four words. No layout, no example, no instruction about images or text. Every model we tried read "demonstrate over tell" and went looking for a moment it could show — and found one. That's the aim from Chapter 7 working exactly as described: the nudge named the kind of move, and the models supplied the expression.

(Notice, though, how they all found the same expression. Hold that thought; it's the first symptom of a problem we'll come back to.)

What holding the judge still revealed

Because the judge never changed, the loop could compare everything it varied — harnesses, models, prompting — on the same scale. With enough testing, a clear ranking came out.

Prompting was the most important thing. The model was the next most important thing. And the harness — the scaffolding of tools and loop around the model — almost didn't make a difference.

On the model, the results were almost comic. We could send Opus a pretty vague, useless prompt — it had to be reasonable — and it would always do the amazing sites. The very first site that got amazing, we just chucked the job at Opus 5.5 and it went amazeballs. On the harness: we were varying them, and they almost didn't make a difference, including our own hand-built one in Python. Opus 5.5 could deal with that and still turn out spectacular sites.

There's an apparent contradiction in there worth untangling, because it's the most useful thing in the ranking. If prompting mattered most, how could a vague prompt produce amazing work? Because what mattered was the kind of prompt, not the amount. Over-prescription hurt. The right nudge helped. And a capable model given reasonable room did the rest. Prompt quality, not quantity.

The harness had to see

That last row came with an asterisk, and the asterisk is where the finding lives.

We realised our internal harness wasn't able to screenshot the web pages to review them. It was building pages it had never looked at. So we fixed that. Once it was fixed, it was equal to all the other harnesses. And Claude had done some smart image work to make the hero not 16 by 9 but 2.4 to 1 — that wide, shallow band with room for the scene and the messages side by side — so we had to build that tooling in too.

Those are the eyes and the canvas of Chapter 7, found by accident. The screenshot fix was eyes: the agent could finally inspect what a visitor would see. The 2.4:1 tooling was canvas: the agent could finally express the composition it had in mind. Before those fixes, the harness made a difference. After them, it barely did.

I was pleased to find the same two things described independently by Prithvi Rajasekaran at Anthropic. Building a harness to generate frontend designs, Rajasekaran gave the evaluator a browser so it could navigate "the page on its own, screenshotting and carefully studying the implementation before producing its assessment" — eyes. And the same work found that a single phrase in the criteria, "the best designs are museum quality", "pushed designs toward a particular visual convergence" — wording steering every output.²⁸ Different team, different harness, same two findings.

The governance page

The hero wasn't the only thing that changed. One of the sites had a governance page — who proposes what, who decides, who checks — and it had been just text, text, text, text, text. As soon as the agent did a diagram of it, it became something you could actually read. I wouldn't say it was a RACI chart, but it was that style of thing. It just looked more interesting, with the dots and the colours.

That's a different move from the hero. The hero was move 1 from the Chapter 4 family, show it happening. The governance diagram is move 3, show how the parts connect. Nobody asked for it by name — the nudge said demonstrate — but the principle underneath is the same: stop making the visitor reconstruct what could be shown.

It was crazy and amazing, and it also made me see the connection to everything else I'd been doing. It's like putting a whiteboard image on the website — which you can't usually do, though it might be reasonable in some situations. Every time it moved to demonstrating, or to a diagram, it was much more interesting.

What this shows — and what it doesn't

I've told you the result the way it felt. Now the discipline. This is what the trials support, and what they don't.

I had a theory at the time that Claude just inherently has been taught to be visual over text. I don't know that, and I'm not going to claim it. The observable result is more useful anyway: in these trials, capable models supplied strong visual judgement without anyone specifying the visual treatment. You don't need to know why a model can do that to use it.

The template trap, in the wild

Now back to the thought I asked you to hold. Every model got the idea. They all just did it — every one of them reached for fake text messages over an image.

That's the nudge working. It's also the template trap from Chapter 7 opening in the same moment. If every minimum viable company ends up with chat bubbles over a wide photograph, the discovery has become the next boring template, and in a few months those pages will look as generic as the icon cards did. The portable thing we found isn't "messages over a photo". It's "demonstrate a representative moment of customer value" — and that principle should produce different expressions for different companies.

The same goes for the 2.4:1 image. Building the tooling so an agent could make that composition was one of the two fixes that equalised the harnesses. Making every hero 2.4:1 would be a rule, and rules are what we were trying to get away from.

How a non-designer found a design principle

There's one more thing in this story, and it loops back to the book's central idea in a way I didn't notice until later.

I didn't start with a theory of good design. I couldn't have written one. What I had was some examples, a few commercial criteria, and a sense that the output was falling short. Then this happened:

1. A good specimen

   The loop produced a striking page. I recognised it was worth keeping, without being able to say why.

2. A proposed explanation

   Claude looked at it and proposed why: it demonstrates the product.

3. A small intervention

   We turned the explanation into a four-word nudge instead of a specification.

4. Tests on further specimens

   The nudge changed the output of every model we tried. "It works because it demonstrates" had been a hypothesis until then.

Look at step one. I didn't need to be able to articulate good design. I needed to be able to recognise it when I saw it — which is exactly what Chapter 5 says a well-designed system lets any human do. The machine prepared something I could react to; I reacted; the machine offered a candidate meaning for my reaction; I tested it. The same recognition that this book asks you to give your readers is how the book's central principle was found.

What I'd do next

If I ran this again tomorrow, three things would change.

• Add the cold-arrival reader to the loop. Twenty seconds on the page, two questions: what does this company do for you, and what would you do next? Run it on the gold standard and on a boring baseline. That's the measure the trials didn't have.
• Vary the move by company. Some businesses need move 1, some move 3, some move 5. Family, not template.
• Keep the static judge — for comparison. It found the finding. It just can't tell me whether visitors understood.

The funny thing is, a website is a communicator, right? And we're just talking about communications. Which is why the next specimen isn't a website at all.

It's funny how it happens.

Chris and I will have a discussion about a bunch of stuff. It might go for an hour. We've both put a bit into it — examples, objections, the times one of us changed direction halfway through a sentence. The recording goes into the system. And then it pulls one image out of it — a whiteboard-style drawing for one of the subjects we covered — and the image is like: oh yeah, that's what we were talking about.

This chapter is about what that moment actually is — because the obvious explanation is wrong in a way that matters — and about how a meeting archive built around it has to work for the people who weren't in the room.

Where the transcripts go

We transcribe all our meetings now and put them into our IP wiki — the knowledge base that holds our frameworks, projects and thinking. The wiki's architecture is its own story, and not this book's. One line of lineage is worth keeping, though. In You Built the Wiki for the AI, I argued that a knowledge base built so AI could understand the organisation turns out to have a second, more important product: "You built the wiki to make AI smarter about the org. The product is making humans smarter about their own org — with AI as the traversal engine." The meeting index is the human-facing end of that. The transcripts are there so the AI can know things. The index is there so people can.

Chris wanted a summary. And then the to-dos.

Chris's instinct for what to do with all those transcripts was the instinct almost everyone has. He wanted them more and more summarised. And then he wanted to-dos out of them.

I pushed back. I know people don't follow the to-dos, so that's pretty useless. And summarising in increasing levels just means you've lost anything that was useful there.

It's worth being fair to Chris here, because this wasn't a disagreement between someone right and someone wrong. Chris doesn't read long things; he's told me as much, and Chapter 1 took him at his word. His instinct about the reader was right. The summary chain was just the wrong fix for it. We both wanted the same thing: something that would actually land with a person who has two minutes. We disagreed about whether making it smaller would get us there.

What I built instead

So instead of summarising the meetings with text, I summarised them with images. Every major subject got a new whiteboard image. Under each one I linked the original audio, so you can click and hear that part of the conversation. And I pulled out a few quotes. No big walls of text to read.

The instruction to the machine was short, and one line of it did most of the work. I've told it not to wall-of-text it — and it's a really, really interesting way to communicate.

If you've read Chapter 6, you'll recognise the shape. One recognisable object per subject, a few exact quotes, a route back to the source. I built the meeting index before I had the word "doorway" for it. The doctrine came out of the specimen, not the other way round.

Why a whiteboard, and not a diagram tool

I asked for the images to look as if they'd been hand-drawn on a whiteboard — text and lines, a bit rough — rather than polished diagrams or infographics, and I think the choice matters more than it looks.

A whiteboard is the native format of a working discussion. Everyone has stood in front of one. A hand-drawn board reads as a sketch of where the thinking got to, not a finished product, which is exactly what a meeting record is. It invites "no, that arrow's wrong" in a way a glossy infographic doesn't. And it keeps the discipline Chapter 3 argued for: a board has room for a dozen words and a few lines, so it has to carry the shape and nothing else. There's no space on it for decoration.

The instruction behind the boards is short. I'd put its shape like this now:

# The shape of the meeting-index instruction (as I'd write it today)
For each major subject discussed, draw one whiteboard-style image:
the options, how they relate, who owns what, and any question left open (circle it).
Hand-drawn look. Few words. Placement carries the meaning.

Under each board, pull three or four exact quotes, verbatim, with speaker and timestamp.
Choose them for disagreement, decision and commitment, not eloquence.

Link each subject and each quote to the audio at that moment.
Don't wall-of-text it. Don't paraphrase the discussion.

Notice what's missing from it: no layout rules, no colour palette, no template. It names what the reader needs — the shape of each subject, the words that carried it, the way back — and leaves the drawing to the machine. It's aim, from Chapter 7, applied to a meeting.

One subject, walked

Here's what reading one subject card is like, at each of the three depths from Chapter 5. The subject and quotes are invented; the structure is the one I use.

1. Five seconds — the glance

   The board. Two options for pricing the pilot; a tick on fixed fee; per-seat pushed to "later?"; one question circled that nobody answered. If you were in the meeting, this is usually where you stop. You've got it back.

2. Thirty seconds — inspect

   The quotes. One makes the commercial case for fixed. One is the objection — and notice it has a condition attached, which the board alone couldn't carry. One is where it landed. They weren't picked for being well phrased; they were picked because together they tell you the disagreement, the decision and the condition on it.

3. As long as it takes — immerse

   Click the chip at 14:32 and you hear the ninety seconds where it turned: the tone in which "not signing off" was said, which the transcript can't give you and the board doesn't try to.

And notice what isn't there: the paragraph that begins "The team discussed pricing options for the pilot and agreed to…". It's the part of a normal summary that everyone skims and nobody trusts, and the index doesn't need it.

The same subject, through the summary chain

To see what the index saves, run that same subject through the chain Chris first asked for. Here is what each hop keeps, and what it quietly loses.

Nobody in that chain did anything wrong. Each version is a fair summary of the previous one. That's the problem Chapter 6 described: compress the compression and the useful part — here, "not until finance has seen the churn numbers" — dies early, and later hops just tidy what's left. The subject card keeps that sentence verbatim, with a timestamp, and the commitment strip turns it into an owned piece of work. The chain turns it into "revisit pricing model".

What "oh yeah" actually is

Back to the moment that started this chapter, because the obvious explanation for it is wrong.

The obvious explanation is compression: the picture somehow packed the hour into itself, the way the old saying says a picture holds a thousand words. If that were true, the picture would work just as well for anyone.

I don't think that's what happens. Chris and I already had the hour. We'd supplied the examples, the objections, the changes of direction. What the image gave us was a shape we could recognise — the right boxes in the right places — and the recognition brought the rest of the hour back into reach. The board didn't contain the conversation. It was a key to it.

That's the mechanism I described for personal memory in The Recognition Loop: a small cue, placed at the right moment, and then the person's own memory does the remembering. I described the reaction there too — you don't necessarily read the prompt about the zoo; "you go oh yeah." The meeting board is the same thing working for two people instead of one. It's the first row of the table in Chapter 6: for someone who was there, the job is recovery, and a good board does it brilliantly.

The newcomer problem

Now hand that same page to someone who wasn't in the room — a new hire, a colleague from another team, whoever inherits the project next year.

The board that made us say "oh yeah" is, for them, a set of boxes and arrows. "Fixed fee ✓ for pilot" tells them the conclusion. It doesn't tell them why, or what nearly went the other way, or that the finance objection carried a condition. They have nothing to recover. That's the second row of the Chapter 6 table: for them, the page has to teach — and the expertise-reversal effect from Chapter 4 says they need more of the worked example, not less.

None of that is a wall of text. It's four small additions that make the doorway teach as well as recover. And the test for whether they're enough is the one from Chapter 8: give a newcomer thirty seconds with the card, then ask what was decided and what's still open.

Following a subject across meetings

Indexing by subject makes something else possible, beyond any single meeting. Subjects recur. Pricing comes up in one meeting, again three weeks later, and again at the review. When each meeting's record is a block of minutes, following one subject across them means opening three documents and reading all of each. When each subject has its own board, you can line the boards up.

Read across that row and you get something no single set of minutes gives you: the path of the decision. The open question circled in September becomes a specific question in the second meeting and a settled answer in the third. That's move 2 from Chapter 4 — make the difference visible — falling out of the structure for free. And if the final decision is ever questioned, the route back isn't "find the minutes from October"; it's three boards and three audio chips, in order.

It also changes what a newcomer can do. Someone joining the project in November doesn't need the whole history. They need the row. Thirty seconds across three boards tells them what was decided, what it replaced, and roughly why — and any of the three chips will play them the moment it moved.

Chris's photographs

Chris spends a lot of time in our discussions actually writing on the whiteboard, and he takes photos of it. I haven't bothered ingesting them. They're probably useful. The whiteboard images I get back from the machine are much cleaner and simpler than Chris's, and for a long time that felt like a reason to skip the photos.

It isn't. The photos aren't worth keeping because they're prettier — they're not. They're worth keeping because they may carry things that never made it into the spoken transcript: the arrow Chris drew and then crossed out, the two ideas he circled together without saying so, the number in the corner. Keep the photographed board as the source; keep the clean board as an interpretation people can check. That's the rule from Chapter 6, and I'm the one who hasn't been following it.

The to-do fight, resolved

Chris and I were each half right about the to-dos. Chris is right that work has to come out of meetings; a meeting that produces no commitments often didn't need to happen. I'm right that the extracted list doesn't get done — because, as Chapter 6 put it, an extracted task list is not yet an agreed commitment.

The resolution is to stop making one list do two jobs. The index holds the meeting's knowledge, navigable by subject. Beside it — not instead of it — sits a short strip of commitments: only the things someone actually said yes to, each with an owner, a condition for done, and the timestamp where it was agreed. In the glance figure at the top of this chapter it's the grey line at the bottom. Two items, not twelve. Each of them real.

People reach for the source

I built this on instinct, but it's reassuring that the most careful study I found of an AI meeting-recap system points the same way. In Microsoft's research, every participant used the ability to expand a summary back into the original dialogue, and many asked for deep links into the recordings (Chapter 6 has the detail).²² The audio chip under every subject is exactly that deep link.

What I'd change now

• Ingest Chris's photos as source, one click from the generated board for each subject.
• Add the commitment strip — accepted work, owner, done-condition, timestamp — and stop extracting to-dos.
• Add the newcomer layer — the decided/open caption and a why-it-came-up line — to every subject card.
• Run the Chapter 8 test on one meeting: the index against a text summary of the same meeting, with people who were there and people who weren't.

And keep the instruction short. One whiteboard per subject. A few exact quotes. Link the audio. Don't wall-of-text it.

The index works after the conversation is over. The last specimen is the one that works during it — a canvas where the AI and I both have our hands on the same object, and where saying "no" costs a tap instead of a paragraph.

An image appears on the canvas. I don't like it.

I click no. Instead of an empty box asking me why, five or six reasons appear, written for that particular image. And often the reason I didn't like it is right there. I tap it, and the next attempt can take that reason into account. I never had to write a sentence explaining myself.

Chapter 5 laid out the doctrine of the return channel. This is where it came from: a working interface, used daily, that made me notice how much of the cost of working with AI sits in the reply, not the output.

The canvas

I built an interface around a dynamic visual canvas that the AI and I both operate on. There's a fast AI and a slow AI, and it's working great.

The fast/slow part matters more than it sounds. The fast agent keeps the conversation moving — acknowledges, asks a quick question, makes a low-risk move — while the slow agent does the real work in the background: generating the next candidates, researching, revising. When the slow agent has something, it lands on the canvas. That's the architecture from The Fast-Slow Split, applied to a visual surface. The effect, for me, is that the object I'm looking at stays live. I'm never staring at a spinner while something thinks.

"Both operate on" is the part that changes the experience. I move things, reject things, keep things. The AI proposes, revises, annotates — on the same objects. The canvas isn't where the AI shows me its answer. It's where the two of us work. Chapter 5 described that shift in general terms, as the output becoming the object of the conversation. The practical difference that design makes is that the human's side of the work becomes pointing instead of explaining. "Not that one." "More like this." "Keep this bit." Every one of those is a gesture at something on the screen, not a paragraph.

One rejection, walked

Here's a single rejection, step by step. The content is invented; the shape is how it works.

1. The possibility

   The canvas shows three hero-image concepts for a small cleaning business's website. Concept A is a bright, empty, spotless office.

2. The reaction

   I don't like it. I couldn't tell you exactly why in the first second. I click no.

3. The candidate meanings

   Six reasons appear, generated for that image: "too corporate", "no people in it", "doesn't show what they actually do", "colours feel cold", "too cluttered", "wrong kind of business" — plus none of these, not sure yet, and my own words.

4. The recognition

   "Doesn't show what they actually do" — yes, that's it. An empty clean office shows the result, not the service. I tap it, and "too corporate" as well.

5. The change

   The next candidate shows a cleaner mid-task in a small café kitchen, the owner in the background. The two reasons I picked are exactly what changed.

That's assisted articulation from Chapter 5, in a single loop. I had a reaction, not an explanation. The menu offered possible meanings for my reaction. I recognised mine. And notice step four: the reason I recognised was sharper than anything I'd have typed. "Not quite right" is what people type into empty boxes. "Doesn't show what they actually do" is a design principle — the same one Chapter 9 found — and I got to it with a tap because the machine had done the articulating and left me the recognising.

That's what I mean by bandwidth. A tap carries a sentence's worth of meaning because the meaning was prepared by the machine, and all the human had to do was recognise it.

When the menu misses

The rejection walked above is the good case. Here's the other one — a hypothetical, built to show where the design either earns its keep or quietly does damage.

1. A near miss

   Imagine a draft email to a long-standing client comes back from an agent, and the person reviewing it rejects it. The reasons offered: "too formal", "too long", "buries the ask", "sounds defensive", "wrong sign-off", "too salesy".

2. None of them is it

   They're all plausible, and none is what's wrong. The problem is that the email mentions a project the client cancelled last year — something the agent couldn't have known was sensitive.

3. The hatch

   Without "my own words", the least-wrong option is "sounds defensive", and a busy reviewer would probably tap it to get on with their day. The system would learn that these emails are too defensive, and the next draft would be blander and still mention the cancelled project. With the hatch, the reviewer types six words: "don't mention the cancelled project."

4. What the system does with it

   This is a context miss, not a tone miss — the routing table in Chapter 5 would send it to what the system knows about the client, not to the template. And an own-words entry like this is a candidate reason for next time: "refers to something sensitive" belongs on the menu for client emails.

IllustrativeA hypothetical case, invented to show the failure mode — not a record of a real rejection.

That's the escape hatch from Chapter 5 doing exactly what the research predicted. Suggested reasons miss some of the time; when they do and there's no way out, people pick the nearest wrong one and the system learns something false. The hatch costs a few seconds of typing in the rare case, and saves the system from confidently learning the wrong lesson.

What makes a good set of reasons

The menu only works if the reasons are good, and "good" here has a specific meaning. Working from the mechanism in Chapter 5 — the person has to recognise their objection in a second, and the set has to leave room for what they actually meant — a few design properties follow.

• Specific to the item. "Doesn't show what they actually do" is about this image. "Not relevant" is about nothing. Generic reasons turn assisted articulation back into a form.
• Different from each other. Six reasons that are all versions of "too busy" waste five slots. A good set spreads across what could be wrong.
• Spread across layers. Some reasons about the content (what's shown), some about tone (how it feels), some about composition (how it's arranged), and one about the concept itself — "wrong idea entirely" — so a fundamental miss has somewhere to go.
• In the person's language, not the designer's. "Colours feel cold", not "insufficient warm-palette saturation". The person has to recognise it in a second.
• Short. A reason is a chip, not a sentence. If it needs a clause of explanation, it's two reasons.

This is cheap work for the machine and expensive work for a person, which is exactly the trade the Mature Token Law says to make. Generating six well-spread candidate reasons for a rejected image costs the model a moment. Composing one precise reason from scratch costs the person far more — and usually doesn't happen, which is why empty boxes collect "not quite right".

What a good rejection menu needs

Having written Chapter 5, I can review my own menu against it. I'll be careful here. What I've described is what the menu does: five or six AI-generated reasons for each rejected item. The table below is the checklist any rejection menu — mine included — should be held to, not a claim about which boxes mine currently ticks.

And one number to watch: the pick rate. How often is a suggested reason chosen, versus "none of these", versus my own words? If a suggested reason is chosen almost every time, check it isn't simply the first one on the list. If "none of these" is common, the generator is missing something, and the own-words entries will tell you what. Chapter 14 turns this into a test.

"Don't wall-of-text me"

The same instinct shows up in how I work with coding agents, and it's where the line in Chapter 1 came from.

Whenever I've got options in coding — a few different ideas about how to build something — I don't want them as prose. Don't wall-of-text me. Write me a web page about it and let's discuss it. I don't mind reading things that are valuable, but sometimes it just seems slow. Writing a web page with structure and colour and images is a better way of communicating than a wall of text.

Here's what that looks like. The question and options are invented, but it's the shape I ask for:

Compare that with the five paragraphs an agent writes by default. In prose, I have to hold option A's risk in my head while I read option C's effort, and find the recommendation somewhere near the bottom. On the page, I compare by looking across a row. The "breaks first" row alone — which prose tends to bury in a subordinate clause — can be what decides it.

This is two moves from Chapter 4 at once. Make the alternatives comparable: the options sit on the same distinctions, so the comparison is visible instead of computed. Give me something to react to: each option has handles, so my reply can be "drop C, and tell me more about B's schema" — a pointer, not an essay. And the page is a doorway: each column opens into the full write-up, so nothing the agent worked out is lost. It's just not the first thing I meet.

The request itself is short, and it names moves rather than layouts. The shape of what I ask a coding agent for, when there are options on the table:

# The shape of the request (as I'd put it now)
Don't wall-of-text me. Write me a web page about it and let's discuss it.
Put the options side by side on the same distinctions:
effort, risk, how reversible it is, and what breaks first.
Recommend one, and say what it gives up.
Let me react to each option. Link each one to the detail.

Nothing in it says what colours to use, how wide the columns are, or whether to draw diagrams. Sometimes the agent adds a small sketch of each option's architecture, sometimes it doesn't; that's its call. What it can't do is bury the recommendation in paragraph four, or describe option C's failure mode in a way I'd have to hold in my head while reading option A. The distinctions are fixed because they're what I need to decide. The rest is the agent's design judgement — which, as Chapter 9 showed, is usually better than mine.

Depth, when there's time

None of this means I only ever want the short version. I sometimes like to listen back to a detailed description from AI. I immerse myself in it. But I don't always have time to do that, because sometimes that's twenty minutes.

So the same material can live at three depths, and the same person can want any of them.

That's the design principle from Chapter 5, lived: not "Scott's a skimmer" or "Scott reads everything", but different depths for different moments, each one step from the next.

Three specimens, one move

Put this chapter next to the last two and the shape of the book is visible.

Chapter 9 ended on a website being a communicator. So is a meeting record, and so is the reply to an image you didn't like. On three different surfaces I'd been doing the same thing without noticing: handing a person something to recognise instead of something to reconstruct, and keeping the depth one step behind.

What I'd measure next

• Hatch use and own-words entries on the rejection menu — they're the map of what the generator is missing.
• Position effects — occasionally shuffle the order of reasons and check whether picks follow the position rather than the reason.
• Options page versus prose — for the same coding decision, time to a correct explanation of the trade-off, per Chapter 8.

That's the three systems the doctrine came from. Built before I had words for any of it, each doing the same thing on a different surface. The question now is what you do on Monday — as the person all this output lands on, and as the person who builds the things that send it.

Start with an inventory of what your AI now sends you.

Not what it could send you — what actually lands, week after week. Typically, the list looks something like this:

Fill in your own version. The last column is the one that matters. Each entry in it is a reconstruction tax you're paying every time — the work of rebuilding, from prose, something the machine already had. The rest of this chapter rebuilds each of the four so that you don't.

Everything here applies Part I; I'll point back rather than re-argue. And every example is invented and labelled, because the point is the shape.

1. The meeting summary becomes a meeting doorway

This is Chapter 6's doorway, applied to your inbox. One drawn board per subject. A few exact quotes, chosen for disagreement and decision. The open questions marked. The audio one click away. And a separate strip of commitments — only the work someone actually accepted, each with an owner and a condition for done.

What changes for you is specific. You can see where the disagreement was, not just the conclusion — which is usually where the risk lives. You can hear the thirty seconds where it turned if you need to. And the commitment strip has names on it, so "follow up with finance" stops being a sentence nobody owns.

What to tell your team: "Stop sending me the summary of the summary. Send me the index, keep the recording, and only list what someone said yes to."

2. The status report becomes "what changed, and where it's stuck"

A status report's job is change and decisions, not activity. Twelve bullets of things that happened make you do the diff yourself — compare against last week's twelve bullets, from memory — and the green dot tells you nothing about the item that's been stuck for twelve days. This rebuild uses two moves from Chapter 4: make the difference visible (each line shows where it was and where it is) and show how the parts connect (a small map of the workstreams is often worth adding, with this week's changes highlighted).

One guard, from the honesty rule. A "what changed" view can hide what didn't. If an item has been stuck for three weeks, it belongs in the doorway precisely because it didn't change. A diff that leaves out the stall hasn't summarised the project. It has hidden the one thing you most needed to see.

3. The long analysis becomes an options page

This one is the "don't wall-of-text me" request from Chapter 11, generalised to any decision.

The gain for you is that you compare by looking across a row instead of holding three sections in memory. You can say "not A — because of the AI features row" and mean something precise. And the analysis you paid for isn't lost; it's behind each column, for the moment one of the cells surprises you.

4. The board paper becomes a decision page

Board papers are the most consequential documents most leaders receive, and often the least readable. The rebuild puts the ask first, the options side by side, and — the part most papers never include — one demonstrated consequence: a miniature worked example of what actually happens if the board says yes.

Two boundaries matter here more than anywhere else in the book. First, the honesty rule: the demonstrated exchange explains what the pilot would be like; it doesn't prove it will work that well. It must be labelled as illustrative, and the evidence pack behind it must be real. Second, board papers carry obligations. The full paper — every qualification, every legal consideration, every piece of prose that needs to be precise — stays complete. As Chapter 3 said, prose is still the right arrangement for argument and qualification. The doorway changes; the record doesn't shrink.

The paragraph to send your team

You can ask for all of this without writing anyone a style guide. Here's a request brief you can paste to your team — or to their agents — as it stands:

When you send me something to decide or review:

Lead with what you need from me.
Show me the options side by side, on the same distinctions,
and say what the recommendation gives up.
Show me what changed since last time — including what's stuck.
Where it helps, show one concrete example of what it looks like
in practice, labelled as an example.
Keep every source one click away.
Put accepted actions in a separate list, each with an owner
and a condition for done.
Don't summarise the summary.

Notice it names moves, not layouts. It doesn't say "use a table" or "add a diagram" or "no more than one page". It's aim, from Chapter 7, given by a leader instead of a builder — and it leaves your team and their tools free to find the right expression for each thing they send.

Reading a doorway well

A doorway changes your job as a reader too. You're no longer wading through everything; you're deciding when to descend. A few signals that it's time:

• The shape surprises you. If the board or the options page doesn't look like what you expected, go one level down before you react.
• A quote contradicts the board. The drawing says "agreed"; the quote says "not until…". Believe the quote, and listen to the audio.
• The decision is irreversible. For anything you can't undo, read the depth, whatever the doorway says.
• The "open" tag is on the thing you care about. Open questions are where your attention earns its keep.

And one signal about the doorway itself: if you try to descend and there's nowhere to go — no source behind the claim, no recording behind the quote — ask why. Either it was summarised away, or it never existed. Both are worth knowing.

The to-do conversation

The hardest change in this chapter is usually the to-do list, because teams are attached to it. An extracted list of actions feels thorough, and removing it feels like removing accountability. It's the opposite. Here's roughly how I'd put it:

If the team worries things will fall through the cracks, point out that they already are — that's what an unowned list of twelve items is. Two owned commitments get done. Twelve extracted ones get forwarded.

Measure it without a research team

You don't need a study to know whether this is working. At your next meeting, take one subject from the index and hand it to someone who wasn't there. Give them thirty seconds. Ask what was decided and what's still open. Then hand the text summary of the same meeting to someone else, and ask the same questions. Ten minutes, and you'll know more about how your organisation communicates than a satisfaction survey would tell you in a year. (Chapter 8 has the full version; Chapter 14 has a two-week plan.)

You can ask for all of this. Someone still has to build it — and for the builder, the levers are different.

The next time an agent's output disappoints you, you'll have four levers within reach.

More rules. A better nudge. Eyes. A canvas. Chapter 7 argued the doctrine: the first lever is the reflex, and for communication work it's usually the wrong one. This chapter is the other three, as things you can install this week — plus the reply channel, and one agent rebuilt from end to end so you can see the difference in the actual system prompt.

The nudge card

Chapter 7 previewed this. Here's the full card: the seven moves from Chapter 4 as one-line nudges, with when to reach for each and when not to.

Three phrasing rules, all from the model-makers' own guidance.

• Say what to do, not what to avoid. Anthropic's advice is explicit: "Tell Claude what to do instead of what not to do."²⁵ "Demonstrate over tell" works partly because it's a positive instruction. "Don't write walls of text" names the thing you don't want and leaves the model guessing what you do.
• Keep it calm. The same guidance warns against shouting at capable models: "dial back any aggressive language. Where you might have said 'CRITICAL: You MUST use this tool when...', you can use more normal prompting."²⁵ A nudge is a whisper, not a siren.
• Give the reason. "Providing context or motivation behind your instructions, such as explaining to Claude why such behavior is important, can help Claude better understand your goals."²⁵ Add one clause: "Readers skim; they understand faster when they can see a moment of the service than when it's described."

And one rule of my own: use at most two nudges per output. One names the main move; a second can cover the depth (move 7 is the usual partner). Stack four or five and you're writing a specification again.

Answer formats

Not every agent output is a web page. Most of what agents produce is an answer to a question. The same moves apply; the question's shape tells you which.

That last row needs saying in the system prompt itself, or a model primed to be visual will force a diagram onto an argument. Something like: "When the question is about why, or depends on qualifications, answer in clear prose — a diagram would drop the 'unless'." Chapter 3's last row, turned into an instruction.

The eyes loop

If your agent produces anything visual — a page, a report, a chart, a card — it should look at it before you do. Here's the loop.

The reason for step four's fresh context is the finding from Chapter 8: models evaluating their own work tend to praise it. The look-pass should be a different conversation with a different job — a reader, not an author.

The canvas checklist

Can your agent actually express what the nudges ask for? Check that it can:

• Compose images at the proportions the idea needs — including wide, shallow heroes — not just one default ratio.
• Lay text over images, and keep that text as real, selectable text where it can.
• Render diagrams as HTML or SVG, so they're inspectable and the eyes loop can check the words in them.
• Lay out side-by-side comparisons that survive on a phone.
• Show before-and-after frames.
• Label anything illustrative as illustrative.

Treat every item as a capability to enable, not a requirement to put in the prompt. The moment "wide, shallow hero" goes into the prompt, every page gets one.

Rejection menus in your product

If people react to your agent's output — accept or reject drafts, designs, proposals — give them the reply channel from Chapter 5. Here's a spec you can build to.

The event record can be small. Something like this is enough to do everything above:

// one rejection event
{
  "item_id": "hero-concept-a",
  "offered": [
    {"text": "Too corporate",                     "layer": "tone",        "position": 1},
    {"text": "No people in it",                   "layer": "content",     "position": 2},
    {"text": "Doesn't show what they actually do", "layer": "concept",     "position": 3},
    {"text": "Colours feel cold",                 "layer": "tone",        "position": 4},
    {"text": "Too cluttered",                     "layer": "composition", "position": 5},
    {"text": "Wrong kind of business",            "layer": "brand",       "position": 6}
  ],
  "picked": [1, 3],
  "hatch": null,
  "own_words": null,
  "context": "cleaning-business homepage, round 2"
}

Guarding against the template trap

Once a nudge works, expect it to work the same way everywhere — and plan for that. Three guards:

• Batch review. Every so often, render the last twenty outputs side by side. If you could swap the logos between them and nobody would notice, the nudge has hardened into a template.
• Vary the move by audience. Keep a small map of which move suits which audience or product, and nudge accordingly, rather than one nudge for everything.
• Run the regenerate test. Give the agent only the nudge and a sketch of a new domain it hasn't seen. You want something recognisably in the family and fitted to that domain — "a family member", in the phrase from Generative Design Patterns — not a clone of the last output.

Where to stay prescriptive

One agent, rebuilt end to end

Here's the whole kit applied to one agent. It's invented, but it's the most common kind of internal agent there is: someone asks it which of several vendors to choose, and it answers.

Before

# System prompt — before
You are a procurement analyst. When asked to compare vendors:
- Start with an executive summary of 3-5 bullet points.
- Then write a section for each vendor with headings: Overview,
  Pricing, Features, Risks, Support.
- Each section must be 150-250 words.
- Include a comparison table with columns: Vendor, Price, Rating.
- Bold the recommended vendor's name.
- End with a Conclusion section.
- Do NOT use casual language. Do NOT speculate.
- ALWAYS be thorough.

The output from a prompt like that is predictable: around eighteen hundred words, a summary that hedges, five sections per vendor at 150 to 250 words each because it was told to, a comparison table whose "Rating" column nobody can interpret, and the actual recommendation in the ninth paragraph. Every rule was followed. The person who asked still has to build the comparison in their head.

After

# System prompt — after
You help colleagues choose between vendors.
North star: the reader should be able to choose in under a minute
and see exactly what they're giving up.

Make the alternatives comparable: lay the options side by side on the
same distinctions — the ones this decision actually turns on.
Say what your recommendation gives up.
Let the reader inspect every claim: each cell links to its source.

Hard constraints:
- Every price and contract term comes from a cited source; label estimates.
- Label any illustrative example as illustrative.

Choose the layout that makes the comparison easiest to inspect.
If the question is really about why, answer in clear prose instead.

Look at what changed. The role is one line. There's a north star that describes what success looks like for the reader. There are two nudges — move 5 and move 7 — and nothing about headings, word counts or bold text. The hard constraints are the must-be-exactly parts: facts and honesty. And there's explicit latitude, plus the escape clause for questions that need prose. It's the shape I described in The North Star Prompt, pointed at communication.

And the check, before anyone relies on it: the eyes loop passes (the page renders, every source link resolves, nothing is clipped), and a colleague who hasn't seen the question can answer "which would you pick, and what are you giving up?" correctly in under a minute. That last one is the test to run, not a result I'm reporting — it's the Chapter 8 measure, and it's the only one that tells you the rebuild worked.

None of this works everywhere, and a book that only told you where it works would be doing the thing Chapter 8 warns about. The last chapter is where it breaks — and how to find out, in two weeks, whether it works for you.

Here's the failure I'd worry about most, because it looks exactly like success.

A beautifully demonstrated page. Warm image, a tidy exchange laid over it, a clear recommendation. The reader nods, smiles, clicks on. Ask them afterwards what the company does and they tell you — confidently, fluently, and wrongly. The demonstration was so easy to follow that it carried them straight past the part that mattered.

This book has argued that handing people something to recognise beats handing them something to reconstruct. That's true. It's also true that recognition is fast, and fast is exactly when people stop checking. A method that makes understanding cheaper also makes misunderstanding cheaper. So before the book ends, here is where it breaks — and a way to find out whether it's working for you.

Nine boundaries

1. When prose was the right answer

When it bites: argument, qualification, careful definition, legal wording, a single correct answer. What it looks like: a tidy diagram of a policy that has dropped the "unless"; a decision page that turns a conditional recommendation into an unconditional one. What to do: keep the prose, as the depth behind the doorway (Chapters 3 and 6). Tell your agents explicitly when prose is right (Chapter 13). The arrangement question sometimes answers "a paragraph", and that answer is as valid as any diagram.

2. Decoration creep

When it bites: as soon as "be more visual" becomes a goal in itself. What it looks like: stock images above every section, an icon beside every bullet, an infographic where a sentence would do. What to do: for every visual element, ask what work it saves the reader. If the answer is none, delete it. Decoration isn't neutral; it competes with the parts that matter (Chapter 3).

3. Demonstrations that imply too much

When it bites: whenever a demonstration shows something the product can't reliably do — or can't do at all yet. What it looks like: a mock message thread for a feature on the roadmap; a demo dashboard with invented numbers that read like results; a "typical" example that isn't typical. What to do: the honesty rule from Chapter 4. A demonstration explains; evidence substantiates. Label illustrations as illustrations, never demonstrate what isn't there, and give any claim that matters a route to its evidence.

4. The template trap at scale

When it bites: the moment a nudge works well. What it looks like: every page, report or answer your agents produce has the same shape — the same chat bubbles, the same wide hero, the same three-column comparison whether or not there are three options. What to do: batch review, vary the move by audience, run the regenerate test (Chapters 7 and 13). The principle should produce a family, not clones.

5. Newcomers

When it bites: whenever the people reading a doorway weren't there when it was made. What it looks like: the meeting board that made the participants say "oh yeah" means nothing to the new project manager six months later. What to do: remember that a doorway recovers for participants and has to teach for everyone else (Chapter 6). Add the decided/open caption and a line of context; make the route to the depth short; test with people who weren't there (Chapter 10).

6. Steering by suggestion

When it bites: in any reply channel that offers reasons. What it looks like: the same suggested reason picked again and again — because it's first on the list, or because the model always generates it — until the system has taught its users to think its thoughts. What to do: keep the escape hatch — suggested reasons miss often enough that, without one, people end up working harder than with an empty box¹⁷ — shuffle the order sometimes and check whether picks follow position, and read the own-words entries (Chapters 5 and 11).

7. Liking mistaken for understanding — and judges mistaken for customers

When it bites: whenever you evaluate by satisfaction, engagement, or an AI reviewer's score. What it looks like: "everyone loved the new format"; "it scored nine out of ten". What to do: the comprehension test from Chapter 8. People can prefer the format that helps them less;¹³ models praise their own work;²⁸ a fixed judge compares versions but doesn't prove understanding.

8. Visuals some readers can't use

When it bites: for anyone using a screen reader, anyone with a colour vision deficiency, anyone on a small screen, anyone who needs to search or copy the text. What it looks like: meaning carried only in colour; text baked into images; diagrams with no labels; alt text that describes the colours instead of the relationship. What to do: keep text as selectable text; label diagrams so the relationship is also stated in words; write alt text that says what connects to what; never encode meaning in colour alone. A visual some readers can't use is decoration to them.

9. The nudge becomes a look

When it bites: when the words you use to steer the machine describe how the output should look rather than what the reader should be able to do. What it looks like: the "museum quality" effect from Chapter 7 — a phrase that pulls every output toward the same aesthetic.²⁸ What to do: name the reader's need, not the style. "Demonstrate over tell" steers toward a kind of move; "make it premium" steers toward a look.

Almost every one of those failures is the reconstruction tax sneaking back in, or a way of hiding that it has. Which is why the only reliable defence is to measure what readers actually understood.

The two-week field method

The ideas in this book came out of my own systems — a canvas, a meeting index, a batch of agent-built websites — and Chapter 1 said plainly what that evidence is and isn't. This is how you find out whether they hold in yours. It's small, cheap, and designed to give you a clear answer either way.

Day 1 — set up

• Pick one recurring AI output that people don't read properly: the meeting summary, the weekly status report, the agent's analysis.
• Write the answer key: one line stating what a reader should understand from a typical instance of it. If you can't write that line, you've learned something already.
• Choose five to ten readers, mixing people close to the work with people who aren't.

Week 1 — Test A: told versus demonstrated

Take two instances of the output. For each, produce two versions of the same content: the current prose, and a rebuild using one or two moves from the Chapter 4 table, with the depth one click behind. Show each reader one version of each instance — never both versions of the same content — and swap which version they see for the second instance. Measure the three things from Chapter 8: time to a correct explanation, useful corrections, recovery of the source. Ask which version they preferred, and record it separately. Then compare the preference with the understanding. The gap between them, if there is one, is the most useful number you'll get.

Week 1 — Test B: participants versus newcomers

Take one meeting. Build a doorway for it — one board per subject, a few exact quotes, the audio linked — and keep the text summary too. Give the doorway to two people who were in the meeting and two who weren't; give the summary to another two of each. Thirty seconds each, then: what was decided, and what's still open? Expect the doorway to win clearly with the participants. Watch the newcomers: that's where you'll learn what your doorways need to carry.

Week 2 — Test C: the rejection pick rate

Wherever people reject AI output in your workflow — drafts, designs, proposals — replace the empty "why?" with five or six generated reasons plus the escape hatch. For a week, log what's offered and what's picked. On half the occasions, shuffle the order. At the end, look at three things: how often a suggested reason was picked, how often the hatch was used, and whether picks followed position when the order changed. And read every own-words entry.

Week 2 — the nudge swap

For one agent that produces visual or structured output, remove the layout rules from its prompt and add one move-nudge from the card in Chapter 13. Make sure it can screenshot its output and look at it. Compare a batch of before and after outputs — not by taste, but with the cold-arrival questions from Chapter 8, asked of people who haven't seen either.

Where to start on Monday

1. One output

   The AI output your people are most likely to ignore this week.

2. One rebuild

   Something to recognise, with the depth one click behind. Use the leader's request brief (Chapter 12) or the builder's nudge card (Chapter 13).

3. One test

   Two questions, thirty seconds, one person who wasn't there.

The same move, everywhere

Three systems taught me this. A batch of agent-built websites, where a single photograph with a few text messages over it did what paragraphs of benefits couldn't. A meeting archive, where one drawn board per subject brought an hour back for the people who'd lived it. A canvas, where saying no stopped costing a paragraph and started costing a tap. Different surfaces. One move.

A website, a meeting summary, a status report, an agent's answer, a board paper — each is a place where the machine has the thing, and the human gets handed a description of the thing, unless someone decides otherwise. Decide otherwise. Show the moment. Draw the relationship. Offer the choices. Let people answer back by pointing. Tell the machine the kind of move, not the layout, and let it see what it made. Then check that people understood.

None of that means writing less of substance. The recording, the transcript, the full analysis, the twenty-minute walk-through — all of it stays, for the moment someone wants it. What changes is what they meet first, and whether they can find their way back.

Don't merely reduce the number of words. Reduce the work required to understand — and make it easier to show where the understanding is wrong.