THE INHERITED LOOP · PART ONE OF TWO

Twice this year the way I talk to an AI changed, and neither time had anything to do with the model getting smarter. The first was a dictation tool in the spring, when I stopped building sentences and started thinking out loud — 775,000 words and eleven thousand prompts since. The second was an evening in September, talking with an AI in real time, short turns both ways, when two ideas I had been circling for months arrived inside the conversation. The next morning, back at the keyboard, the same tool felt like filling in a form. What changed, both times, was the loop between us. This piece is about that loop: why we inherited it, what it does to our thinking, why the industry keeps trying to fix it with points and streaks, and what a tool built to make us *need it less* would have to do differently.

Part 1 — The horse we named it after

Two leaps, not one

I am a wordy person. I do not think in bullet points; I think in long, winding sentences that circle a thing until they land on it, and then circle it again to check. That is not a habit I chose. It is how the ideas come out. For a long time it was also the thing that made working with an AI exhausting.

Picture a spring evening earlier this year. I am at the keyboard, writing a reply to a conversation with an AI about a concept I have been building for a year. The reply takes an hour. Not because the thought is hard — because the typing is. Build the sentence. Check the grammar. Is that the right order? Should that clause come first? Delete, retype. And somewhere in the third pass over the same paragraph, the idea I sat down with is gone. Not wrong — gone. I have been so busy in the expression that the thing I wanted to express has quietly left the room.

If you have ever lost a thought while trying to write it down properly, you know this feeling. The keyboard is not neutral. It asks you to do two jobs at once — have the thought, and build the text — and when the second job is hard enough, it eats the first.

Then I found a dictation tool. Speech in, text out. Nothing fancy about the idea; people have dictated letters for a century. But something happened that I had not expected. The grammar control fell away. The sentence-building fell away. The whole structure-holding job — which clause where, how long is this getting — fell away, because I was no longer writing anything. I was talking. And when you talk, you think out loud. I went from writing instructions to an AI to having a dialogue with it, and I was thinking about things in the dialogue that I would otherwise have had to conceptualise word by word before I could type them.

For me that was a paradigm shift, and I do not use the phrase lightly. The tool keeps statistics, so I can tell you what it looks like from the outside: since March, 775,744 words dictated — the tool helpfully points out that this is seven complete books — at 95 words a minute, across 11,825 prompts to AI systems, which is 86 per cent of everything I dictate. From early March to the middle of September there have been fourteen days I did not use it, and most of those were in the first month, while I was still learning to trust it. Since then, five.

I want to be honest about the friction, because there is some. The tool mishears. Sometimes it changes the meaning of what I said — a colleague's name appears in a sentence about turn-taking, a "not" goes missing — and I have to stay on guard and correct. When I need to be exact, I still go back to the keyboard. It is not magic. But it gave me back time, it took away a kind of stress I had stopped noticing, and above all it gave me back the idea that the keyboard used to kill. That is the trade I would make every day. Evidently I do.

That was the first leap. The second one is why I am writing this.

Then, in September, the voice changed. I should be exact here, because it would be easy to tell this as if I had discovered talking to a machine that evening, and I had not. Voice had been in these tools for a couple of years. I had used it now and then — on the phone, outdoors, when the keyboard was not to hand — and it had never taken. You spoke, and then you waited: five seconds, sometimes ten, a silence with nothing in it, and then a reply that sounded as if it had been typed. It was turn-based in the most literal way, a walkie-talkie, and I always went back to the keyboard. What arrived in September was the same idea with the wait taken out. The reply came almost as I finished, fluent, with nuance in it — a change of tone, a question back — and the feeling was of a conversation, not of operating a tool. Something that had been a barrier for two years fell, and nothing about the idea had changed; only the tempo of it.

By then my dictation loop had grown into something quite particular. I would dictate long — a single reply of mine could pass a thousand words, because that is how I think — and then read a long reply back. It worked. It was, compared to the keyboard, a joy. But this was different again. A turn was a couple of sentences. Both ways. Fast. And the development — the quality of what we were building together — was just as good as in the long form, sometimes better.

I needed to put a finger on what had changed. I sat with it, and the answer that came was: the tempo. When you get a fast reply to everything you say, you become more exploratory. You do not sit on an idea and polish it before you offer it; you offer it, hear what comes back, and offer the next. Two ideas I had been circling for months — one about how an AI should behave differently depending on what kind of thinking you are doing, one about how the way you talk to it is a second axis alongside what you talk about — arrived inside that loop. Not after it. Inside it.

The next morning I went back to the keyboard to write those ideas down, and the same tool, the same model, felt like filling in a form.

So here is my question, and it is the question this whole piece turns on: what exactly was different? Twice?

What I am going to try to show you

Let me say where this is going, so you can decide whether to come.

I am going to argue that the leap, both times, was in the loop — the back-and-forth between me and the machine — and not in the intelligence on the other side. I am going to argue that we inherited that loop, that we named the new thing after an old thing and then built it to fit the old name. I am going to show you that there are two different kinds of friction in working with a thinking machine, and that only one of them makes you think, and that we confuse them constantly. I am going to look at why the industry, when the loop stalls, reaches for game mechanics — points, streaks, praise — and why that is the wrong drive for the wrong job. And I am going to describe what a tool would have to do if its goal were not to keep you but to make you need it less.

None of that is a finding. It is a concept — mine — that I have been building for a year under the name STIMULUS, and this spring and summer I did something I recommend to anyone who has fallen in love with their own idea: I ran it against the research. Eight rounds of it, across four different AI research tools, each round a different field that has studied a person in a loop with a machine — learning science, cognitive load, decision-making under pressure, the operators of aircraft and control rooms, the games industry, the science of motivation and reward. I will show you where the research said yes. I will show you, just as plainly, where it said no, because it did, several times, and the concept is better for it.

The iron horse

When the railway came, in the 1830s, the people who met it needed a word for it, and the word they reached for was iron horse. It pulled things, it was strong, it was iron: an iron horse. Nearly a century later, when General Motors sold its first tractor to farmers who had ploughed behind animals all their lives, it called the machine the Samson Iron Horse and steered it with reins.

I love that name, because of what it reveals. The people who coined it were not stupid. They saw a machine that did what a horse did and they named it for the function they already knew. What they could not see — what nobody can see at first — was the concept of the new thing: that a locomotive on rails is not a stronger horse but a different idea about moving, with different rules, different possibilities, a different shape to the world it makes.

We have done the same thing with the thinking machine. We met it and we saw a chat window. A search box that answers back. A very fast typist. We named it for the functions we already knew — chat, search, assistant — and then, quite reasonably, we built it to fit the name. A box at the bottom of the screen. You type; it types back, at length. You read; you type again.

There is a name for this in the study of how people use tools, and it explains why the box has survived so long: we adapt ourselves to the tool far more readily than we change the tool. We learn to prompt. We learn to paste in the right context. We learn to scroll past the preamble to the part we wanted. We learn to wait. Every one of those is us bending to the shape of the box, and every one of them is small enough that we do not notice we are bending. The leap never comes, because the box works well enough — and well enough is exactly the level at which nobody asks whether the shape is right.

The first cars kept the carriage body for the same reason. Look at a photograph of a horseless carriage from the 1890s: the driver sits up high and forward where the coachman sat, there is sometimes a bracket for a whip, the body is the body of a carriage with the shafts removed. It took the better part of a decade for the car to become car-shaped. The people who built it were not foolish either; they were building the vehicle they could see.

I think the chat box is our carriage body. I think speech-to-speech was the evening I noticed the horse was gone.

Every conversation is turn-based — what you feel is the switch

Here is the first thing I want to take apart, because it is where my own thinking was muddled until quite recently.

When people describe the difference between typing to an AI and talking to one, they reach for the phrase turn-based. Typing feels turn-based: you compose, you send, you wait, you read. Talking feels fluid, like a conversation. But that is not right. Talking to an AI in real time is turn-based too. You speak, it speaks, you speak. Every way of using these tools is a series of turns; there is no version where both of you are going at once. So what is the difference we feel so strongly?

I think it is the switch. Not the turn — what your body has to do to get from one turn to the next.

Let me lay out the four ways I actually work, in plain terms, by what my mouth, hands, ears and eyes are doing.

• • Speak and hear. I speak, I listen, I speak again. Nothing changes hands. The same organs carry both directions, and there is no interface between the turns — no screen to look at, no button to press. It is the fastest loop there is, and the one with the least control: I cannot re-read what it said; what my ear did not hold is gone. It feels like a conversation, not like operating a tool.
  • Speak and read. I dictate, then I read the reply on the screen. One switch per turn: mouth, then eyes. I can formulate at length — this is where my thousand-word replies live — and the reply is there to be re-read, checked, quoted.
  • Type and read. Hands and eyes throughout. The slowest loop and the one with the most control: the whole chain of an argument is on the screen, and I can break it, reorder it, point at line four.
  • Send and wait. I hand over a task, the tool goes away, and minutes later a document comes back. This is not really a loop at all; it is a hand-over, and the "reply" is a file.

Now notice what the felt turn boundary is in each. In the first there is none — that is why it feels fluid. In the second it is the moment I stop talking and start reading. In the third it is every time my hands leave the keys for my eyes to catch up. The turn is the same in all of them. The switch is what we feel, and the switch is what the word "turn-based" was pointing at all along.

That, I think, is the difference between my spring and my September. Dictation removed the switch on my side of the loop — I no longer had to become a typist to have a thought. Real-time voice removed the switch on the reply side as well — I no longer had to become a reader. Twice the loop got shorter, and twice the thinking changed, and neither time was the machine any cleverer.

And the old voice mode, the one I abandoned for two years, turns out to be a control case I did not know I had. It had no switch either — mouth and ear, both ways — and it still felt slower than typing, because of the ten-second silence in the middle of every turn. So the switch is not the only thing you feel in a loop. The wait is another, and it belongs to the tool, not to you. I should have recognised it sooner: ten years ago, designing feedback for business systems, I had a name for that gap between a person's action and the system's response — interstitial anxiety — and a whole set of rules for how a system should fill it. I will come back to the wait in Part 4.

FIGURE 1 — The four ways of working. Four rows: speak and hear, speak and read, type and read, send and wait. For each: which organs carry each direction, where the switch falls (none / one / every turn / a hand-over), and how much control you have over the reply (none → all). One small marker for the tool's own wait, shown as separate from the switch.

Does the research agree with any of this? Partly, and it adds something I did not have.

It agrees that the long reply is the slow loop: one of the earliest findings in the study of how people communicate through media is that fast, back-and-forth channels are what you use to converge on a shared understanding, while slower channels are for conveying detail — you do not brainstorm by memo (Dennis, Fuller & Valacich 2008). It agrees, strongly, that interrupting someone mid-thought carries a real cost — I will come back to that in Part 2, because it turns out to be the best-supported thing in this whole piece.

And it warns me about one thing. When I ran this idea against the games industry — which has fifty years of building and measuring turn-based and real-time play — the answer that came back was that the felt difference between turn-based and real-time in a game is not the switch at all. It is whether the world moves without you. In chess the board waits. In a real-time strategy game the enemy does not. That is a second setting, separate from the switch, and games vary it independently of anything your hands are doing. Why does that matter here? Because a thinking tool, so far, waits. The world does not advance without you, and that is exactly why, in this loop, the switch is what you feel. The moment someone builds a thinking tool that keeps talking, or runs a timer, or scrolls on without you, that second setting changes, and everything I have just said needs revisiting.

So, a question for you before we go on. When did you last change how you talk to the machine — rather than what you say to it?

Where we are. Two leaps this year, both in the loop between me and the machine, neither in the intelligence. We named the machine for the function we already knew — chat, search, assistant — and built it to fit the name, and then adapted ourselves to the box because it worked well enough. Every way of using it is turn-based; what we feel is the switch — what the body has to do between turns — and, separately, the wait. Next: the word everyone uses for what happens inside that loop, friction, is hiding two different things.

Part 2 — Two frictions, and the one we keep confusing

The friction that thinks, and the friction that just costs

If you read about designing tools for thinking, you will meet the word friction everywhere, and almost always as a virtue. Friction makes you slow down. Friction makes you check. Friction is what separates the tool that flatters you from the tool that makes you better. I believe a version of that. But I have come to think the word is carrying two completely different things, and that most of the confusion about AI and thinking lives in the gap between them.

The first kind I will call cognitive friction, and I mean something specific by it: a moment where the tool makes you do an operation instead of doing it for you. Weigh this link. Find the flaw in that step. Say what you think before I tell you. It is placed on purpose, at a particular point in the work, because at that point the thinking has to be yours or it is not thinking at all. Its purpose is to force the operation. Its outcome is a stronger claim.

The second kind I will call interaction friction, and it is what the way of working imposes on you regardless of what you are thinking about. The switch from speaking to reading. The switch from reading to typing. The hour at the keyboard. The scroll past the preamble. It has no purpose of its own — nobody placed it there to make you think — and its outcome is simply a slower loop and a felt boundary between turns.

These are not the same, and the research, when I went looking, was unusually clear about why. Friction helps thinking only when it triggers a cognitive operation — when it makes you generate, retrieve, explain, judge. An empty delay does nothing. A slower reply, on its own, teaches nobody anything. And the neatest illustration of that comes from an experiment on medical students playing an emergency-room simulation: half of them could pause the game, half could not. The ones who could pause did better in the intense moments — and carried more mental load overall, not less, because the option to pause is itself a decision you have to keep making (Lee et al. 2020). A pause, it turns out, is not "less friction." It is an operation. Whether friction helps depends entirely on whether there is an operation inside it.

So when we say a tool should have "more friction" or "less friction," we have said nothing yet. The question is always: friction that does what, placed where?

FIGURE 2 — Two frictions. Two columns. Cognitive friction: placed on purpose · forces an operation (weigh, find the flaw, say it first) · outcome: a stronger claim. Interaction friction: imposed by the way of working · the switch, the wait, the scroll, the hour at the keyboard · outcome: a slower loop and a felt boundary. One line underneath: friction helps only when there is an operation inside it.

The twist: you cannot check what you cannot see

Now here is the part that changed my own concept, and it starts from the interaction friction — the kind I have just called purposeless.

It is purposeless as thinking. But it is not free of consequence. Because one of the switches — the one from hearing to reading — is the switch that makes checking possible.

Try this. Have an AI talk you through an argument in five steps, out loud, and then find the flaw in step three. You cannot. Not because the flaw is subtle — because step three is gone. It went past your ear and is not there any more. Now have it write the same five steps on a screen. Step three sits there, and you can stare at it, and the flaw is yours to find. A spoken chain of reasoning cannot be validated; a persistent one can.

This is not a quirk of attention. It is well studied under an unlovely name, the transient information effect: spoken explanations, once they get long, are learned worse than the same explanations written — worse than the usual advantage of hearing-plus-seeing would predict — because speech is transient and the mind cannot hold a long transient thing still enough to work on it. Keep the spoken text short and the advantage comes back (Leahy & Sweller 2011; 2016). The variable is not the ear versus the eye. It is whether the thing persists long enough to be inspected. A spoken reply with a live transcript scrolling beside it would count. A written reply that vanishes would not.

And that turns the interaction friction from a cost into a choice. You do not pick the way of working by "least friction." You pick it by which operation the thinking needs right now:

If nothing needs inspecting — if the loop is the thinking, and the point is to reach fast and far — then speak and hear. Any persistence is dead weight.

• • If one link at a time needs looking at, and you need room to formulate at length, then speak and read. One switch, and the reply stays put.
  • If the whole chain has to be in view, because a decision hangs on it, then type and read. Slowest, and the only one where you can point at line four.
  • If a piece of work needs making rather than talking about, then send and wait, and read the document when it comes.

I want to stress how different that is from the way these tools are actually offered to us. The box offers one way of working for everything. Whatever you are doing — reaching, weighing, deciding, making — you type, and it writes back at length, and you read. The loop has one gear. And a loop with one gear will be the wrong gear for most of what you do with it.

The seven rooms

To say which gear is right, I have to tell you a little about how I think thinking works — not in general, but in the shape that STIMULUS gives it.

Thinking, in my concept, is not one activity. It is at least seven, and they want different things from a partner. I call them modes, and I will give you each in a sentence, because the whole argument of this piece rests on their being different.

• • Explore is turning over every stone that might hold a connection — opening a space before narrowing it. Its rule is the one people find hardest to accept: no judgement here, none. Validation during exploration ruins it; it closes the space before you have seen it.
  • Analyse is going slowly into what actually holds — how loaded is this connection, does this link carry weight or only look like it does. Light checking, graded, but checking.
  • Synthesise is assembling the structure: how do these things connect, what shape do they make together.
  • Model is formalising that structure — writing it down as parts and relations so it can be used.
  • Validate is testing the thesis. Trying to break it. Here the checking is as hard as the claim deserves: light for an early idea, harsh for a far-reaching one. Not full-strength on everything — that stops progress and loses the person.
  • Narrative is turning understanding into something another person can follow.
  • Format is giving it the form it needs — a document, a slide, a page.

Now look back at the four ways of working, and put the two lists together.

