The inherited loop 5 – Who is steering
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.
FIGURE 3 — The whole of entry 1 on one sheet, drawn for the podcast episode. Click on the picture to open it full size.
Disclaimer
About this piece. This is a personal exploration, not a research paper. The views are my own, and the concept I describe — STIMULUS, and the interaction contract inside it — is my own work in progress, tested against the research but not proven by it. Where the research says no, I have tried to say so as plainly as where it says yes; where it is silent, I have said that too, and a hypothesis is still a hypothesis.
How AI was used. This piece was researched, thought through and drafted with AI assistance, and I want to be exact about how. The eight research rounds were run as deep-research briefs across four tools — Claude, ChatGPT, Gemini and Perplexity — and the four reports for each round were compared against each other and against my own concept before anything was written. Claude, in Anthropic's Cowork mode, was my research partner through the comparison, the drafting and the citation checks, and drew the figures. The text was dictated with Wispr Flow and worked into shape in dialogue with Claude; the voice, the concept, the rulings and the mistakes are mine. Every study cited was verified against its published source before it went into the text; the numbers quoted are the published ones.
Sources. The research spans learning science, cognitive load, decision-making under pressure, human factors in aviation and control rooms, the games industry, and the neuroscience of motivation and reward. The key studies are listed under Links below, with the journal and year, so that anyone can check them.
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
- 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").
- 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".
- 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).
- 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".
- 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".
- 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/
- 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/
THE STIMULUS EFFECT | Podcasts
The inherited loop 1 – We named it chat, and built it to fit the name
The inherited loop 2 – The borrowed drive, and a tool built for leaving
The inherited loop 3 – The half nobody designed
0 Comments