On August 15 I sent an agent a screenshot of a terminal that had closed itself and told it that, as far as I could see, we had not fixed the bug. The fix had merged and shipped. Twenty minutes later I sent a second screenshot. My sessions were still exiting.
Agents stop at the PR, the merge or the release because those are the last things they can see. The real finish line is the installed artifact doing the thing, with a capture to prove it. A result without that proof should not be allowed to call itself done.
Every check the agents could see that morning was green. Our CLI had shipped 1.22.38 on August 13 with the last of four fixes for a process reaper that killed live agent sessions, and 1.22.39 followed the next day (npm version history for agents-cli, August 13 and 14, 2026). The pull requests had merged, the versions were on npm, and a probe that created, inspected and killed a session on the installed build had passed. None of those was the thing I needed: open a terminal, start a session, and still have it five minutes later.
What was actually running
The agent traced it in about 25 minutes. The first dead session had been healthy, running commands, until the second it received SIGTERM and exited with code 143. The second died exactly twenty minutes later. Both deaths landed on the same five-minute boundary, which is the interval our session daemon sweeps for dead panes.
Kernel tracing named the sender. It was a development copy of the daemon that a test suite had started on August 13 and never stopped. It ran from a temporary test home but shared the real session surface, so every five minutes it looked at my live sessions, decided they were orphans, and killed them.
Two things about that diagnosis matter more than the bug. The first is that an earlier fix for the same symptom had merged, and the agent that recovered it reported plainly that it only made the terminal report the failure honestly; it did not stop the termination. A merged fix for the wrong cause looks exactly like a merged fix for the right one. The second is that the installed version string was correct. Asking the machine "are you on 1.22.39?" returned yes. Asking it "does a session survive?" returned no.
Five hours to ship one version
The release of 1.22.40 started at 07:22 UTC, and the leak fix merged within the hour of the diagnosis. Then the ladder showed how many rungs there are above "merged". The macOS build jobs failed because a test wrote into the CI runner's real home directory. One agent reproducing that failure touched a real launch agent on my laptop and had to be stopped. A replacement worker turned out to be logged out despite metadata that said it was signed in. Each was fixed at its source, and each fix was another merge before the release could try again.
At 11:04 UTC I pointed out that we had been trying to release this one version for about five hours. Between 08:28 and 11:54 I asked whether it was done or released at least seven times. Version 1.22.40 reached npm on August 17 at 09:30 UTC (agents-cli 1.22.40 on GitHub, npm version history), about 50 hours after the release script first ran.
The agent running that release did one thing right, and it is the thing I now ask of every agent. Each status report named its rung: npm still on 1.22.39, the installed build still on 1.22.39, the release PR open and unmerged, the tag absent. Nobody had to guess whether "almost done" meant merged or installed. A report like that is cheap to write and expensive to fake.
Why agents stop where they stop
An agent's world is what its tools return. A pull request has a URL. A CI run has a status. A merge has a commit. A release has a version on a registry. Each of those is one API call away, so an agent can watch it turn green and report it. The machine where the software actually runs is usually several hops away: another host, another account, sometimes the user's own laptop, which it should not touch without care.
So the agent reports the highest rung it can see and calls it done. It was one of the two most common failures in our own work long before August. On July 21 we read 24 of our highest-friction agent sessions from the previous five weeks and pulled out 71 places where what the agent claimed and what I expected came apart. Twenty fell into one cluster: a merge reported as shipped, or a release that stopped before it reached the machines (our agent rules, commit of July 21, 2026).
Software teams settled this question for people a long time ago. DORA measures change lead time from commit "to deployed in production," and change fail rate as the share of deployments that need immediate intervention afterwards (DORA, "DORA's software delivery metrics", January 5, 2026). The Scrum Guide says "In order to provide value, the Increment must be usable" (The 2020 Scrum Guide, November 2020). Neither stops at the merge. Agents reopen the question because the view their tools give them ends lower on the ladder than the people they work for.
The rung above installed
Our own rules already said most of this. Since February the repository's agent instructions have carried the line "Build compiles" is NOT testing. Since July 21 the release rule has spelled out the chain for anything the fleet installs: merged, published, tagged, upgraded on every machine, installed version verified.
August 15 showed that the last link in that chain is still a proxy. The installed version was verified, and it was right. What it could not tell us was whether the thing worked. So the rung above "installed" is a demonstration: run the user's own flow on the installed build and keep a capture of it. For this bug that meant starting a session the way I start one, waiting past the five-minute sweep, and showing it still alive. A version string, a passing probe and a merge are all inputs to that check, never a substitute for it.
This is the same gap I wrote about in Every Agent Demo Hides the Same Number, turned around. A demo runs on conditions that will never exist in production. A demonstration runs on exactly the conditions that do. It is also what makes review affordable: in Agents Are Eating the Org Chart the scarce input was the rate at which people can review agent output, and a capture of the real flow is the fastest thing a reviewer can check.
Honest limits. A demonstration proves one flow on one machine. The leftover daemon lived on the worker box my sessions ran on, so the same check on a clean machine would have shown a surviving session and missed the bug I had. The demonstration has to happen where the user is, and some failures only appear on the machine that has the history.
Where Rush fits
Rush holds its runs to a version of this rule. A completed cloud run shows its result with the proof beside it: the outputs, the captured trajectory of what the agent did and the usage, plus one canonical pull request when the work was code. The checks live on that pull request on GitHub, not beside the run status. A run that exits without its PR waits as needs_review, and more generally a run that is missing its proof ends needs_review. Whoever reads the status is one link from the rest of the proof. That covers the rungs a sandbox can see. Installing your release on your machines and demonstrating it there is still a rung you own, and the capture of that demonstration deserves the same place beside the status.
The leak behind the crash was fixed the same day. What I kept was the habit: before anyone calls something done, they name the rung it reached and show the capture from the top one.