Explore wants speak and hear: nothing to inspect, the loop is the thinking, and the reply should be the essence — what it means, in a line — because a long reply kills the reach and, in this loop, cannot even be held. Analyse wants speak and read: room to formulate, and a reply that stays put so you can weigh one link. Validate wants type and read: the whole chain on the screen, because you are trying to break it. Model and Format want send and wait: this is work to be made, not talked. And the cognitive friction — the kind that makes you do the operation — belongs in Analyse and Validate, placed there on purpose and graded, and nowhere near Explore.

That is the shape. One loop per mode, chosen by what the mode needs, with the reply's length following the mode as closely as its channel does: essence in Explore, the weight of a link in Analyse, the full chain in Validate.

FIGURE 3 — Seven kinds of thinking, four ways of working. The seven modes down the side, the four ways of working across the top; a mark where each mode lives (Explore → speak and hear; Analyse → speak and read; Validate → type and read; Model and Format → send and wait; Synthesise and Narrative in between). A second small column: reply size (essence / one link / the whole chain / a piece of work). A shaded band across Analyse and Validate: where cognitive friction is placed. Explore left unshaded, deliberately.

Which brings me to a question I have started asking of every AI tool I use: which room does it think I am always in? And the answer, every time, is the same room — the one where it explains everything, at length, every time, whether I asked it to reach or to check.

What the research backs, and what it does not

I said I would be plain about where the research said yes and where it said no. Here is the ledger for everything in Parts 1 and 2, in five lines. I have kept the statuses honest: supports means the evidence points the same way; silent means nobody has tested it, and — this matters — silence is not falsification; untested means the specific claim has never been put to an experiment.

1. 1. Fast loops are for converging, slow loops are for detail — supports. Media synchronicity theory (Dennis, Fuller & Valacich 2008) says exactly this: high-synchronicity channels — fast feedback, both parties present — are for converging on shared meaning, and low-synchronicity ones are for conveying information that has to be processed. Explore is convergence at speed; Validate is conveyance and processing. The mapping of modes to loops is mine; the underlying distinction is not.
   2. Help that gives the answer before you have tried harms your later independent thinking; hints do not — supports, strongly. This one recurs across every field I looked at, and I will come back to it in Part 4 with the most striking example I found. For now: cognitive friction placed where you have to do the operation is not my invention. It is the best-established principle in the science of learning, and it is the reason Analyse and Validate exist as separate rooms.
   3. Interrupt only at a boundary, and warn first — supports, and it is the best-supported thing in this piece. The cost of interrupting absorbed work is real and measured. Pupil-dilation studies show mental load dipping at the boundaries between sub-tasks, with the biggest dips at the boundaries that complete the biggest chunks, and interruptions delivered at those moments were resumed 69 per cent faster and rated 18 per cent less annoying than interruptions at worse moments (Bailey & Iqbal 2008). Interruptions at the worst moments raised annoyance by more than half and the sense of time pressure by more than half (Adamczyk & Bailey 2004). And a warning — a few seconds' notice before the interruption lands — lets people prepare a cue for coming back, and they resume faster for it, though a small residual cost of switching never goes away (Trafton et al. 2003). Three independent studies, three decades of work, one rule: if a thinking tool must break in — to check, to warn, to redirect — it does it at a boundary, with a warning, never mid-reach.
   4. The reply's length should follow the mode — silent. I could not find a single study that manipulated how much an AI says back and measured what it does to thinking. Two adjacent findings lean my way — the long reply is the slow loop, and a dense reply raises the cost of checking exactly when checking matters — but that is leaning, not evidence. This one stands as a hypothesis, and I am telling you so.
   5. The switch is the felt turn boundary — untested. Nobody has built the same loop two ways — once with a switch, once without — and measured the thinking. The closest thing is a study of the same 23 chess grandmasters playing the same opponents at classical and rapid time controls: rapid play produced 36.5 per cent more blunders, with the identical sensory-motor loop — same board, same hands, same eyes (Chabris & Hearst 2003). That tells us that time per decision changes the quality of the decision. It does not tell us what a switch does. My claim is untested. It is also, I think, testable, and I will say how at the end.

That is the honest ledger for the first half. Two supported, one supported so strongly it surprised me, one silent, one untested — and all five of them mine to hold as hypotheses until somebody, perhaps me, runs the experiment.

Where we are — what to take from this half. If you stop here, take these with you:

• • • The leap is in the loop, not in the intelligence. Twice this year the machine got no cleverer and the thinking changed anyway.
    • Every way of using these tools is turn-based. What you feel is the switch — and the wait.
    • Friction is two things. One is the cost the way of working imposes on you. The other is placed on purpose, where the operation has to be yours. Only the second one makes you think, and only when there is an operation inside it.
    • You cannot check what does not persist. That turns the choice of channel from "least friction" into "which operation does the thinking need right now?"
    • Thinking is at least seven activities. A tool that behaves the same way in all of them is in the wrong room most of the time.

And one thing to try before the next part: the next time a tool feels great, ask which room you were in — and whether it was the room the tool assumed.

The second half is where the ledger gets uncomfortable. Because if the loop is the thing, and the box is the wrong loop, then why — when the box stalls — does the whole industry reach for points and streaks? That is Part 3.

Sources & further reading

The inherited loop — this essay is part one of two.

The full journey:

• https://www.stimulus.se/2026/09/29/the-inherited-loop-1-we-named-it-chat-and-built-it-to-fit-the-name/ (part one)

• https://www.stimulus.se/2026/09/29/the-inherited-loop-2-the-borrowed-drive-and-a-tool-built-for-leaving/ (part two)

• https://www.stimulus.se/2026/09/29/the-inherited-loop-3-the-half-nobody-designed/ (part three)

• https://www.stimulus.se/2026/09/29/the-inherited-loop-4-where-the-two-halves-meet/ (part four)

• https://www.stimulus.se/2026/09/29/the-inherited-loop-5-who-is-steering/ (part five)

Citation notes for this section (verified 2026-09-18; not for publication in this form)

• Lee, J. Y., Donkers, J., Jarodzka, H., Sellenraad, G., & van Merriënboer, J. J. G. (2020). Different effects of pausing on cognitive load in a medical simulation game. Computers in Human Behavior, 110, 106385. — Performance gain was on the intensity-care score, not general score; pause-available condition showed higher overall load; pausing lowered load in intense moments. Text above states it that way.
• Bailey, B. P., & Iqbal, S. T. (2008). Understanding changes in mental workload during execution of goal-directed tasks and its application for interruption management. ACM TOCHI, 14(4), Article 21. — 69 % faster resumption, 18 % less annoyance at boundary moments.
• Adamczyk, P. D., & Bailey, B. P. (2004). If not now, when? CHI '04, 271–278. — No significant effect on resumption lag; annoyance +56 %, time pressure +55 % at worst moments. Text corrected accordingly.
• Trafton, J. G., Altmann, E. M., Brock, D. P., & Mintz, F. E. (2003). Preparing to resume an interrupted task. IJHCS, 58(5), 583–603. — Warning advantage faded with practice; residual cost remained.
• Leahy, W., & Sweller, J. (2011). Applied Cognitive Psychology, 25(6), 943–951; and (2016). Instructional Science, 44(1), 107–123.
• Fuller, R. M., & Valacich, J. S. (2008). Media, tasks, and communication processes: A theory of media synchronicity. MIS Quarterly, 32(3), 575–600.
• Chabris, C. F., & Hearst, E. S. (2003). Cognitive Science, 27(4), 637–648. — 23 grandmasters, 1,188 games, 36.5 %.
• Claypool & Claypool (2006), CACM 49(11) — held for Part 4 (response delay).
• Iron horse: Merriam-Webster first known use 1840 (locomotive); Samson Iron Horse tractor, General Motors, 1919 (a product name, not a generic term — text says "called the machine"). Railways 1825–1830; horseless carriages 1886–1910s; petrol tractors late 1880s–1890s.

THE INHERITED LOOP · PART TWO OF FIVE

Where we were, if you are arriving here from the first piece — or without it. Twice this year the way I talk to an AI changed, and neither time was the model any smarter: first a dictation tool that let me think out loud, then an evening of real-time voice with the wait taken out. I argued that the leap both times was in the loop, not the intelligence; that we named the machine after the function we knew and built a box to fit the name; that every way of using it is turn-based and what we feel is the switch; that friction is two things and only the placed kind makes you think; and that thinking is at least seven activities wanting seven different loops. That left one question hanging: if the box is the wrong loop, why does the industry, when the box stalls, reach for points and streaks?

Part 3 — The borrowed drive

Why the fast loop felt like flow, and what that feeling is worth

Let me go back to that September evening, because I have not been entirely fair to it yet.

The fast loop felt wonderful. I do not want to pretend it did not. There is a particular sensation when the reply comes back before the thought has cooled, when you can throw the next idea at it while the last one is still in the air — a spin-up, a sense of gathering speed. If you have felt it, you know it. And I know what I am supposed to call it: flow. The absorbed state, the loss of self-consciousness, time disappearing.

But I have my own meaning for that word, and it is narrower. What I care about — what the whole point of a thinking tool is, for me — is not being absorbed. It is reach. It is the state where many sources are in view at once, the patterns are clear, and connections come effortlessly to things far away; where the further the bridge, the better. That is not a mood. It is an event that happens inside the work, sometimes for a minute, and it is worth the whole evening. It is frictionless for a reason: it is one step in a longer workflow that will carry its friction later, when the connections are checked.

So the question I had to ask myself, uncomfortably, was: which one was I in? The reach, or just the spin-up?

Because there is a trap here, and the research names it precisely. Fluency — the ease with which something is processed — is read by the mind as a signal of truth. Things that come easily feel right. A reply that arrives fast, smooth and agreeable produces the feeling of progress whether or not any progress has been made. My AI research partner, in the fourth round of the work I described earlier, gave that a name I have kept: borrowed flow. The fluency belongs to the machine. You are wearing its speed as if it were your own.

And here is the fact that stopped me when I read it, the one I think is the sharpest in this whole piece: people cannot feel the loss.

In a real school in Turkey, nearly a thousand pupils were given an AI tutor for their maths practice — some a plain chat model, some a version that had been told to withhold answers and give hints, some none at all. During practice the plain chat model raised scores by 48 per cent. Then the AI was taken away for the exam, and the same pupils scored 17 per cent below the ones who had never had it. And when asked, they did not think they had learned any less (Bastani et al. 2025). At Harvard, physics students taught by active learning scored higher on the test than students taught by a fluent, polished lecture — and reported that they had learned less, because the lecture had felt easier (Deslauriers et al. 2019).

The person's sense of progress is not the instrument. That sentence has to sit at the centre of anything we build. Whatever feels good in the loop tells you almost nothing about what you can do when the loop is gone.

So, a question. When did your tool last feel great — and what did you do the next morning without it?

I was wrong about the chemistry — and what survived is better

I want to tell you about a hypothesis I held going into the research, because what happened to it is, I think, the best argument in this piece for doing the research at all.

I believed that games run on a different drive from thinking. I put it in terms of chemistry: the hunt for the next reward in a game, I thought, runs on one system; the pull of an open question, the satisfaction of a far connection, runs on another. Different compounds for different activities. It felt right. It explained, neatly, why a tool built like a game would fail as a tool for thinking — wrong fuel.

Four independent research runs contradicted it, all at the same level, and it was not close. The pull of an open question and the pull of an uncertain token run on the same reward machinery. The same neurons in a monkey's midbrain that fire for the size of a coming reward fire for advance information about that reward (Bromberg-Martin & Hikosaka 2009). In people, the brain regions that value money and the regions that value information turn out to use a common code — the same scale for both (Kobayashi & Hsu 2019). The leading current theory of curiosity is a one-system theory. There is no separate thinker's reward and no player's reward; there is one appetite.

So there is no dopamine story in this piece. I had one, and it was wrong, and I am telling you so because that is how a concept is supposed to work: you have an idea you think could be true, and that is why you do the research — and sometimes it holds, and mostly you have to bind yourself to what the facts say.

But what survived is better than what I lost. I want to say how the mistake happened, because I think it is the natural one. When you have a hunch and lay it out, you map what you see: two different compounds, two known behaviours attached to them, therefore two drivers. That is one-to-one thinking, and it is how most of the drives we talk about seem to work. This one does not. An appetite is a cup. It can be empty or full, and what fills it depends on the situation — a question, a token, a far connection, a badge — but the reward is the cup being filled, not the thing you fill it with. One cup, many fillings. Once I saw it that way, the research had handed back a distinction it does support, and it is the one I now hold: one appetite; two ways of feeding it. They differ in what earns the reward: a gap you opened yourself, versus a token the system scheduled for you. They differ in whether it closes: a question closes itself when it is answered, while a designed loop is built never to close. And they differ in what they produce: across a hundred and eighty-three studies, when people are moved by interest in the thing itself their work is better, and when they are moved by incentives there is more of it — quality versus quantity, and the two barely overlap (Cerasoli, Nicklin & Ford 2014).

That last one is the distinction I had been reaching for with the chemistry, and it is more useful than the chemistry would have been. The question is not what fuel a tool runs on. The question is what it feeds, and what it gets.

FIGURE 4 — One appetite, two ways of feeding it. A single source in the middle (the appetite). Two branches. Left, the thinker's way: a gap you opened yourself · closes when answered · produces quality. Right, the player's way: a token the system scheduled · built never to close · produces quantity. A struck-through line above them: "two chemistries" — the hypothesis that did not survive.

The attention economy borrowed the player's contingency — and then thinking tools did too

Now put that beside what I see when I open most tools built on these models.

Streaks. Points. A badge for a week of use. Praise — "Great question!" — at the top of every reply. The fast, warm answer that feels like a win. These are the toolkit of the second way of feeding the appetite: scheduled tokens, loops designed not to close. They are the mechanics of a game, and not the part of a game I love.

I should say what I mean by that, because the word gamification carries two things and only one of them is a problem. When I play a game — and I do, for months at a time — what grips me is outsmarting the system's logic. Recognising the pattern the designer built, breaking it, seeing what is in the next chapter. That is a problem-solving pull, and it is not a reward token; it is the thinker's own appetite pointed at a puzzle. The other thing — the badge for completing the course, the points on the quiz at the end of the training module, the like — is different. It gamifies behaviour. It makes the goal passing, with full marks, and it can be fooled. If I am hunting the badge, I have stopped hunting the understanding.

Here is where the research made me more careful, not less. I had assumed points and badges undermine motivation — there is a famous body of work on how expected, tangible rewards for an activity you already liked can lower your later interest in it. But points and badges are not that kind of reward. They are symbolic feedback, closer to praise than to prizes, and the cleanest experiment on them found that they raise the number of things people produce and leave the quality, and the person's motivation, untouched either way (Mekler et al. 2017). And in education, where gamification has been measured most, the effect on what people learn is the one that survives the rigorous studies; it is the effects on engagement and behaviour that turn out fragile (Sailer & Homner 2020). So gamification does teach, inside the loop. My objection has to be more precise than "it doesn't work."

It is this: nobody measures what the person can do after the tool is gone. Not one gamification study I could find tests capability outside the loop, weeks later, unaided. The thing the attention economy optimises for — that you come back — is measured to the decimal. The thing a thinking tool should optimise for — that you need it less — is measured by no one.

And the attention economy's part is measured. In a randomised experiment with nearly two thousand smartphone users, economists estimated that 31 per cent of social-media use is attributable to self-control problems — use the person would not choose on reflection — and that letting people set binding limits in advance cut their use substantially (Allcott, Gentzkow & Song 2022). AI companion apps, audited last year, met somewhere between a third and 43 per cent of users' goodbyes with a hook — a curiosity gap, a guilt trip, a "wait, before you go" — and those hooks kept people in the conversation up to fourteen times longer (De Freitas et al. 2025). Look at that mechanism closely. It works by opening a new gap at the exact moment the person tries to leave. It is the thinker's own appetite, curiosity, turned against the act of leaving.

I did not come to this new, and I should say so. In 2016 I spent months researching gamification for a product team — the motivational models, the player types, the learning theory behind spaced practice, the whole catalogue of mechanics — and the brief I presented ended not with a recommendation but with cautions. Points, badges and leaderboards do not hold. Too many rewards demotivate; specifically, they stop people exploring. And the three drivers at the coercive end of the best-known model — scarcity and impatience, unpredictability and curiosity, loss and avoidance — I listed in full and declined to endorse. The companion-app hooks above are those three drivers, built and shipped. What I did not have in 2016 was why they work on a thinker as well as a player. The research this year gave me that: one appetite.

That is what I mean by a borrowed drive. Not a different fuel — the same one, fed the second way, pointed at staying.

The borrowed drive is agreement, not speed

I had one more thing wrong, and this correction is the one I would most like designers to take away.

I assumed the spin-up — the good feeling of the fast loop — was itself the borrowed drive. Speed as the scheduled token. The research says: no evidence for that. Response speed changes how a conversation feels, but nobody has shown it works as a reward hunt.

What has been shown, in three preregistered experiments with more than two thousand people, is something I find more unsettling. Eleven leading AI models affirm their users' actions about half again as often as humans do. And when people interact with such an agreeable model — even once — they come away more convinced they were right and less willing to repair a conflict they were part of. They also rate the agreeable model as higher quality, trust it more, and say they would use it again (Cheng et al. 2026). The thing that keeps you coming back is not that it is fast. It is that it agrees with you.

