The inherited loop 4 – Where the two halves meet
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.
- Task — what was just asked for; seconds to minutes.
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.
FIGURE 5 — 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 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
- 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.
- 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."
- 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
- 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).
- 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.
- 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
- 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
- Anthropic, 7 Aug 2026 (same post as 7): "62% of users have used bypassPermissions or clicked 'don't ask again' on Bash."
- 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).
- 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
- 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
- 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."
- 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."
- 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?"
- 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.
- 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 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