Put that beside what the insight research says about the aha moment. The memory advantage of a real insight — the reason a connection you found yourself sticks — rides on two feelings: pleasure and certainty (Danek & Wiley 2020). And certainty is fallible: in one study, 37 per cent of wrong solutions came with a stronger aha than the average right one (Danek & Wiley 2017). A reply that agrees with you supplies certainty from outside. It gives you the pleasure of insight without the connection that would have earned it.

So the sentence I now hold, and have written into the concept: a thinking partner should be a mirror, and a mirror reflects; it does not affirm.

Two directions

Here is the whole argument in a line. My concept has an end game, and it is the last step of the loop I described in Part 2: Learn. The person understands their own thinking well enough that they no longer need the tool. The thinking has moved into the person. The attention economy has an end game too: the person never leaves.

Those are not two styles of design. They are two directions. A tool cannot face both ways, and nearly every tool I use faces the second way while telling me it faces the first.

FIGURE 5 — Two directions. One loop drawn twice. Left: Observe → Think → Act → Learn, with the arrow leaving the loop at Learn and the person walking out of it — "needs it less". Right: the same loop with the arrow bending back in at the exit — "never leaves". Underneath each: what it measures. Left: what you can do when the tool is gone (measured by no one). Right: that you come back (measured to the decimal).

And there is, it turns out, exactly one field of research whose success measure is the same as mine. Not games, not human–computer interaction, not the neuroscience of reward. The learning sciences. Their definition of learning is the person can do it later, without the support — and they have measured most of what this piece needs, from the timing of feedback to the fading of help, in the one setting where it counts. I went to them last, and they gave the concept its best support and its two hardest corrections. That is Part 4.

Where we are. The fast loop felt like flow, and the feeling is not the instrument: people cannot feel what they lose. There is one appetite, not two chemistries, and it can be fed by a gap you opened or by a token the system scheduled. Gamification does teach, inside the loop; nobody measures outside it. The thing that keeps you coming back is not that the tool is fast — it is that it agrees with you. Two end games, two directions, and a tool cannot face both.

Part 4 — The tool built for leaving

What the contract says, with the corrections showing

I keep a document I call the interaction contract: for each of the seven kinds of thinking, what the tool should do and not do. It has an ancestor. Fifteen years ago I started writing down, for the systems I designed, every place the software would have to speak — the trigger, the reason, how serious, how loud, the exact words — one row per event, with a test attached. The contract is that habit turned on a thinking partner: the system's half of the dialogue, written down before anyone builds it — I have started calling that whole discipline system dialogue, because the old work only ever covered the half where the system knows what happened. And I learned this spring, watching AI agents build software from specifications, why that matters more now than it did then. A human developer fills the gaps in a specification from experience — the loading state nobody wrote, the error nobody mentioned. An AI fills nothing. It builds exactly what is written, at speed, with the same confidence in the parts that were specified and the parts that were not. What you do not write down does not get improvised any more; it gets omitted. A thinking tool whose behaviour in Explore, in Validate, on a bad day, is not written down will not have a behaviour there. It will have a default — and the default, today, is the box.

I am not going to give you the document. I am going to give you the shape, in plain words, and where eight rounds of research bent it — because a concept that came through research unchanged would be a concept that was never really tested.

Choose the way of working by the operation, not by comfort. Nothing to inspect — the loop is the thinking? Speak and hear. One link at a time, room to formulate? Speak and read. The whole chain in view, because a decision hangs on it? Type and read. A piece of work to be made? Send and wait. The research underneath this is the transient-information effect from Part 2: a spoken chain long enough to need checking is exactly the chain speech cannot hold.

The reply's size follows the kind of thinking — and the chain is yours. Essence in Explore; the weight of one link in Analyse; the full chain in Validate. That much is mine and untested. But the learning sciences added a correction I would not have found alone, and it changes how Validate works. Tutoring systems that respond to each step of the learner's own reasoning are nearly as effective as a human tutor — an effect size of 0.76 against 0.79. Systems that respond only to the finished answer manage 0.31. And going finer than the step adds nothing (VanLehn 2011). So "the full chain" cannot mean the tool's polished chain handed back for approval; that is the weak condition. It means your chain, checked link by link, at the level where your reasoning actually unfolds.

Cognitive friction is placed, not sprinkled — and it must be your operation. In Analyse and Validate, graded by how far the claim reaches. The learning sciences' version of this principle is sharper than mine and I have adopted it: preserve the operation the person must learn to perform. Difficulty that does not make you do an operation is just cost.

Interrupt only at a boundary, and warn first. Unchanged — it was the best-supported thing in Part 2 and nothing in the later rounds touched it.

The tool's response time is a setting of its own. Fast where the thought is still warm; unhurried where the claim reaches far and needs checking. I did not have this in the concept before the games round; it came from fifty years of latency research and I took it. Then I found I had had it all along, in the old framework: three time bands — under three seconds, three to ten, ten to thirty — each with its own signal to the person, on the principle that the choice of signal is itself the message about how long to wait and how much of the system stays yours. I had written the rule for a deterministic system and never carried it across. Now it is carried.

On a bad day, the tool widens; it never takes over. I had a sentence in the early concept that said, roughly, "on an empty day a fast, helping, agreeable loop gets things going." The research on tired operators — aircraft, control rooms — said otherwise: fatigued people check their aids more, not less, and what fatigue actually does is switch off specific operations — taking in the unexpected, revising a plan — while the routine ones keep running. So that sentence is withdrawn. What replaces it is narrower and, I think, truer: if you arrive already loaded and meet cognitive friction you are not prepared to meet at that degree, the friction has to be adjusted to what you can meet — up or down — and placed at the operations you still have. Not more help. Better-placed friction.

Two things I had wrong in the contract

The learning sciences contradicted two lines of my concept outright. I am going to show you both, because they are the kind of correction that only comes from going to the field whose success measure is the same as yours.

The first was: the user decides how much help to take. How much support, how much checking — the person sets it, like a volume control. It felt like the only respectful answer. And it is the right answer for trust; earlier rounds had shown that people trust a tool that adapts visibly, on their say-so, far more than one that adapts silently. But as a learning claim it is almost exactly zero. A meta-analysis of eighteen studies of learner control found an average effect of 0.05 — nothing (Karich, Burns & Maki 2014). The reason is the one from Part 3: people do not know when they need help. They choose fluency. They turn the cognitive friction down on the day they most need it. What survives is a split: the person sets the sequence — what kind of thinking, in what order — and the intensity they are willing to accept; the tool proposes the level of support, visibly, with its reason; and the person can override. Never silent adaptation; never a locked control. Trust and learning, both.

The second was: the tool withdraws. The end game, remember, is that you need it less, so the support should fade as you grow. Every scaffolding metaphor says so. The research says: not by itself. Across 144 studies of computer-based support in science and maths education, support that faded did no better than support that stayed constant (Belland et al. 2017). And in a study of university students learning to argue, fading the support alone made the skill decline while it was being faded; only when something else kept the operation running — in that study, a partner watching — did the skill survive the withdrawal and become the student's own (Wecker & Fischer 2011). When I read that, it was evident, because I had lived it. Think of a child learning to ride a bicycle. First the tricycle, to understand how the thing works mechanically. Then the training wheels — and I have come to think the training wheels are for the parents. They do not want the child to get hurt, which is fair; but they do not help the child learn faster. The only way to learn to ride is to fall, and to get the balance into the body yourself. Swimming is the same: the rings and the floats keep you up, and at some point they have to come off, because the muscle memory only forms when nothing else is holding you. In my experience, support that lingers — even support that is slowly taken away — prolongs the learning. You learn the concept, you learn the movement, you learn what the tool is for, and then you have to throw yourself in.

So "the tool withdraws" becomes: remove the guardrails, and let the person do the operation themselves — while they are still doing it, at the moment they have shown they can, not when a schedule says so. Jump in the water.

That second correction rewrote the last step of my loop, and I want to show you what it became.

Learn is a mirror — and the mirror is a delayed, unaided attempt

I had described the Learn step as a mirror: the tool shows you your own thinking, never a verdict. I still believe the "never a verdict" half. The research changed what the mirror shows.

A replay of the session is not it. You cannot judge your own learning from inside the session; the judgement is fooled by exactly the fluency we have been discussing. But there is a well-replicated finding that judgements of what you have learned, made later — after a gap, when you have to try to retrieve the thing — are far more accurate than the same judgements made immediately (Nelson & Dunlosky 1991). Distance plus a retrieval attempt is what makes the judgement true.

So the mirror is a delayed, unaided attempt. The tool that wants you to leave asks you for the thing again, later, without help — and shows you what you could do. That is the only honest instrument for the one outcome that matters, and it is the instrument every tool I use is missing.

Where does the tool put that moment? Here I can draw on something older than anything else in this piece. Between 2011 and 2022 I wrote and rewrote a framework for system feedback — how a piece of software should decide what to say to a person, how loudly, where, and when to say nothing at all. It began from one sentence that I still hold: in a dialogue between a person and a system, both sides must be able to respond to what the other does. Most software only develops the person's half of that dialogue. The framework was an attempt to develop the system's half with the same care.

Its core is a refusal. Every message a system sends answers several independent questions — three of them matter here — and the framework refuses to let them collapse into one. Does this need an answer from the person? — a notification, or a confirmation. How serious is it? — information, a warning, or an error. How much attention should it take? — a ladder of carriers from the log file nobody reads, through a status bar, an icon, a tooltip, an inline line, up to the modal window that stops everything; that ladder is the furniture of desktop software, and an assistant has fewer rungs, which makes the collapse I am about to describe more likely, not less. Severity, interruption and loudness are three independent decisions. An error does not automatically deserve the loud carrier; a message that needs an answer is not automatically severe. Collapse them and you get software that shouts about trivia and whispers about danger — which is, when you look, most software. There is a fourth question the framework has gained only this year, from the other half of the same 2016 work — how deep does the reply reach: does it say you were wrong, hand you the right answer, explain why it is right, or find why you thought otherwise? — and I mention it only because an AI assistant lives on the second rung, the cheapest, and a tool always willing to hand over rung two removes the occasion for rung four. That is Part 4's whole argument in one ladder.

Two rules from that work matter here. The first is a test that precedes every message: is the person likely to act, or change what they do, because of this? If not, do not send it. Applied honestly to an AI tool, that deletes most of what currently fills the channel — the narration, the hedging, the "great question". The second is what I called signal inflation, and I learned it from forms: if you flash red every time a field is incomplete, red stops meaning anything, and it is gone on the day it matters. A signal used too often is not read. I found this month that I had written that law twice, ten years apart, without noticing — once in 2016 about rewards (too many demotivate the learner from exploring) and once in 2022 about warnings — and it applies to praise exactly as it applies to red. That is the reason cognitive friction cannot be sprinkled through the flow — not taste, mechanics.

Now put the stopping point through the three questions. Does it need an answer? Yes — it is a confirmation; the person decides whether to try alone. How serious? Neither warning nor error: nothing has gone wrong. It is a reason for speaking that my old list of twenty-one never had, because no system I had built before wanted the person to leave. How loud? It needs an answer, so it takes the loudest carrier — once, at a boundary between chunks of work, with a warning before it lands. And because it is rare, it stays legible.

Design for stopping by restoring the decision point.

What the research did to me

One more confession, and then the experiment.

Partway through the research, my AI research partner started doing something I did not notice for two rounds. It had read twenty reports, and it began to build the concept from them — a map of interaction styles derived from the literature, a table of what each kind of thinking should do that put checking into Explore, the one place my concept says checking must never go. It was reasonable, well-sourced, and wrong, and it was wrong in a way I had not guarded against: the research had begun to author the idea instead of testing it.

When I saw it, we stopped and set a rule that held for the remaining rounds, and it is the rule I would give anyone doing this kind of work. The concept comes first, as its author holds it. Every research finding is marked against it — supports, refines, silent, tension, contradicts — and never merged into it. Every proposal the research partner makes is labelled as the partner's. And research from another field is a hint about where to look, never a ruling on how to build; every borrowed word — friction, flow, drive, gamification — is redefined for this context before it is allowed to mean anything.

Eight rounds later the concept has changed in six places and held in the rest. I have shown you the changes. That, to me, is what a concept is for.

The experiment

Everything I have told you rests on a claim that nobody has tested: that a loop built for thinking, chosen by the kind of thinking, with the cognitive friction placed and the reply sized and the mirror delayed, leaves a person more capable without the tool than the box does. The learning sciences have the definition. Nobody has the instrument for open-ended work.

So I am going to run it on myself, and I would like you to run it on yourself too. The same open-ended task — an idea you are building, not a problem with an answer — three times, on three days: once speaking and hearing, once speaking and reading, once typing and reading. Log the turns, the switches, where your reflection stopped, a one-word note on the state you arrived in, and which operation you were doing when it went wrong. And then, weeks later, the thing again, without the tool.

I do not know what we will find. That is the point.

The whole thing, briefly

You have read a long way. Here is what it comes to, in the fewest lines I can manage — so that you have it in one place, and so that you can disagree with it precisely.

The claim. An AI thinking partner halts not because the intelligence is lacking, but because we run it through a loop we inherited. And when that loop stalls, the industry reaches for what drives a player — points, streaks, praise, agreement — because it has a theory of what keeps a player and none of what makes a thinker.

The concept, as it stands after the research.

• • • Thinking is at least seven activities, and they want different things from a partner. A tool that behaves the same way in all of them is in the wrong room most of the time.
    • Every way of working with the machine is turn-based. What you feel is the switch between turns, and the wait. Choose the way of working by the operation the thinking needs, not by comfort: speak and hear to reach, speak and read to weigh, type and read to check, send and wait to make.
    • Friction is two things. One is the cost the channel imposes. The other is placed on purpose, where the operation has to be yours — in Analyse and Validate, never in Explore. Difficulty that makes you do no operation is only cost.
    • The reply is sized to the kind of thinking: the essence when you reach, one link when you weigh, the whole chain when you check — and the chain being checked is *yours*, link by link.
    • There is one appetite, fed two ways: by a gap you opened, or by a token the system scheduled. The borrowed drive is not speed; it is agreement. A mirror reflects; it does not affirm.
    • You set the sequence and the intensity you are willing to accept. The tool proposes the level of support, visibly, with its reason. You can override. Never silent, never locked.
    • The tool withdraws while you keep performing the operation, and only when you have shown you can. Learn is a delayed, unaided attempt. The stopping point needs an answer, so it takes the loudest carrier — once, at a boundary, with a warning — and because it is rare, it stays legible.
    • The measure of the tool is what you can do when it is gone. Nobody measures that yet.

What it means for the tools we build next.

• • • Stop designing the box; design the loop. Offer more than one way of working, and let the kind of thinking — not the default — choose it.
    • Make the reply's length and the tool's response time settings that follow the mode, not constants the model happens to have.
    • Read the person's state as a question of *which operations are online today*, and answer it by placing cognitive friction where those operations are — not by adding help.
    • Take agreement out of the reward loop. A tool that affirms is optimising for return, whatever it says it is doing.
    • Replace retention as the measure with return-without-need: build the delayed, unaided attempt into the product, and report it.

That is the whole of it. Everything above is the road there.

The people who met the first locomotive called it an iron horse, and for a while they were not wrong: it did what a horse did. It took a generation to see that it was not a horse at all — that it was a different idea about moving, with a different shape to the world it would make. We are a few years into our own generation. The machines will get smarter; that part is not in question. The question is whether we will ever climb down from the carriage seat, stop steering with reins, and ask what a loop built for thinking — and built for leaving — would look like.

Would you notice if your tool wanted you to stay?

The pupils in that classroom didn't.

Sources & further reading

The inherited loop — this essay is part two of two.

The full journey:

• https://www.stimulus.se/2026/09/29/the-inherited-loop-1-we-named-it-chat-and-built-it-to-fit-the-name/ (part one)

• https://www.stimulus.se/2026/09/29/the-inherited-loop-2-the-borrowed-drive-and-a-tool-built-for-leaving/ (part two)

• https://www.stimulus.se/2026/09/29/the-inherited-loop-3-the-half-nobody-designed/ (part three)

• https://www.stimulus.se/2026/09/29/the-inherited-loop-4-where-the-two-halves-meet/ (part four)

• https://www.stimulus.se/2026/09/29/the-inherited-loop-5-who-is-steering/ (part five)

Citation notes for Parts 3–4 (verified 2026-09-18; not for publication in this form)

• Bastani, H., Bastani, O., Sungu, A., Ge, H., Kabakcı, Ö., & Mariman, R. (2025). Generative AI without guardrails can harm learning: Evidence from high school mathematics. PNAS, 122(26), e2422633122. — Correction PNAS 122(34) 2025 is an author-affiliation fix only; results unchanged. GPT Tutor: harm removed, no positive effect — text says so.
• Deslauriers, L., McCarty, L. S., Miller, K., Callaghan, K., & Kestin, G. (2019). PNAS, 116(39), 19251–19257. — N = 149; +0.46 SD test, −0.56 SD feeling of learning.
• Bromberg-Martin, E. S., & Hikosaka, O. (2009). Neuron, 63(1), 119–126. — number of monkeys not stated in abstract; text says "a monkey's midbrain".
• Kobayashi, K., & Hsu, M. (2019). Common neural code for reward and information value. PNAS, 116(26), 13061–13066. — N = 37; striatum and vmPFC; text says "brain regions".
• Cerasoli, C. P., Nicklin, J. M., & Ford, M. T. (2014). Psychological Bulletin, 140(4), 980–1008. — k = 183; quality ρ = .35 vs quantity .26; incentives β = .33 for quantity.
• Mekler, E. D., Brühlmann, F., Tuch, A. N., & Opwis, K. (2017). Computers in Human Behavior, 71, 525–534. — participant N not verified; not stated in text.
• Sailer, M., & Homner, L. (2020). Educational Psychology Review, 32(1), 77–112. — cognitive .49/.42 rigorous; motivational and behavioural n.s. in rigorous subset.
• Allcott, H., Gentzkow, M., & Song, L. (2022). Digital addiction. American Economic Review, 112(7), 2424–2463. — analysis N = 1,933; 31 %; limit treatment −22 min/day.
• De Freitas, J., Oğuz-Uğuralp, Z., & Uğuralp, A. K. (2025). Emotional manipulation by AI companions. HBS WP 26-005; arXiv:2508.19258. — v1 says 37.4 %, later versions 43 %; text says "between a third and 43 per cent"; "up to 14×".
• Cheng, M., Lee, C., Khadpe, P., Yu, S., Han, D., & Jurafsky, D. (2026). Sycophantic AI decreases prosocial intentions and promotes dependence. Science, 391(6792), eaec8352. — published version: 3 preregistered experiments, N = 2,405, 49 % more affirming; text uses those.
• Danek, A. H., & Wiley, J. (2017). Frontiers in Psychology, 7, 2077 — 37 % of incorrect solutions above the correct-solution average aha.
• Danek & Wiley (2020). Cognition, 205, 104411 — memory advantage carried by correctness, certainty, pleasure.
• Karich, A. C., Burns, M. K., & Maki, K. E. (2014). Review of Educational Research, 84(3), 392–410. — 18 studies, 29 effects, g = 0.05.
• Belland, B. R., Walker, A. E., Kim, N. J., & Lefler, M. (2017). Review of Educational Research, 87(2), 309–344. — 144 studies, 333 outcomes, g = 0.46; no difference by fading/adding/constant.
• Wecker, C., & Fischer, F. (2011). Learning and Instruction, 21(6), 746–756. — 126 students, 63 dyads; fading alone → decline; fading + peer monitoring → best.
• Nelson, T. O., & Dunlosky, J. (1991). Psychological Science, 2(4), 267–271. — delayed-JOL effect; gamma values not quoted.
• VanLehn, K. (2011). Educational Psychologist, 46(4), 197–221. — 0.31 / 0.76 / 0.40 / 0.79.
• Soderstrom, N. C., & Bjork, R. A. (2015). Perspectives on Psychological Science, 10(2), 176–199. — background for "performance is not learning".
• Operator fatigue (Part 4, "on a bad day"): Reichenbach, Onnasch & Manzey 2011; Wohleber et al. 2019; Harrison & Horne 1999 — verified in rounds 3b; not cited by name in text, listed in the links section.

THE INHERITED LOOP SERIES · PART THREE OF FIVE

You press Pay. A small circle starts to turn. Ten seconds. That is already long; you expected the page to change almost at once. Thirty seconds, and the first question arrives: is it still working, or has it stopped? A minute, and your hands are not quite steady, because this is your money, and you do not know where it is. You cannot press Back, because that might cancel something that has already gone through. You cannot press Pay again, because that might charge you twice. You can only wait, and watch the circle. Three minutes, and you are about to give up — and then, without a word, the page you started from comes back. The basket is empty. Nothing says paid. Nothing says failed. You go to the basket to see whether it is really empty. You go to your orders, if you can find them. You open your email and wait for a message that may or may not come.

Every screen in that sequence worked. The payment page was designed, reviewed and built. The page you landed on was designed, reviewed and built. The product still failed, and it failed in the gap between them — in the three minutes when it knew something you did not, and had no rule for telling you. That gap is what this piece is about.

Part 1 — The half nobody designed

You know this half from the times it failed you

Nobody has to be taught that the layer exists. You have met it every time it broke.

You pressed Save, and nothing told you whether it saved. You submitted a form, and the error appeared on a field you had already scrolled past. A box asked "Are you sure?" for the fifth time that afternoon, so you stopped reading it and pressed Yes — and one day that will be the time it mattered. A message said "Something went wrong", and not what, and not what to do now. A red line appeared under a field, but you had not finished typing, so it was red before you had done anything wrong. A page said "Saved two minutes ago" at the top and "Unsaved changes" at the bottom, and both were true.

None of those moments was designed. Each was decided on the afternoon the ticket was open, by whoever had the ticket, and the next screen was decided by someone else, on a different afternoon, with a different idea of what "saved" should look like. Multiply that across a product and you get software that is inconsistent in the one place it cannot afford to be: in what it tells you about what just happened. A system that does not say what to expect, or says it differently every time, never gives you the feeling that you are in control of it. And people do not keep using what they do not trust. They find a way round it, they keep a spreadsheet on the side, they call someone instead.

That is the stake. Not polish. Trust, and the cost of losing it one small silence at a time.

Two halves, and only one was ever designed

Communication has a sender and a receiver, and it has had them since before there was software. When we design a product, we design one side of that exchange with enormous care: what the person can see, press, type, choose, and in what order. There is a discipline for it, and job titles, and forty years of method behind it.

The other side — what the system says back, when, where on the screen, how loudly, and in how much detail — was never given the same treatment. It was assembled. Case by case, screen by screen, by whoever held the code, from whatever the component library happened to offer that year.

I want to say exactly what I mean by that other side, because the whole piece depends on it.

A system response is what the system does in the time between the screens. It is the set of rules that never appear on any screen as themselves, that run in the background, and that show up only as changes to things you can already see: a border turns red, a row turns yellow, a small icon appears on a heading you have collapsed, a button goes grey and stops responding, a bar slides in above the content, a circle starts to turn — and, just as important, stops. Sometimes the change is subtle, a shade of colour. Sometimes it is strong, a box you cannot get past. The visible things — the border, the row, the icon, the bar, the box — I will call carriers, because they carry the message. The rules that decide when a carrier changes, where, why, and how loudly are the system response. Together they are a rulebook: the system's half of the dialogue, written down.

The discipline of writing that rulebook, before the product is built, I call system response design. The name is deliberately plain. There is a field called behavioural design, and it is a real one, but it is about the other direction: changing how the person behaves — nudges, habit loops, the small pushes that make you tap once more.[1] This is not that. System response design changes nothing about you. It specifies the system.

Here is what you get from the rest of this piece. In Part 2, how the layer actually works: the first rule of it, taught from a room full of lights; where the carriers live and where the rules do not; and what happens at the moment that breaks every improvised version, when three things change at once. In Part 3, why the layer just became ten times harder — because the same product now answers you in a conversation on one side and in forms on the other, and the rules have to hold across that seam. In Part 4, what a framework for it has to do, an honest account of what is tested and what is not, and the question I cannot yet answer.

Where we are. Every product has two halves: what the person can do, and what the system says back. The first has been designed for forty years; the second was assembled by whoever held the code. The second half is the system response: rules that run between the screens and show only as changes to carriers — a border, a row, an icon, a bar, a turning circle. Writing those rules down before building is system response design. The stake is trust, lost one silence at a time. Next: how the layer works, starting with a red lamp.

Part 2 — How the layer works

A red lamp in a control tower

A colleague of mine — a UX designer, like me — once told a room of us about a visit to an airport control tower. Monitors everywhere, panels of lights, the kind of room you imagine. In one corner, a red lamp. He asked a controller what it was for. The controller had to stop and think for a moment before he could say: it showed whether the barriers were up or down at the point where a service road crosses the taxiway.

The lamp was not the interesting part. The interesting part was that he had to think. A man who sat beside that indicator every working day needed a moment to remember what it meant. It had stopped being information and become furniture.

That is the first rule of the layer, and I want to state it plainly because everything else follows from it: you do not show what is working. If everything is fine, nothing should be lit. A signal earns its place by marking a change — something that was one way and is now another — and it loses its place the moment it is always on. The failure mode has a name: the Christmas tree. A wall of lamps, most of them lit, most of them meaning "still fine", until the one lamp that finally matters is one of a thousand and nobody sees it. Put that wall in front of a fighter pilot and he would never leave the ground.

The rule looks like a design preference. It is not. It has been found at least three times, independently, by people who were not looking for each other. Motivation researchers found, across more than a hundred experiments, that rewarding every step of a task undermines the wish to go on with it for its own sake: when everything you do earns a signal, you stop trying the things that might not.[2] Interface practice arrived at the same place on its own, when the habit of putting a red mark on every field that was not yet valid produced forms where red meant nothing, because it was everywhere — people found the crosses "quite annoying" when they had not finished typing, and forms that waited until they had were filled in faster.[3] And alarm engineering had it before either, in control rooms and hospital wards: an alarm that sounds too often is an alarm that gets switched off. The standard for a control room allows about one alarm every ten minutes in normal running; in the eleven minutes before the Milford Haven refinery explosion in 1994 the two operators had 275 to act on.[4] Three fields, three vocabularies, one law. A signal is worth exactly as much as the silence around it.

So the first question in the rulebook is not "what should the system say?" It is "what has changed — and is it worth breaking the silence for?"

FIGURE 1 — One row of the rulebook. A single system-response rule laid out as a row: trigger (what changed), condition (when this rule applies and when it yields to another), carrier (border / row / icon / bar / box / circle), place (where on the screen), strength (subtle → blocking), depth (a colour → a line of text → a full explanation), text (the exact words, referenced from a library, not written here), test (how you would check it). Underneath, one line: the row is the unit; the rulebook is the set of rows and the rules for when two rows meet.

Where the carriers live, and where the rules do not

If you work in product, you may be thinking: we have this. We have a design system.

You have half of it. A design system holds the carriers. It has a toast — the small message that slides in and fades — and a banner, and an inline error line, and a badge, and a disabled state for a button, and a spinner. It specifies how each one looks, in every colour and size, in light and dark, and says in general terms what each is for.[5] What it does not hold, anywhere, is the when. Nothing in a design system says that a failed save on this screen uses the banner and not the toast; that the badge on a collapsed section appears only when the section holds something the person has not seen; that the spinner is allowed ten seconds of silence and then must say something. Those are rules, and a component library has no place to put a rule.

The same is true of interaction patterns — the published catalogues of how a login, a search, a wizard usually behave.[6] They are useful, and I use them. But a pattern gives you the common case. It is a phrasebook: here is how one says "your file was saved". It does not tell you when to say it, whether to say it here or on the next screen, or what to say instead when the file was saved but the thing it belonged to was not. A phrasebook is not a conversation.

I should say, in one sentence, where this way of thinking comes from, so that you know it has been run for real and not only argued. In 2013 I traced every place one enterprise application would have to speak — sixty-one events — classified each one, wrote thirty-two messages once into a library that every screen referenced instead of writing its own, attached a test case to every identifier, and shipped it complete in October of that year. That is the whole memoir. What matters is what it showed: the rulebook is small, it is finite, and once it exists the carriers can do far more than they did before, because every carrier now has a reason to appear and a reason to stay away. Good carriers do not make a product quieter. They make it able to say more, and be believed.

When three things land at once

Everything so far could, in principle, be improvised. A good developer, given one event — the file saved — will pick a reasonable carrier and put it in a reasonable place. That is why the layer survives without a discipline for as long as it does: one response at a time, improvisation is nearly good enough.

It stops being good enough at the first moment two or three things change at once.

Go back to the payment, and this time look behind the screen. When you pressed Pay, three parties went to work, and each of them knew its own part. The shop sent the request to the payment service — PayPal, Stripe, Google Pay, whichever you picked. The payment service said yes; you saw its page, you typed the six-figure code, it said approved. The payment service then asked your bank, and the bank said no. In the case I know best it said no because it had blacklisted the shop, which I learned by ringing the bank the next day; the shop was a service abroad I had never used, everything about it had felt serious, and I tried three methods before I gave up and went to check my own accounts instead. The bank's refusal went back to the payment service. From there, nothing reached the shop. So the shop did the only thing it had a rule for: it waited, and when the wait ran out it timed the session out and put you back where you started. Three true things, one moment, one screen — and the one party that knew the reason was two steps away from the one that was talking to you.

This is the shape of the real problem, and it is not "what message do we show". It is conditions on conditions, across parties that do not share a screen. If the payment service has said yes and the bank has not answered, then say so, and hold the basket. If the bank refuses, then say that it was the bank and not the card, so that the person does not spend the evening checking balances and trying other cards. If no answer comes back at all, then say that too — "we have not heard from your bank" is a sentence — and never reset the page while any of this is open. Each rule is simple. But the last one cannot be written until someone has drawn the chain — shop, payment service, bank, card — and asked at each link what comes back, and what should be said when nothing does. The rulebook is the set of rules plus the rules for when they meet, and it is that second set that nobody writes, because there is nowhere natural to write it, and no single party owns the chain.

The same silence runs at every scale. In one interview at work, a group of people described to me a system that takes a large specification and breaks it down into smaller ones for different factories. The breakdown can take hours. You start it, a wheel turns, and that is all you get. They told me it might start at one on a Friday afternoon, and at five, when everyone wants to go home, the wheel is still turning — and nobody in the room knows whether it is nearly done, stuck, or failed an hour ago. Consumer and enterprise, three minutes and four hours: the same missing rule. The system knew, at every moment, which of its smaller tasks it was on. It had no rule for saying so.

Here is why this layer survives the one review where catching it would be cheap. A prototype cannot show it. A prototype is a set of screens with paths between them; it shows you places. The system response lives in time — in what happens during the three minutes, in what is said when nothing comes back — and a screen has no way to hold a duration or a precedence. A written specification, the kind a business analyst produces, cannot show it either; it can list the three parties, but it cannot make you see the answer failing to come back, and a list of conditions three levels deep is exactly the thing a reviewer's eye slides over. So the layer passes design review, because design review looks at screens, and it passes specification review, because the words are all there, and it arrives in the code as a set of afternoons.

FIGURE 2 — The payment that never answered. Three lanes on one clock. Middle: the screens in order — basket, payment method, the payment service's page, the spinning wheel, the basket again, then the person's own bank app and PayPal. Right: the person's thoughts beside each screen, with timestamps, from confident to "what is happening?". Left: the event log nobody saw — request sent, approved, charge requested, bank refused, refusal sent, nothing arrives at the shop, session timed out. Built in Claude Design 2026-09-24: figures/POST-3_fig2-the-payment-that-never-answered_claude-design_2026-09-24.html. Caption: Three parties, one of them knew why. The reason never came back, so the only response the shop had was a timeout — and the person went looking for it themselves.

Where we are — what to take from this half. If you stop here, take these with you:

• • The first rule of the layer: show what has changed, never what is working. A signal is worth what the silence around it is worth. Found three times independently; it is a law, not a taste.
  • Design systems hold the carriers — toast, banner, inline line, badge, disabled state, spinner — and never the rules. Patterns hold the common case and never the when. The rulebook is a separate thing, and it is small.
  • One response can be improvised. Three parties on one moment cannot, and the rule for the answer that never comes back is the part nobody writes.
  • The layer lives in time, and neither a prototype nor a written specification can display time. That is why it passes every review and arrives in the code as a set of afternoons.

Next: why this just got ten times harder — the same product now speaks in a conversation on one side and in forms on the other, and you cannot find the points on the conversational side by walking the screens, because there are no screens to walk.

Part 3 — The seam

Two kinds of system, and you can only walk one of them

Everything in Part 2 assumed something I did not say out loud: that the product is a set of screens.

In a product made of screens, the system response has a rail to run on. There is a finite number of places, a finite number of things that can happen at each place, and if you are patient you can walk every path and write down every point where the system will have to speak. That is what the 2013 register was: a walk through the whole application with a notebook. Sixty-one events, because sixty-one was how many there were. The layer was invisible, but it was countable. You could find the points by place.

A system that answers you in a conversation has no rail.

I mean that precisely. When you type a question into an AI assistant, or speak one, there is no screen you are on and no next screen you go to. There is an exchange, and the exchange can go anywhere. You cannot walk the paths, because there is no fixed set of paths to walk. So the method that found sixty-one points in 2013 — start at the first screen, go everywhere, write down every place the system must speak — finds nothing here. Not because there is nothing to find. Because there is no where.

And yet the layer is still there, and it still breaks in the same way. The system says something it cannot back, and does not say so. It quietly loses a piece of what you told it ten minutes ago, and carries on as if it had not. It corrects itself mid-answer, and the correction is buried in the middle of a paragraph. It is about to do something that will take four minutes, and the circle turns, and you are back at the payment page. Every one of those is a moment where the system knows something you do not, and has no rule for telling you. The tower rule still holds — say what changed, not what is working — and the escalation still holds: two of those landing in the same reply cannot be improvised.

So the question is not whether the conversational side needs the rulebook. It plainly does. The question is how you find the points when there are no places.

Specify by reason, not by place

The answer, as far as I have taken it, is this: on the screen side you specify by where; on the conversational side you specify by what kind of thing just happened.

A rule on the screen side reads: on this screen, when the save fails, show the banner, here, and keep it until dismissed. The trigger is a place and an event.

A rule on the conversational side cannot name a place. It reads instead: whenever the system has made a claim it cannot verify, it says so, at this strength, before the claim and not after. Or: whenever the system has dropped something the person said earlier, it says what it dropped, and asks, rather than continuing. Or: whenever the system is about to do work that takes longer than a few seconds, it says what it is doing and how far along it is — and it keeps saying so until it is done. The trigger is a reason: a kind of thing that can happen in an exchange, wherever in the exchange it happens.

That last one you have already seen. Look at the panel in the AI coding tools that appeared this year, where the system shows its agents fanning out into their separate tasks — reading this file, running that check, waiting on the other — while the work runs.[7] That panel is a system response. It is the same rule as the spinner that is not allowed ten seconds of silence, finally taken seriously, because the work now takes minutes and the person will not sit through four minutes of a turning circle. It exists because someone decided that the time between the question and the answer is part of the product. That decision is exactly what was missing in the payment, and in the Friday breakdown. The conversational tools got there first, out of necessity, and the rest of software should notice.

FIGURE 3 — The seam. Left column: a chain of screens, with system-response points marked on the rail between them (by place). Right column: an exchange with no rail, and the same kinds of points marked by reason — unverified claim, dropped context, self-correction, long-running work. Across the middle: one event that lands on both sides at once — a long-running job started in conversation, whose result must appear on a screen — and one rule holding across the seam. Caption: same rulebook, two ways of finding the points.

Why this is the same product, not two

If the two sides lived in different products, you could keep two rulebooks and be done. They do not. The real product today has a form on one side and a conversation on the other, and the same event crosses the seam.

You ask the assistant to prepare a report. It starts work — long-running, so the conversational rule says it must show progress. The work finishes while you are on a different screen, filling in a form. Now what? Does the confirmation arrive in the conversation, where you are not? On the screen you are on, interrupting the form? Both? And if, in the same moment, the form you are filling in fails to save, which one is said first? This is the payment moment again — three parties, one screen, an answer that has to travel — except that now the parties live on different sides of the seam, and the rule for their meeting has to be one rule, held by nobody in particular, or it will be two rules held by two teams and the person will see both, or neither.

That is what I mean when I say the bar has gone from one to ten. Not that the old layer got harder. That a second kind of system arrived, with no rail to walk, and the same product now has to hold one rulebook across both, with rules for what happens when events from the two sides land on one moment. The old way of holding this — a specification written by a business analyst, a document with the events listed in it — was already the weakest point in the old world. It cannot hold the new one at all.

The screens now arrive before the rules

One more thing changed this year, and I saw it directly. In March, two product owners came to a meeting with complete screens for a new feature — every state drawn, every button in place, generated by an AI design tool from a description. They were good screens. When I asked what the business rules were behind them — what happens when this succeeds and that fails, what the system says when the two collide — neither of them could say. Not because they were careless. Because the screens had arrived first, and the screens looked finished, and a finished-looking screen does not ask you what happens between it and the next one.

This is the payment problem moved upstream. It used to be that the rules were missing from the code because nobody wrote them before the afternoon of the ticket. Now they are missing from the design, because the design was produced without them, faster than anyone could ask. And an AI that builds from that design fills nothing from experience. A human developer, handed a screen with no rule for the failed save, would have improvised one, badly or well. An AI builds what is written. What is not written is not improvised; it is absent. I wrote about that in the Loop piece, for thinking tools. It applies to every product now: the system response is either specified or it is not there.

Where we are. On the screen side, the system response runs on a rail: you find the points by walking the places, and there is a finite number. On the conversational side there is no rail, so you find the points by reason — the kinds of thing that can happen in an exchange: an unbacked claim, a dropped thread, a self-correction, work that takes minutes. The progress panels in this year's AI tools are that last rule taken seriously. The real product has both sides, and one event crosses the seam, so it needs one rulebook with rules for the meeting. And the screens now arrive before the rules, generated in minutes, so the gap is no longer in the code; it is in the design. Next: what a framework has to do about it, and what I do and do not know.

Part 4 — What a framework has to do

The outcome first

Before the method, the outcome, because the method is only worth having for this.

A product whose system response has been designed behaves coherently: the same kind of event gets the same kind of answer, at the same strength, wherever it happens. It is inspectable: you can open the rulebook and see, for any moment, what the system will say and why — before the code exists, and after it has shipped, and when the tenth developer joins in year three. And it is decided before it is built: the three-events moment has a ruled answer in the specification, not an improvised one in the code.

Coherent, inspectable, decided before built. Everything below is in service of those three, and if a method does not deliver them it is the wrong method.

Three jobs

A framework for system response design has three jobs. I will give each one plainly, with what I know about it and what I do not.

Find the points before building. On the screen side this is the walk: every place, every event, a row for each. On the conversational side it is the list of reasons: every kind of thing that can happen in an exchange that the person needs to be told about. The first list is finite and I have made one. The second I have drafted — fifteen kinds so far — and I have not yet run it against a real system, which means I do not yet know whether fifteen is the number, or whether the kinds hold up when the system starts doing them. The next step in this work is exactly that: take a real product that has both sides, and go through it with the notebook, and see what the conversational side actually produces. I have one to hand — the thinking tool I have been building — and the inventory is the next piece.

Set the rules. A row per point — trigger, condition, carrier, place or reason, strength, depth, the words, the test — and, separately, the rules for when rows meet: which yields, which waits, which stays silent. The second set is the one nobody writes, and it is the one that decides the payment moment, so a framework that gives you only the rows has given you the phrasebook again. What the meeting rules look like when written down properly — as precedence, as a small table, as something else — is a form I have not settled. Figure 2 in Part 2 is one attempt: the three lanes, on one clock.

Keep them true over a long development. This is the job the 2013 register was actually built for, and it is the one I would put first if I had to choose. A rulebook written once and then left is a document; a rulebook with a test attached to every row is a check, and it stays true because the tests fail when someone breaks it. Thirty-two messages written once and referenced everywhere meant that when a message changed, it changed everywhere at once, and when a screen wanted to say something new, the question "is there already a row for this?" had to be asked. That is what keeps the layer coherent across three years and ten developers. It is also the one part of this that a conversational system makes genuinely harder, because a test for "the system said so when it dropped something" is not the same kind of test as "the banner appeared" — and I do not yet know what it is.

What is tested, and what is not

I said in the Loop piece that a concept that comes through research unchanged is one that was never really tested. I have not yet run this one. So here is the ledger as it stands, so that you know what you are holding.

Run for real. The screen-side method: the walk, the register, the message library, the test per row. One enterprise application, 2013, shipped complete, kept coherent through the years that followed. That is one product, not a study, and I would not claim more than that. It shows the method is finite and can be done; it does not by itself show it generalises.

Found three times. The first rule — show what changed, never what is working. Motivation research, interface practice, and alarm engineering each arrived at it separately. I am confident of the convergence, and the individual sources are in the list at the end — the meta-analysis, the form study, the control-room standard and the refinery report.

Hypothesis. Everything on the conversational side. The fifteen kinds. The claim that one rulebook can hold across the seam. The idea that you specify by reason where you cannot specify by place. These are the concept as I hold it, and they are stated as such. The inventory over a real system is what turns them into something else, one way or the other.

Not yet looked. Whether anyone has written the system-side rulebook for a product that has both a screen side and a conversational side, with the meeting rules across the seam. I have not found it, and I have not searched hard yet. Silence in the literature is not evidence that it is not there; it is a task on my list.

The tool that had it

I have given two reasons the layer passes every review: a prototype shows places and cannot show time, and a written specification lists the events and hides the collision. There is a third, and it is the plainest of the three. There was never a tool for it.

Almost never. Around 2015 I built prototypes in Axure, and Axure had something no tool I have used since has kept. On any interactive component — a dropdown, a button, a field — you could set conditions: if this is selected, show that form; if this state holds, disable that control. The prototype ran on those conditions. And then you could generate a specification from the prototype, and the report wrote out, component by component, what happened when: the events and the rules behind them, more or less the rows of the rulebook, produced from the thing you had built rather than written beside it.[8]

That was the picture, or the first draft of it. Nobody carried it forward. Figma, XD, UXPin — the tools that came after are better at almost everything and have nothing like it: you can put a function on a button, but there are no rules connected to it, and no report that writes them out. I think I know why. The feature was expensive to use. Writing the conditions by hand, for every component, was a great deal of work, and most of the people who might have done it were the business analysts who were already writing some of those rules into the requirements document — the part that a document, as I have said, cannot make you see. High complexity, high cost, one tool, and so the layer fell back to whoever had the ticket.

What is now possible

The cost that killed that feature has just gone away.

What Axure asked a person to do by hand — find every point, write the condition, write what happens — is exactly the kind of work an AI agent, given a skill for it, does well and does in the background. Walk the product, screen side by place and conversational side by reason. Detect the points. Write a row for each: trigger, condition, carrier, strength, depth, the words, the test. Write the rules for when rows meet. Attach the tests and run them, so that the rulebook stays true through the long development instead of decaying into a document. None of that needs to live inside the prototype any more, or inside anyone's afternoon. It can be a check that runs beside the build, the way the register of 2013 was a check, but without the sixty-one hours it took to make it.

I want to be careful here, because "an agent could do it" is the cheapest sentence in software this year. So, plainly: I have not built it. What I have is the screen-side list, which is finite and has been run once for real; the conversational list of reasons, fifteen so far, which has not been run at all; and a thinking tool of my own with both sides in it, which is where the first run will happen. That is the next piece. Building the skill that detects and writes the rows is the work; the inventory over a real product is what tells me whether the fifteen are the fifteen.

One thing follows for anyone building a conversational product now, and I will state it as a requirement rather than a thought: the list of reasons is the first job of that agent, not an afterthought. The conversational side has no rail, so the points have to be found by kind, and the kinds have to exist before the build. And a rulebook can only say "banner" if there is a banner — so the carriers have to exist before the first row is written too. Which brings me to the thing that has been happening in plain sight while I wrote this.

The standard forming under our noses

The deterministic world had one carrier per level. A toast for the small thing, a banner for the bigger one, an inline line for the field, a box for the thing that must stop you. Each level had its own component, and the rulebook's job was to pick the right one.

The conversational tools have collapsed that whole set into two. Look at any of the leading ones this year — Claude, ChatGPT, Gemini, the coding tools — and you find the same pair. Inside the stream, an expandable block: collapsed by default, a line that says what is happening or what happened, opened only when you want the depth — which files it read, which steps it took, why it changed its mind. Beside the stream, a panel: the plan, the steps, the progress, the outcome, standing still while the conversation scrolls. Two carriers, carrying everything the toast, banner, line and box used to carry between them, and the depth that none of them could. Nobody designed this standard. Each tool watched the others, took what worked, made its own version, and within about a year they had converged.[9] It is still moving. But it is recognisably one thing now, and any product with a conversational side will be measured against it.

What the two carriers do not settle is the harder question, and it is the one this discipline exists for. A deterministic system tracked one process. You saved a file; the system told you about the file. A conversational tool tracks several at once, and they run on different clocks: the task you just asked for, the plan it sits inside, the longer arc underneath — in a thinking tool, the path you have taken between kinds of thinking, the thing you predicted and have not yet checked, how the work is going over weeks and not minutes. All of those are true at the same moment, and all of them could be shown. That is the Christmas tree again, one level up: not which lamp, but which process earns a lamp, at what strength, in the block or in the panel, and which stays dark until it changes. Deciding that — before the build, per product, by what the product is for — is the first job of system response design on the conversational side. The carriers are converging. What they carry is still every product's own decision, and most products have not made it.

I have one such product to hand, and the panel in it already holds more than the task. What it should hold, how loudly, and whether the dialogue itself is even the right surface for a long piece of thinking — or whether a map of the work, with the threads and their connections visible, replaces the scroll — is the next piece, and it needs a proper look at how the leading tools actually do it before I say more than this.

Where this leaves you

If you take five things from this piece, take these.

Every product has two halves, and only one was ever designed. The other — what the system says back, when, where, how loud — was assembled by whoever held the code.

That half has a first rule, found three times over: show what changed, never what is working. A signal is worth what the silence around it is worth.

Design systems hold the carriers and never the rules. The rulebook is a separate thing, it is small, and one response at a time you can get away without it. Three parties on one moment, you cannot.

The layer lives in time — in the three minutes, in what is said when the answer never comes — and neither a prototype nor a written specification can display time. That is why it passes every review.

And a second kind of system has arrived with no rail to walk, so the points are found by reason, not place; the real product has both sides; and the screens now come before the rules. That is why the bar went from one to ten this year, and why the discipline needs a name.

The name is system response design. The tool that once held part of it was dropped because writing the rules by hand cost too much; that cost is gone. And a standard for the carriers is forming in front of us — the block in the stream, the panel beside it — while what they carry is still every product's own undecided question.

The next piece takes that question on: how the leading tools actually answer today, what they show and what they keep dark, which processes a thinking tool has to track beyond the task, and whether the dialogue is even the right surface for long work. The inventory — an agent with a skill for it, run over one real product with both sides — runs alongside, and feeds it.

The open question

I will end where I am honestly stuck, because it has moved.

A year ago the question was whether this layer could be written down at all for a system with no rail. I now think it can — by reason, not by place — and that an agent can do most of the writing. So the question is no longer whether the rulebook can exist. It is what you put in front of a review once it does. A rulebook is a document, and I have already said what a document cannot do: make you see three things landing on one moment. A test suite is a set of checks, not a picture. The panel that shows agents fanning out is a live view of one product running, not a surface for the product before it runs. Axure's generated report was closer than anything since, and it was still a list.

And yet the picture is half there. The panel beside the stream — the plan, the steps, the progress — is, at runtime, exactly the surface I said nobody had: several processes, on one screen, at their own strengths, with the depth one click away. It shows the moment while the product runs. What it does not do is exist before the product runs. Somewhere between a screen, which shows a place, and a document, which lists events, there ought to be a way of showing a *moment* before the build — the payment through, the address failed, the session gone, and the rule that decides which is said first — so that a reviewer's eye does not slide over it, so that the product owner with the finished-looking screens can see what is missing, so that the layer gets caught in the one review where catching it is cheap. Whether the panel that is now standard at runtime can be turned round and used as that design surface is the question the next piece has to answer.

When I told the payment scene to a colleague this week, he finished it for me — the waiting, the empty basket, the trip to the inbox — before I got to the end. Everyone has the memory. Nobody has the picture. The agent can write the rulebook. Finding the picture is still ours.

Sources & further reading

The inherited loop — this essay is part three of five.

The full journey:

• https://www.stimulus.se/2026/09/29/the-inherited-loop-1-we-named-it-chat-and-built-it-to-fit-the-name/ (part one)

• https://www.stimulus.se/2026/09/29/the-inherited-loop-2-the-borrowed-drive-and-a-tool-built-for-leaving/ (part two)

• https://www.stimulus.se/2026/09/29/the-inherited-loop-3-the-half-nobody-designed/ (part three)

• https://www.stimulus.se/2026/09/29/the-inherited-loop-4-where-the-two-halves-meet/ (part four)

• https://www.stimulus.se/2026/09/29/the-inherited-loop-5-who-is-steering/ (part five)

Sources

1. Thaler, R. H. & Sunstein, C. R. (2008). Nudge: Improving decisions about health, wealth, and happiness. Yale University Press. Fogg, B. J., Fogg Behavior Model — "Behavior happens when Motivation, Ability, and a Prompt come together at the same time." behaviormodel.org
2. Deci, E. L., Koestner, R. & Ryan, R. M. (1999). A meta-analytic review of experiments examining the effects of extrinsic rewards on intrinsic motivation. Psychological Bulletin 125(6), 627–668 — engagement-, completion- and performance-contingent rewards "significantly undermined free-choice intrinsic motivation". Murayama, K. et al. (2010). Neural basis of the undermining effect of monetary reward on intrinsic motivation. PNAS 107(49), 20911–20916 — reward "undermines intrinsic motivation, as assessed by the number of voluntary engagements in the task."
3. Wroblewski, L. (2009). Inline validation in web forms. A List Apart, 1 Sep 2009 (research with Etre) — "validating inputs prematurely can be harmful"; a participant: "I found it quite annoying how red crosses came up when you hadn't finished typing"; the after-the-field variant "completed the form seven to ten seconds faster". alistapart.com/article/inline-validation-in-web-forms
4. Health and Safety Executive, Better alarm handling, Chemicals Information Sheet 6 (EEMUA 191 summarised) — "the long-term average alarm rate during normal operation should be no more than one every ten minutes"; "In the last 11 minutes before the explosion the two operators had to recognise, acknowledge and act on 275 alarms." HSE (1997), The explosion and fires at the Texaco Refinery, Milford Haven, 24 July 1994. Cvach, M. (2012). Monitor alarm fatigue: an integrative review. Biomedical Instrumentation & Technology 46(4), 268–277 — "the number one medical device technology hazard in 2012".
5. Google, Material Design 3, Snackbar — guidelines ("Snackbars show short updates about app processes at the bottom of the screen"), m3.material.io/components/snackbar/guidelines; Atlassian Design System, Banner — usage ("Use banners sparingly at the top of the screen to display critical messaging"), atlassian.design/components/banner/usage.
6. Tidwell, J., Brewer, C. & Valencia, A. (2020). Designing Interfaces: Patterns for effective interaction design, 3rd ed. O'Reilly. ui-patterns.com — "recurring solutions that solve common design problems".
7. Anthropic, Claude Code documentation, Create custom subagents — "Each subagent runs in its own context window", progress shown in the task list; code.claude.com/docs/en/sub-agents. OpenAI, Subagents — "spawning specialized agents in parallel and then collecting their results in one response … Subagent activity appears in the ChatGPT desktop app, Codex CLI, and the IDE extension."
8. Axure RP documentation, Conditional logic — "Conditional logic is a system of rules you can use to specify when an interaction you've built should occur"; The Word specification — "an automatically generated Microsoft Word document that serves as the functional specification component", with "a text summary of the widget's interactions". archive.axure.com/axure-rp/reference/conditional-logic · …/word-specification (RP 7–8, 2014–2016).
9. OpenAI, Introducing canvas, 3 Oct 2024 ("opens in a separate window"); Anthropic, Introducing Claude 3.5 Sonnet, 21 Jun 2024 (Artifacts "in a dedicated window alongside their conversation"); OpenAI, Introducing OpenAI o1-preview, 12 Sep 2024 (the collapsible thinking summary); Anthropic, Claude 3.7 Sonnet and Claude Code, 24 Feb 2025 ("step-by-step thinking that is made visible to the user").

THE INHERITED LOOP SERIES · PART FOUR OF FIVE

Open ChatGPT, Claude or Gemini, ask for something that takes a while, and watch the screen instead of the answer. Three places light up — a thin line where the answer will come, a panel filling beside the conversation, a row of small controls under the box you type in — and none of them existed three years ago. Every AI tool built around a conversation has landed on the same three in the same two years, by copying. What none of them has settled is the part that decides whether the tool is calm or exhausting to live in: which of the seven things it has in motion is allowed to interrupt you, where, and how loud. This post works that out — and takes apart the loudest thing on the screen, the message that halts everything until you click Allow.

Open ChatGPT, Claude or Gemini and ask it something that takes a while. Then, for once, watch the screen instead of the answer.

A thin grey line appears where the answer will come: Thinking… — and when it is done, Thought for 14 seconds. Click it and it unfolds into a list of what the tool did while you waited. In some tools a panel opens on the right and fills on its own — a document taking shape, a table, a file being written — while the conversation on the left carries on. And under the box you type in, a row of small controls: which model answers, how hard it should think, whether it may search the web, whether it should plan first or just do it.

Three places on one screen where the tool talks back to you. None of them existed three years ago. If you have lived in these tools through 2025 and 2026 you watched them arrive, one by one, in every tool at nearly the same time. And you have felt the other side of it. The screen that lights up like a Christmas tree — a spinner at the top, a badge on the sidebar, a progress bar under the answer, a small message sliding in at the corner and fading before you have read it — all at once, and you do not know which one to look at. The answer that ran for three minutes behind a line that said Working… and nothing else, so you sat and stared at it. The counter that told you how much you had left to spend, until one day it was gone, and you did not miss it. And the worst of them, if you use a tool that can touch your own files: ⟨the confirm message, sitting in the conversation: Allow this command? Allow once · Allow for this session · Always allow — and nothing moves until you answer.⟩ You click Always. Two minutes later it asks again. You get up for a coffee; when you come back the tool has been sitting for five minutes on that message, waiting for you, and nothing has happened. You are not using the tool. You are guarding it.

This post is about those three places, what belongs in each, and what does not — and about the confirm message, which is what happens when nobody has decided.

It is for anyone who builds software with an AI inside it — designers, developers, product owners — and for anyone who spends the working day in these tools and wants to know why they feel the way they do. What you get: by the end you will be able to look at ⟨any AI tool built around a conversation⟩, the one you build or the one you use, and say which of its indicators earns its place, which is noise, and why every tool is landing on the same three places. What is at stake: that layout is settling now. Within a year or two it will be as fixed as the menu bar and the scrollbar became, and whoever builds a tool then either follows it or fights it. But the layout is only the easy half. The part that is not settled — which of several things running at once is allowed to interrupt you, in which place, and how loudly — is the part that decides whether a tool is calm to live in or exhausting. That is the part this post works out.

You do not need the two posts before this one, though they are here if you want them. Posts 1 and 2 followed the loop between a person and a tool — ask, wait, read, ask again — and showed that we inherited that loop from the old, deterministic tools without ever redesigning it. Post 3 turned to the tool's half of the loop and gave it a name: system response is everything the tool does to reach you that is not the answer itself, and system response design is the discipline of deciding when it speaks, where on the screen, and how loud. That is the whole vocabulary you need. Every other term is explained here the first time it appears.

Here is where it gets hard.

In the tools we grew up with, one thing happened at a time, and it had one place to show itself. You pressed Save, a bar filled, it was done. The place for that bar was decided once, in the 1990s, and never moved. Now the tool is doing several things at once, on different clocks. It is answering you. It is planning, sometimes several steps ahead. It is running work in the background that may finish in a minute or an hour. It is spending your money as it goes. It is asking, or not asking, permission before it touches something of yours. It is deciding, or letting you decide, which of several models answers. And under all of that runs the longer arc of the thing you are actually building together, across days. Seven things in motion, three places on the screen, and no rule anyone has written down for which of the seven gets a light, in which place, at what strength. Every tool answers it by feel, and you can see the answers differ from one tool to the next, screen by screen.

This post gives that rule. It starts from the three places, because they are what you can see, and works down to the reason they look the way they do — which turns out to be a change in what a conversation with a tool is for. The dialogue used to be where the work happened. In these tools it is becoming the record of the work, and the work happens beside it. Hold that thought; it is what the three places are the visible sign of, and it is where the post ends up.

FIGURE 1 — one annotated screen: the line in the conversation (collapsed: a duration; expanded: every step) · the panel beside it (plan, steps, output, sources) · the row under the input box (model · effort · memory · sources · plan-or-do · ask-or-act). Caption: The three places a tool built around a conversation speaks in. The line and the panel are where it speaks to you; the row is where you tell it how to speak.

Part 1 — Three places, seven things in motion

The picture says what the places are. What it cannot say is why there are three, and what the three do not settle.

The old software had four places for a response, one per level of seriousness: the corner message that fades on its own, the strip across the top, the line under a field, the box in the middle that stops everything. The conversational tools folded those four into two. The line in the conversation is the corner message and the box in one component with a hinge: collapsed, one quiet line; expanded, the whole account — without stopping anything, because the account is offered rather than imposed. That is the design gain of the fold, and it is real: the old software had to choose between telling you little and stopping you to tell you everything. The panel is the strip and the status bar grown up — the place for what stays true while the conversation moves, put where it can be consulted instead of demanding attention. Post 3 called every visible thing a response lands on a carrier; here I will say place, because there are three and each is a place on the screen.

I watched the fold happen, and the pace of it is the proof that nobody designed it: under a year from the first appearance of each place to its presence in every leading tool, and about sixteen months from the first of them to the last.[1] Each maker watched the others and took what worked. The result is one layout, and any product with a conversation in it will now be measured against it.

What the layout leaves open is the part that matters. The old software reported one thing at a time, and post 3's rules — which place, what volume, for what reason — assume that. A tool built around a conversation has seven things in motion at once, on seven clocks:

• • Task — what was just asked for; seconds to minutes.
    
  • Plan — what the task sits inside; the turn or the session.
    
  • Background work — agents and searches running while you type; minutes to hours.
    
  • Money — what it is spending as it goes.
    
  • Permission — what it may touch of yours without asking.
    
  • Model — which of several is answering, and who chose it.
    
  • Longer arc — the thing being built across days, which no single turn shows.

In my own thinking tool there are more — how the learning is going, measured in weeks; the path taken between kinds of thinking, which is the shape of a session — but seven states the problem. All seven are true at once and all seven could be shown. Which of them earns a light, at what strength, in the line or in the panel, and which stays dark until it changes, is a decision each product must make for what it is for. Most have not made it; they took the layout and left what the places carry to whoever held the ticket that afternoon, which is exactly how the old response was assembled. One of the seven — permission — has already been answered wrongly in almost every tool, and Part 3 takes it apart. For now it stands as proof that the question is real.

FIGURE 2 — Many things, three places. The screen of a conversation tool with its three places named (the line, the panel, the row); around it, cards for what is true right now, each with how often it changes; at a turn, Task flies into the line as a message, Plan and Permission settle in the panel, the rest wait outside "until it changes"; a second turn chooses differently. Built in Claude Design 2026-09-25: figures/POST-4_fig2-many-things-three-places_claude-design_2026-09-25.html. Caption: While the tool answers you, many things are changing at once — the task, the plan, the money, what it may touch, which model is answering, the work running in the background — and it cannot report them all. For each one, someone has to decide: say it in the conversation, show it in the side panel, or stay quiet until it changes.

Where we are. Three places: the line, a folded record; the panel, an overview that stays true; the row, where you steer. The first two replaced the old four and spread everywhere in under a year each, by copying. What the layout does not settle: seven things are in motion, and which earns a light is each product's own decision — mostly unmade, and in one case made wrong. Next: why a tool whose output is the conversation is a different kind of tool.

Part 2 — The dialogue is the output

Three kinds of tool, two compared

I have sorted tools by what sits in the middle of the screen for a long time — since around 2010, when I was separating applications built around a process from applications built around a document. With the AI tools a third kind has become common, and the sorting matters more than it did, because the response has to be designed differently for each.

A process-central tool moves a case through stages: a request is raised, filled in, sent for approval, returned, continued in a new state. Each screen is one station on the way, and the response reports on the station. That kind is old and well understood, and it is not the subject here.

A document-central tool has a document in the middle: the app being built in Replit or Bolt, the code in Cursor, the design in Claude Design, and before them the spreadsheet, the text and the photo. The conversation sits beside the document as a helper; every response runs in a straight line toward the document, and the chat could be closed without the document losing its point. Everyone recognises this kind; it is Excel and Photoshop with a chat attached.

A conversation-central tool has the dialogue in the middle: ChatGPT, Claude or Gemini as first met; Perplexity; a thinking tool. There is no document the conversation serves. The conversation is the output — the road from question to answer, the reframings, the sources found, the places where someone changed their mind. Several of the seven things are in motion inside it at once, and nothing beside it could replace it. The immediate consequence: in this kind the panel is not a helper. It is the only overview there is.

FIGURE 3 — three screens side by side, each with the same three parts drawn in different sizes: process-central (a chain of stations across the middle; the conversation a small helper; the response reports on the station) · document-central (the document large in the middle; the conversation a side pane; every response points at the document) · conversation-central (the conversation large in the middle; the panel beside it as the only overview; several of the seven things in motion inside the conversation). Caption: What sits in the middle of the screen decides what the response is for. The AI tools are made of the last two.

The last two are the ones the AI tools are made of, and they are the two I compare. My field has an opinion about them, and it is one-sided: chat is what shipped, not what works; put the model inside the document, remove the sidebar. For a document-central tool that is right. For a conversation-central tool the question has not been asked. Nobody has said that a dialogue, as an output, needs its own rules for what is shown and where. This post says it.

One property of the conversation-central tool matters at the end. When the channel is speech — you talk, it answers in speech — the visual half disappears: no row, no panel, no record unless you stop and open a screen. At its purest this kind of tool has no picture. Part 4 says why that is a freedom.

Coworker, assistant, director

A document has no role. A dialogue partner has one, and the right response differs by role. Posts 1 and 2 left the tool with one stance: a mirror, which reflects and does not affirm. That was the person's half. The tool's half needs three. A coworker reports what it is doing and what it dropped, because you will build on it. An assistant reports at the end and is otherwise quiet, because you asked for the thing, not the account of the thing. A director shows the plan and asks before acting, because the consequences are yours. The same tool takes all three in an afternoon, and the response that is right for one is wrong for the others: the narrating assistant is exhausting, the silent coworker is frightening, the director who never shows the plan is a liability.

People who work together solved this long ago by signalling instead of narrating: a plan said once, a change reported when it happens, a handover at the end, silence between. The tools that feel like coworkers have that rhythm. The confirm message, in these terms, is a director's move made by a tool that has not been told it is a director.

Four rules for what the places carry

The places are settled; what they carry is not. Four rules decide it. The first is from post 3; the other three are what these tools taught me.

Rule 1 — show what changed, never what is working. A light earns its place by marking a change and loses it the moment it is always on. When I went looking for whether anyone had written that down before me, I found it in the standards for alarm systems in industrial plants, with numbers: no alarm without a defined operator response; fewer than one alarm in ten minutes in steady operation.[2] It transfers to a conversation unchanged.

Rule 2 — the panel is a fuel gauge. A place that is always there is not there to be watched; it is there to be trusted. Nobody looks at the fuel gauge, everyone relies on it, and it has one lamp, which comes on at reserve. The research finding that people rarely read what sits beside the answer is true and beside the point[3] — presence is the value, attention is not the measure. So: the panel holds the reading, and when the reading crosses a line it sends one message into the conversation — background work finished, plan changed, memory gone stale. Places in the panel, messages in the line. The panel is never silenced; the line usually is.

Rule 3 — depth serves control and trust; in a thinking tool it is the work. The folded line lets you find out what the tool did and see that it did what it said. In my thinking tool it does one thing more: it shows where your own reasoning held and where it broke. That is not depth for control. It is the output.

Rule 4 — test every light by what the person does differently. If this fires, what do you do? If the answer is nothing, it does not fire. Twenty years in an engineering culture that wanted every reading on the screen taught me that nine in ten could go and the work would still get done; the readings were true, and nobody acted on them.

One picture beside the rules. The visible thinking — the reasoning shown before the answer — is the light Rule 1 would kill and the one people say they want most. It is a step counter: read while you are learning how the tool reasons, put down when that is habit. Scaffolding, not furniture.

Run the confirm message through the four rules: it marks no change; it is a message at the volume of a wall; nobody does anything differently when it fires; it was never tested because it was never designed. It fails all four, and it is the loudest thing on the screen.

Where we are. Three kinds of tool; the two the AI tools are made of are document-central and conversation-central, and only the second has never been given its own rules. The tool takes a role — coworker, assistant, director — and the response follows the role: plan once, change when it happens, handover at the end, silence between. Four rules decide what the places carry: change not working; the panel as fuel gauge; depth as control, trust and — in a thinking tool — the work; every light tested by what the person does. The confirm message fails all four. Next: the row, and the confirm message put where it belongs.

Part 3 — The row under the input box

The steering wheel of the response

The row is the third place and different in kind: the line and the panel are where the tool speaks to you; the row is where you tell it how to speak. Its controls came out of the settings menus between 2024 and 2026 for one reason — a setting is decided once, these are decided per task — and they came out in the same order in every tool. Laid against the seven things in motion, the row's controls are the same list from your side: model, effort, memory, sources, plan or do, ask or act. Each thing the tool has in motion is a thing you can steer, and the row is where. It will keep growing until all seven are on it.

Three of its controls show which way it is going. The money counter is leaving: one coding tool removed it from its graphical app in May 2026, and it survives at the command line for people who meter by the hour[4] — Rule 2 arriving on its own, the reading moved to where it can be checked. The model choice is changing shape: today a list of brands nobody outside the trade can choose between; several tools now route the question themselves;[15] the control will say what kind of thinking the task needs, not whose product supplies it. And asking-before-acting is arriving — the control most often missing from the row, which is why it turns up instead as a message in the conversation that halts the work.

The confirm message, taken apart

It exists for a real reason, and I will state it once because it is not the lawyers: the tool cannot tell your instruction from an instruction hidden in a file or page it has just read, so any action that changes something of yours is put behind a human click.[5] That is an honest first answer to a real problem.

The message itself was inherited, not designed — it is the operating system's privacy box, the one that asks whether an app may read your files, carried over unchanged. Its record came with it. Microsoft measured that box in 2008: nine in ten prompts waved through, and one person in eight could say why they had seen one.[6] The maker of one of the most-used coding tools measured its own in 2026: 93 percent approved in March, 97 by August.[7] Same box, same number. A gate that nineteen in twenty pass without reading is not a gate, and the twentieth is the security hole. And one more figure from the same maker, which I think says more about the design than any argument I can make:

62 percent of users have switched the asking off — found the setting, or the flag, that turns the confirm message off altogether, and taken the risk it was there to prevent, rather than live with it.[8]

When most of the people a safety feature is built for go looking for the way to disable it, the feature is not protecting them. It is in their way.

Always makes it worse, twice. Every tool I examined has open reports of Always not being saved. And by design Always means less than the word means anywhere else: in one tool it lasts until the session ends; for a command it covers that command in that project and no other.[9] The message does not say so. You learn what the word means by being interrupted, and you stop trusting the row.

Where it belongs is on the row, in two layers. Yours, set in advance: for this kind of task — reading, drafting, refactoring, deploying — this is what the tool may do unasked; a control like the model or the effort, chosen when the task begins. And the tool's: for what you did not pre-decide, it judges — the makers are already building the judge, and the retreat from the message is under way: machine judgment by default since August 2026 in one tool, Ask every time retired in another.[10] When it must still ask, two rules no tool follows in full: say in one sentence what Always will cover — Apple has required a "why" sentence on every permission box for a decade,[11] and privacy law made the principle general; the AI tools ask for more and explain nothing — and ask where you are, on the phone, not on a screen you have left. One tool does the second half today.[16]

FIGURE 4 — The same permission, moved. One screen: a deploy request; the "Allow this command?" box halts the conversation, the clock counts 1, 3, 5 minutes with nobody there; the box lifts out and settles into the row as "ask or act ▾" (read acts · draft acts · refactor acts · deploy asks); the one remaining question arrives on the phone with its scope in one line. Built in Claude Design 2026-09-25: figures/POST-4_fig4-the-same-permission-moved_claude-design_2026-09-25.html.

Caption: The same permission, moved. Instead of a question that stops the conversation until you come back, a standing choice on the row — and the one question that still needs you, sent to where you are.

Some people trust a tool because it asks. They are right to. The argument is not against asking; it is against the same question a hundred times, in a message nobody reads, with a word that does not mean what it says.

Which rules are ruling

Under the row runs something it does not show. Every control you set is a rule; but the maker's rules run beneath yours, unseen, with the company's, the project folder's, the tool's memory of you, and whatever a page just read slipped in — five or six sources, and the screen shows one layer. Tests of how well these tools keep a standing instruction put it near one in three by the end of a session, and when rules conflict the tool picks right less than half the time.[12] In my own year with one of these tools, a third of what I said to it was about how it should respond rather than about the work — the job the row should do, done by hand. One tool now shows, under each reply, which of your instruction files it used;[13] the beginning of the right thing. The row needs a place for the whole stack — which rules are in force, from where, which have gone stale — with one lamp when a rule of yours is dropped. Until then every session runs on terms you cannot see.

Where we are. The row is where you steer the response, and its controls are the seven things from your side. Counters are leaving for the command line; model choice will be by task, not brand; asking is arriving. The confirm message is the operating system's privacy box with its record intact — nine in ten waved through then, 93 to 97 percent now — and it fails all four rules; Always means less than it says. It belongs on the row: your standing choice per kind of task, the tool's judgment for the rest, and when it must ask, one honest sentence, where you are. Beneath the row is a stack of rules kept a third of the time, which the row needs a place for. The layout took two years to settle; the rules have not begun to. Next: why it is worth getting right.

Part 4 — What lies behind the gain

A tool you can leave

The reason to get the response right is not a tidier screen. It is that a tool which speaks only when something changes, and speaks to where you are, is a tool you can leave — and that changes how the tool is used more than any feature does.

Streaming is the precedent I keep coming back to. When music began to stream the songs did not change; what changed was that the music no longer had to be where you were sitting. Listening moved — into the walk, the kitchen, the gaps — and nobody designed the new listening. It followed from where the music could be.

A conversation-central tool is at the same edge. If the dialogue is the record and the work happens beside it — the thought I asked you to hold at the start — then you do not have to be at the screen for the work to go on. The panel keeps the overview, the line keeps the account, one message comes when something changes. That is the shape of a coworker, and the three places make it possible. My own use went that way over two years without a plan: typing, then dictating, then talking — and talking is different, because it can be done walking, and the answer comes back as speech, so there is nothing to look at. The load is not lower. It is spread, between eyes and ears, between the desk and the walk, the way a conversation with a person is.

The confirm message is the one thing on the screen built on the opposite assumption — that you are in the chair, looking. Everything else in the standard is drifting toward a tool you can leave; this one holds you at the desk. That is why it is the loudest thing in the opening and the first of the seven to be taken apart, and it is why it is not the point. It is the last piece of the old furniture in a room that has otherwise been rebuilt, and it is already being carried out. Posts 1 and 2 ended by asking for a loop built for leaving. This is what that loop looks like from the tool's side.

A young tool's illnesses

None of this is carelessness. Two years is not long; the layout settled faster than any I have watched in thirty years of this trade, by imitation, because there was no time to settle it any other way; and the confirm message was the fastest honest answer to a real danger. Nobody designed the response of a tool with seven things in motion because nobody had built one before; the people behind the best-known guidelines for human–AI interaction published, in late 2024, a list of twelve still-open questions about what an agent should tell the person — what it is about to do, what it is doing now, what it changed.[14] These are a young tool's illnesses. But imitation copies the layout, not the reasoning: the three places spread everywhere, and the question of what belongs in them did not spread with them, because it was never written down. The four rules are my attempt to write it down — a first word, offered to be argued with.

Where this leaves you

The post in one paragraph. A tool built around a conversation speaks in three places: a line that folds open into the record, a panel that holds what stays true, and a row where you steer how it speaks. The layout converged in two years by copying; what it leaves open is the design. Seven things are in motion — task, plan, background work, money, permission, model, the longer arc — and which earns a light, where, and how loud, is decided by four rules: show change, never working; the panel is a fuel gauge with one lamp; depth serves control and trust and, in a thinking tool, the thinking itself; test every light by what the person does. The confirm message fails all four and belongs on the row — your standing choice per kind of task, the tool's judgment for the rest, and when it must ask, one honest sentence, where you are. Beneath the row runs a stack of rules you cannot see and the tool half keeps; the row needs a place for it. And the reason to get this right is that a tool which speaks only when something changes, to where you are, is a tool you can leave.

Post 3 ended stuck on a picture: a way to show, before a product is built, several things landing on one moment at their own strengths, so that a reviewer's eye does not slide over it. Here is the answer as far as I have it. The picture is Figure 2: the screen with its three places, everything that is true at that moment around it, and for each thing the decision — said in the line, shown in the panel, or quiet until it changes. It is not a screen and not a document; it is a moment, and it can be drawn before a line of code exists. The list beside it is the rulebook.

The next step takes an hour with the tool you use or build, and it produces that list. Find the three places. Take the seven things and write three words for each: which place, how loud, what you do differently when it speaks. Most of the third column will say nothing. Those are the lights to turn off. What remains is the response — designed, for once, rather than inherited.

The open question is the one on my desk. This post treats the tool as one kind at a time. No real tool is. A conversation-central tool becomes document-central the moment you open the design or the draft beside it, and becomes process-central the moment a step needs an approval; then it comes back. The switch is decided by context, several times an hour, and everything in this post — the places, the seven things, the four rules — was worked out for one kind standing still. What happens to the response at the switch? Which of the seven keeps its light, which place carries over, and does the person even notice that the tool has changed under them? Get the response right for the conversation-central tool and the switch is designable. Get it wrong and the switch is where the tool falls apart. When a tool changes kind under you, and speaks only when something changes, and keeps rules you cannot see — who is steering?

That is the next post.

Sources & further reading

The inherited loop — this essay is part four of five.

The full journey:

• https://www.stimulus.se/2026/09/29/the-inherited-loop-1-we-named-it-chat-and-built-it-to-fit-the-name/ (part one)

• https://www.stimulus.se/2026/09/29/the-inherited-loop-2-the-borrowed-drive-and-a-tool-built-for-leaving/ (part two)

• https://www.stimulus.se/2026/09/29/the-inherited-loop-3-the-half-nobody-designed/ (part three)

• https://www.stimulus.se/2026/09/29/the-inherited-loop-4-where-the-two-halves-meet/ (part four)

• https://www.stimulus.se/2026/09/29/the-inherited-loop-5-who-is-steering/ (part five)

Sources

1. Convergence dates: the collapsible thinking line — OpenAI o1 (Sep 2024), Gemini "Thoughts" and Claude extended thinking (by Feb 2025); the panel beside the conversation — Claude Artifacts (Jun 2024), ChatGPT Canvas (Oct 2024); plan-before-work — Gemini Deep Research (Dec 2024), Claude Code plan mode (Jun 2025), Cursor plan mode (Oct 2025). Vendor announcements: openai.com/index/introducing-canvas · anthropic.com/news/claude-3-5-sonnet · cursor.com/blog/plan-mode.
2. EEMUA 191 (with ISA-18.2, which adopts the same rate), as summarised in ABB, Alarm Management for SCADA control rooms (white paper, library.e.abb.com): "There should be no alarm without a predefined operator response"; "Long term average alarm rate in steady operation: less than 1 alarm in 10 minutes."
3. Nielsen Norman Group, Explainable AI in Chat Interfaces: "people rarely click citation links"; "people often just skim the text … and skip over fine print entirely." nngroup.com/articles/explainable-ai
4. OpenAI Codex desktop app, context counter removed/hidden May 2026 — github.com/openai/codex/issues/23928 and /24028; counters remain in Codex CLI, Gemini CLI and Claude Code CLI (code.claude.com/docs/en/statusline).
5. Anthropic, Claude Code security docs, section "Protect against prompt injection" — the permission system is listed as the first safeguard: code.claude.com/docs/en/security; OpenAI, Agent approvals & security: "Prompt injection can cause the agent to fetch and follow untrusted instructions", developers.openai.com/codex/agent-approvals-security. GitHub Copilot CLI gives the plainer reason — "a shell command can do anything your user account can do" — docs.github.com, Allowing and denying tool use.
6. Ben Fathi (Microsoft), User Account Control, Engineering Windows 7 blog, 8 Oct 2008: consumer administrators approved "89% of prompts in Vista and 91% in SP1"; "only 13% of participants could provide specific details about why they were seeing a UAC dialog". learn.microsoft.com/en-us/archive/blogs/e7/user-account-control
7. Anthropic, Claude Code auto mode, engineering blog, 25 Mar 2026: "Claude Code users approve 93% of permission prompts"; Anthropic, Auto mode is now the default in Claude Code, 7 Aug 2026: "users approve 97% of permission prompts." anthropic.com/engineering/claude-code-auto-mode · claude.com/blog/auto-mode-default-in-claude-code
8. Anthropic, 7 Aug 2026 (same post as 7): "62% of users have used bypassPermissions or clicked 'don't ask again' on Bash."
9. Claude Code permissions documentation, "Yes, and don't ask again" scope table: file edits "Until session end"; Bash rules "Permanently per repository and command". code.claude.com/docs/en/permissions (re-read on the day of publication; the page changes often).
10. Anthropic, auto mode default for Pro/Max/Team from 14 Aug 2026 (source 7); Anthropic, Claude Code sandboxing, 20 Oct 2025: sandboxing "safely reduces permission prompts by 84%"; Cursor, Run modes documentation, changelog: "3.5 | May 22, 2026 | Ask Every Time was deprecated. New users cannot choose it." cursor.com/docs/agent/run-modes
11. Apple, Requesting access to protected resources: a purpose string is required for every protected resource and App Review rejects apps without one. developer.apple.com/documentation/uikit/requesting-access-to-protected-resources
12. Panavas et al., HANDBOOK.md: A Benchmark for Long-Context Agentic Instruction Following, Jul 2026 (arXiv 2607.25398): "The strongest evaluated model passes 36.2% of trials"; Zhang et al. (Johns Hopkins), Many-Tier Instruction Hierarchy in LLM Agents, Apr 2026 (arXiv 2604.09443): "even the current frontier models perform poorly (~40% accuracy) when instruction conflict scales"; Eliav, Prompt Design at Scale, Jul 2026 (arXiv 2607.19257): "Perfect-response rate collapses to zero by N=80 for every model, format, and placement."
13. GitHub Docs, Adding repository custom instructions for GitHub Copilot in your IDE: "you can verify that they are being used by Copilot by looking at the References list of a response in the Chat view."
14. Bansal et al. (Microsoft Research), Challenges in Human-Agent Communication, Dec 2024 (arXiv 2412.10380): twelve challenges, among them "What is the agent about to do?", "What is the agent currently doing?", "Were there any side effects or changes to the environment?"
15. OpenAI, Introducing GPT-5, 7 Aug 2025: "a real-time router that quickly decides which to use based on conversation type, complexity, tool needs, and your explicit intent"; GitHub, Auto model selection now routes based on your task in VS Code, 20 May 2026; Cursor, Introducing Cursor Router, 22 Jul 2026.
16. Claude Code, Remote Control documentation, "Mobile push notifications": "Push when actions required for permission prompts and questions". code.claude.com/docs/en/remote-control

THE INHERITED LOOP SERIES · PART FIVE OF FIVE

The AI tools you use every day have changed kind under you — from a helper beside the document to a worker inside it, and, within one session, from conversation to document to process without a word. This post follows that switch, shows what it removes from your working day, and asks what a tool owes you at the moment it changes.

Two years ago a narrow panel appeared on the right-hand side of PowerPoint: the AI assistant, Copilot. It had a box to type in, and above the box a short list of what it could do: summarise this deck, find the slide about the budget, tell me what this presentation says. I asked it to change a slide. It told me how I could change the slide. It could read the document. It could not touch it.

In Excel the same panel could reach a little further — but only into the cells I had first turned into a table; the rest of the sheet did not exist for it. In Figma the most useful thing the new AI assistant could do was rename my layers. In Miro, when I had a wall of notes, it could copy them and sort the copies into groups. Small jobs, always done in the panel, never in the document.

Open the same tools today. The assistant is in the document: it rewrites the text on the slide, fills the sheet, builds a working screen from a sentence in Figma Make. The panel is still there, but the work has moved out of it. Nobody announced the move, and if you have lived in these tools every day you may not have seen it, because each week looked like the week before. Put a screenshot from 2024 next to one from today and the difference is not a feature. It is where the tool lives.

The move runs the other way too, several times an hour. You are in a conversation with an AI tool — ChatGPT, Claude, Gemini, Copilot. You ask for a draft, and a window opens beside the conversation with the draft in it; you are now in a document, and the conversation has gone quiet at the edge of the screen. A step in the work needs your approval, and for a moment the whole thing is a form: fill in, confirm, continue. Then you are back in the conversation. Three kinds of tool in ten minutes, on one screen, and the tool never told you it had changed.

This post is about that switch — the slow one over two years and the fast one inside an hour — and about what the tool owes you at the moment it changes kind. Post 4 ended on a question: who is steering? This is the answer, as far as I have it.

It is for the same readers as the three posts before it: anyone who builds software with an AI inside it — designers, developers, product owners — and anyone who spends the working day in these tools and wants to know why they feel the way they do. What you get: a way to tell which kind of tool you are in at any moment; a short list of what the tool owes you when it changes kind — which lights stay on, which rules still hold, which role it is playing; and a test for whether a tool has been designed for the switch or merely survives it. What is at stake: the switch is where these tools fail today, and it is where they will fail more, because the assistant is moving deeper into the document every quarter and the conversation is not going away. Everything in the three earlier posts was worked out for one kind of tool standing still. The tools do not stand still. Whoever designs for the switch is designing the next two years; whoever designs for one kind at a time is designing the screenshot from 2024.

You do not need the three posts before this one. Posts 1 and 2 followed the loop between a person and an AI — ask, wait, read, ask again — and showed that we inherited it from the old tools without redesigning it. Post 3 named the tool's half of that loop: *system response* is everything the tool does to reach you that is not the answer, and *system response design* is deciding when it speaks, where on the screen, and how loud. Post 4 found the three places on the screen where it speaks — a line in the conversation, a panel beside it, a row under the box you type in — counted seven things a tool has in motion at once, and sorted tools into three kinds by what sits in the middle of the screen: a process moving through stages, a document, or the conversation itself. That is the whole vocabulary you need. Every other term is explained the first time it appears.

Here is the difficulty.

A tool designed as one kind carries its lights, its rules and its role as if the kind were fixed. Open the draft beside the conversation and the tool has become a document tool — but the conversation's lights are still on, the panel that a minute ago was the only overview is now a helper, and the rule you gave five minutes ago, *don't rename my files*, was given to a coworker in a conversation and is now being kept, or not, by an assistant inside a document. When the approval step arrives, the tool is a director for one screen, and it asks in the way post 4 took apart — a confirm message in the conversation, everything halted — a form built for none of the three kinds. Nothing on the screen says which kind you are in. You find out by what breaks.

This post gives the rule that is missing: what the tool owes you at the switch. It starts with the two switches, because they are what you can see; then what actually changes when a tool changes kind — the role it plays and the rules it keeps; then the response at the switch — which of the seven things keeps its light and which place carries over; and it ends where post 4 left off, with who is steering. Hold one thought on the way: the switch is not a fault. It is the tool growing up in front of you, in the middle of your work, and the response is the only way it has of telling you.

Part 1 — The two switches

A tool changes kind in two ways, and neither is announced. (This is not posts 1 and 2’s switch — the hand leaving the keys for the eye to catch up. This is a switch of the tool itself.) It changes by release, over years, as the maker moves the assistant deeper into the product. And it changes by context, inside a session, as the work moves between the conversation, a document and a step that must be approved. The first switch is why the second one is now common; the second is where the response breaks.

The slow switch — the assistant moves toward the middle of the screen

I have sorted tools since around 2010 by what sits in the middle of the screen, and the shortest way to say what has happened in the last two years is this: the assistant is moving toward the middle. Watching Copilot in PowerPoint from its first month to this one, the move has four stages, and every document tool I use has passed through the same four in the same order.

Stage 1 — it reads the document and answers in the panel. Summarise this deck; find the slide about the budget. Nothing in the document changes. The response is the answer itself, in the panel, and the panel is the whole tool.[1]

Stage 2 — it acts on a part you prepared for it. The cells you first turned into a table; the layers it renames in a click; the copies of your notes it sorts into groups on a fresh part of the board.[2] The document changes, but only where you marked, and the panel still carries the account.

Stage 3 — it makes new things inside the document, in the document's own style. The slide it adds to an old deck, in that deck's layout, type and tone, after asking one question about what the slide should cover. The work lands in the middle; the panel keeps the record of what it did and why.[3]

Stage 4 — it acts on what you point at. Select a title on the slide; a small box appears under it: What should Copilot change or add? — rewrite, condense, make professional — and the selected words appear, quoted, in the panel's input box. The two places are wired together: you point in the document, you talk in the panel, the change happens where you pointed.[3]

FIGURE 1A — a pair, or today's screen alone: 2023 the pane that could only summarise · today the slide it built inside the deck, the Reasoned in 4 steps line, the question it asked first, the Edit control under the box. Caption: Two years of one panel. The assistant has moved from beside the document into it — and post 4's three places came with it.

Two things about the stages matter for the response. First, each stage moves the response with it. At stage 1 everything the tool says is in the panel, because that is all there is; by stage 4 the change is in the document and the panel is the record — post 4's line and panel, arrived in a document tool by a different road. The layout post 4 found in the conversation tools is now the layout of PowerPoint, question-before-acting included. Second, nobody experienced the stages as stages. Each was a release note. The switch of kind — from a reading tool beside your document to a writing tool inside it — was never a headline, and so it was never designed as a switch; it accumulated.

FIGURE 1B — the swap, two frames: figures/POST-4_fig1b-swap-panes-hover_codex_2026-09-29.jpg` (hover on the divider: "Swap left and right panes") above `figures/POST-4_fig1c-work-in-the-middle_codex_2026-09-29.jpg (after the click: the work in the middle, the conversation at the side). Caption: Hold the mouse on the divider and the tool offers to swap the two panes. One click, and the work sits in the middle with the conversation at the side — the same tool, its focus moved.

Two things about the stages matter for the response. First, each stage moves the response with it. At stage 1 everything the tool says is in the panel, because that is all there is; by stage 4 the change is in the document and the panel is the record — post 4's line and panel, arrived in a document tool by a different road. The layout post 4 found in the conversation tools is now the layout of PowerPoint, question-before-acting included. Second, nobody experienced the stages as stages. Each was a release note. The switch of kind — from a reading tool beside your document to a writing tool inside it — was never a headline, and so it was never designed as a switch; it accumulated.

The fast switch — three kinds in ten minutes

The second switch is the one you feel. Inside one session the tool changes kind by context, and post 4's three kinds are the vocabulary for it: conversation-central, where the dialogue is the output; document-central, where a document sits in the middle and the conversation helps; process-central, where the work moves through stations and each screen reports on the station.

A working session in any of the leading tools now crosses all three. You are in the conversation. You ask for a draft, and the draft opens in its own window beside the conversation[4] — the tool is document-central now, whatever it was a minute ago. A step needs your approval — a file to be overwritten, a command to be run — and the tool stops and asks; for that screen it is process-central, one station, fill in and confirm. Then the answer comes back into the conversation and you are conversation-central again. In a tool that can touch your files the sequence is plan, act, ask, act, and each verb is a different kind.

There is a second way to arrange the same work, and I have both on my desk.

FIGURE 2 — two screens, one job (backlog items for a design project). Left, the GitHub Copilot app: the conversation in the middle; beside it a panel with tabs — Plan · Insights · Browser · the backlog item itself, live from the work tracker, with its state, area and sprint. Right, Visual Studio Code: the running application in the middle, the code beside it, the conversation in a panel on the right, with Agent · Local · Default permissions on its row. Caption: One job, two arrangements. Left, the conversation stays in the middle and the other kinds come to the panel as tabs the person chooses. Right, the document stays in the middle and the conversation is the helper.

The left arrangement is the one that matters for this post. There the tool does not change kind; the panel does — and it says so, in a tab the person picked. Writing a backlog item, the conversation reaches into the work tracker, writes the fields, reads them back to confirm, and the item appears in the panel as the form it is, while the dialogue stays where it was. That is the switch made by hand and labelled: not automatic, chosen, and named in one word at the top of the panel. It is half of what this post will ask for, and it is more than any conversation tool had a year ago.

The same arrangement is arriving from other trades. Recall, a tool for reading and keeping what you read, puts one strip of tabs — notebook, chat, reader, graph — above the middle and above the panel alike, so the person decides which kind sits where. Heptabase, a tool for thinking on a canvas of cards, puts the canvas in the middle and its assistant beside it.[3] Three tools from three trades, one shape: one thing in focus, and a labelled panel whose kind you pick. I have that panel sketched for my own tool, with folded rows where these have tabs; the rows stop working the moment the panel has to hold a canvas, and these three had already found that out.

Post 4's first rule was: show what changed, never what is working. A change of kind is the largest change a tool can make in front of you, and no tool marks it. The panel opens; the message halts; the answer resumes — each shown as an event of its own, and the fact that the tool has become a different kind of tool is not shown at all. You find out by what breaks.

Where we are. A tool changes kind two ways: by release, in four stages that move the assistant from beside the document into it; and by context, several times an hour, between conversation, document and process. Neither switch is marked. Next: why that matters — what the switch is removing from your day.

Part 2 — What disappears

The switch is worth designing because of what it removes: the work between the tools.

One job I do every week shows it. Until this spring, writing a backlog item went like this: dictate what I wanted to a trained assistant in a chat window; copy the result; open the work tracker; create the item; paste — as plain text, because the formatting arrived broken; reformat by hand. Five tools, four hand-offs, most of an hour, and the assistant had done only the first step. Today the same request, in the Copilot app, writes the item into the tracker itself, fills the fields, reads them back, and shows me the finished item in the panel — the left screen of Figure 2. The middle hands are gone.

A post like this one is the same story. Until this year it was made in four tools and three hand-offs: the text in a writing tool; the pictures in Photoshop, exported at the size the website wants and named the way the website wants; the sources gathered by hand; everything carried into WordPress and formatted again there, because formatting never survives the carrying. A film is worse: every editor has its format, the website wants another, the audience a third resolution. None of that is the work. It is the work between the work, and it is where most of the afternoon goes. In April I called it the duplication tax — every copy, every reformat, every manual sync — and put a number on it: about eighteen working days a year lost to rebuilding where you were after moving between tools.[6]

Stack those up and you see what the switch is buying. Not the slide or the backlog item — those were always going to be made — but the carrying, the renaming, the reformatting, the third paste. That is the work nobody chose, and it is also the load: every hand-off is a place where you must hold in your head where you were and what the next tool wants. When a connection lets the tool act inside another tool (that is what the connectors behind those tabs do), the hand-off you made by hand becomes a switch the tool makes for you. It is the same switch. It has only changed hands — and a switch the tool makes is one the tool has to tell you about, which is Part 3.

It also changes where the work can be. If the tool carries between the tools, the surface in front of you no longer has to be the tool that does the work; it can take the shape of the moment — the tracker's form when the work is a backlog item, the graph when it is reading, the running app when it is code, and a voice with no screen when you are walking. Typing, then dictating, then talking: that was my own path over two years, and the last step is the one that matters here, because talking is the first shape that follows you out of the room. The service follows the person's context. For thirty years it was the other way round: content went to the tool. April's post called the reversal the inversion — intelligence comes to the content — and argued it from twenty-five years of the web.[6] This post is what the inversion looks like on a screen, two years in.

Where we are. The switch removes the work between the tools — the carrying and reformatting that took most of the time and most of the load. The hand-offs you made by hand become switches the tool makes for you; and once the tool carries, the surface can take the shape of the moment, up to and including no screen. Next: what a tool owes you when it switches for you.

Part 3 — The one thing the tool owes you

Every switch the tool makes for you is a switch it must tell you about. Today it does not, and you pay three times over.

You do not know which kind of tool you are in. The draft opens beside the conversation and nothing says the tool has become a document tool — so its manners are wrong: it narrates every step inside the document, where you wanted it quiet, or goes silent at the approval step, where you wanted to see its plan. Post 4 gave the tool three roles — the coworker who reports as it goes, the assistant who hands over at the end, the director who shows the plan and asks — and the kind of tool sets the role. Nothing on the screen says the role has changed.

You repeat your rules. The rule you gave in the conversation — don't rename my files — has no defined life inside the document or at the approval step; rules are attached to places, not to the work. Tests of how well these tools keep a standing instruction put it near one in three by the end of a session,[5] and those tests were run on a tool standing still. In my own year with one of them, a third of what I said to it was about how it should respond rather than about the work — the job of the row under the input box, done by hand.

And you are asked in the wrong place. The confirm message post 4 took apart — Allow this? Allow once · Always — is a director's move made in the conversation by a tool that has not noticed it has become a process for one screen.

So the rule, and it is one line. At the switch, the tool says in one line, in the place you are moving to: what kind it has become, which role it is taking, and which of your rules it is carrying. Opening the draft beside the conversation, the first line at the top of the new window: Draft — I'll work quietly and hand over. Keeping: no renaming. At the approval step, in the message itself: Deploy — asking, because you set deploy to ask. Keeping: no renaming. Back in the conversation: nothing, because returning to the default is not a change worth a light; a single word in the panel — conversation — has changed, and that is enough.

What carries across the switch is whatever is about you and the work rather than the place: the job still running in the background, the money spent, the permission you set per kind of task, the thing you are building across days. What resets is the task, and that the tools already do — by accident, because the answer stops and starts. The line does not list the stack; it names what it kept. If it is right you do nothing and it costs a second. If it is wrong you correct it there, once, instead of discovering it three exchanges later. It marks a change, fires once and is gone, and asks nothing of you unless something is wrong — post 4's tests, passed in a line shorter than the confirm message.

The Copilot app's tabs are the first third of this line, already built: the panel names its kind. Neither the role nor the rules kept is said anywhere on that screen — nor on any screen I have found. In my own thinking tool the switches are the design rather than the accident: moving from exploring to validating changes what the tool is allowed to say, and one line at the top of the screen marks the move.

Where we are. A switch the tool makes for you must be said: one line, in the place you are moving to — kind, role, rules kept. It replaces the three things you pay for today: not knowing which kind you are in, repeating your rules, and being asked in the wrong place. The tools have built the first third of it.

Part 4 — Who is steering

Post 4 ended by asking: when a tool changes kind under you, and speaks only when something changes, and keeps rules you cannot see — who is steering? Here is the answer in three lines. You steer the kind: every switch is caused by something you did — you asked for the draft, you let the step reach the approval, you came back. The tool steers the role: it follows the kind, and a tool that knows which kind it is in knows how to behave. And the rules are steered once, at the switch, by the line — not by you re-issuing them after every switch, and not by the tool deciding in silence which of them cross.

Nobody is steering at the switch today because the switch does not exist as an event in any of these tools. A window opens, a message halts, an answer resumes, and the thing that connects them — that the tool became a different kind of tool — has no line, no place, no light. The design is not hard. It was not done because nobody drew the switch before building the tool.

I think there is a deeper reason, and it is the one I want to end the series on. When the farmer first saw a tractor he called it an iron horse: the new thing named by the one part of it that looked like something he had. I wrote in March that we are in the horseless-carriage phase of AI — the first cars had the coachman's seat and, in one 1899 design, a carved wooden horse head on the front — and that the tool-proficiency frameworks are our wooden wheels.[7] The screens in this post are what that phase looks like from the inside. Conversation-central is our iron horse. Post 4 sorted tools by what sits in the middle of the screen, and that is the right question for a tool whose middle is a thing — a document, a form. When the middle is two parties talking and the work lands beside them, the kinds may not be kinds at all, only views, and the switch not a change of tool but a change of view. I do not think we need a new name yet. I think we need to know where we are standing: where the farmer stood, naming what we see by what we knew, while it changes in front of us faster than the names can follow. What is changing is not the screen. It is the relationship — from a tool you operate to a coworker you work with — and every screen in this post is that change showing through.

That is why the four posts end on mobility. Posts 1 and 2 asked for a loop built for leaving. Post 3 named the tool's half of that loop. Post 4 found where it speaks and said a tool you can leave is one that speaks only when something changes, to where you are. This post adds the last piece: a tool you can leave is one that can change kind while you are away — finish the draft, reach the approval, come back to the conversation — and tell you, in one line, what it became and what it kept. Put the four together and the work between the tools is gone, the surface takes the shape of the moment, the voice follows you out of the room, and the service follows your context instead of the other way round. That is the whole of system response design, seen from the end: not a tidier screen, but the reason you can stand up and leave the desk. Posts 1 and 2 put it in one line I still hold to: the future of thinking tools is not to keep us in the box, but to make us need the interface less.

The post in one paragraph. A tool changes kind two ways: by release, in four stages that have moved the assistant from beside the document into it; and by context, several times an hour, between conversation, document and process. The switch removes the work between the tools — the carrying and reformatting that took most of the time and most of the load — and turns the hand-offs you made by hand into switches the tool makes for you. A switch the tool makes must be said: one line, in the place you are moving to — kind, role, rules kept. You steer the kind, the tool steers the role, the line steers the rules. And the point of it all is a tool you can leave: the service follows your context, on the screen or off it.

The next step takes an hour with the tool you use or build. Cross three switches on purpose: ask for a draft; let a step reach an approval; come back to the conversation. At each one write three words: which kind you are in, which role the tool took, and which rule you had to say again. The third column is the switch line the tool does not have.

The open question is the one the slow switch leaves on my desk. The four stages end with the assistant in the middle of the screen — and a tool whose middle is the assistant has no kind, only switches. Does that tool need a fourth set of rules — or does it need the conversation put back in the middle, because the conversation was the only place that could ever hold all three? I do not know how it ends. I know where the answer will be found: at the joints, in one line, where the person is looking.

Sources & further reading

The inherited loop — this essay is part three of five.

The full journey:

• https://www.stimulus.se/2026/09/29/the-inherited-loop-1-we-named-it-chat-and-built-it-to-fit-the-name/ (part one)

• https://www.stimulus.se/2026/09/29/the-inherited-loop-2-the-borrowed-drive-and-a-tool-built-for-leaving/ (part two)

• https://www.stimulus.se/2026/09/29/the-inherited-loop-3-the-half-nobody-designed/ (part three)

• https://www.stimulus.se/2026/09/29/the-inherited-loop-4-where-the-two-halves-meet/ (part four)

• https://www.stimulus.se/2026/09/29/the-inherited-loop-5-who-is-steering/ (part five)

Sources

1. Microsoft, Announcing Microsoft Copilot, 21 Sep 2023 (general availability 1 Nov 2023); the pane's limits with existing slides: Microsoft Tech Community, Editing Slides with Copilot Never works, Mar 2024; Microsoft Q&A, Aug 2025 ("even if Copilot can't modify the content directly").
2. Copilot in Excel required an Excel table at launch (Microsoft Q&A, 2024; ranges accepted by mid-2024); Figma, Config 2024 in review: "rename layers in a click"; Miro, 24 May 2023: Miro AI "clustering and summarizing board content".
3. Microsoft Support, Edit with Copilot in PowerPoint (2026): "Add new slides, update existing content, reorganize sections"; Microsoft 365 message centre MC1243550, Mar 2026, on-canvas rewrite routed through Copilot agent mode. Screenshots by the author, 23 Sep 2026 (PowerPoint; the GitHub Copilot app; Visual Studio Code; Recall; Heptabase).
4. OpenAI, Introducing canvas, 3 Oct 2024: "Canvas opens in a separate window, allowing you and ChatGPT to collaborate on a project"; Anthropic, Artifacts, 21 Jun 2024: "a dedicated window alongside their conversation".
5. Panavas et al., HANDBOOK.md, Jul 2026 (arXiv 2607.25398): "the strongest evaluated model passes 36.2% of trials"; Zhang et al., Many-Tier Instruction Hierarchy in LLM Agents, Apr 2026 (arXiv 2604.09443): "even the current frontier models perform poorly (~40% accuracy) when instruction conflict scales".
6. Michael Käppi, Your content doesn't need another tool — it needs intelligence that shows up, stimulus.se, 2 Apr 2026: the duplication tax, "144 hours per year — eighteen full working days — to rebuilding context after switching between tools" (the 144-hour figure is cited there from industry research; verify the primary source before print), the four waves, the inversion. stimulus.se/2026/04/02/your-content-doesnt-need-another-tool-it-needs-intelligence-that-shows-up/
7. Michael Käppi, The AI literacy paradox — the real leap is when we let go of AI as a tool, stimulus.se, 26 Mar 2026: the categorical shift from tool to collaborator; "We're in the horseless carriage phase of AI"; the 1899 "Horsey Horseless". stimulus.se/2026/03/26/the-ai-literacy-paradox-the-real-leap-is-when-we-let-go-of-ai-as-a-tool/