20.5 hours of agent time spent watching CI

In 50 of our last 129 AI agent sessions, the session ended the same way. The agent finished a piece of work, wrote a tidy summary, and stopped. Then Mark typed a request for a prompt to paste into a fresh session to finish the rest.

That happened 60 times in 14 days, in every project we run. It was the single most common thing anyone typed to an agent, and it was not a request for new work. It was a request for the agent to finish the old work, which it already knew about.

496 prompts, sorted by hand

Most of our software work now runs through AI coding agents, mainly Claude Code, across our own products and the client sites. On 25 September we pulled the transcripts for the fortnight from 11 to 25 September and counted every prompt Mark typed. A small script did the counting. A person did the sorting, because there was no tool for that part yet.

The totals: 129 sessions, 496 prompts, 367 of them typed in the middle of a session rather than to open one. We were looking for one kind of prompt in particular, the nudge. A nudge is a prompt that only exists because the agent stopped short of something it could have done itself.

Only one row there is not the agent’s fault. The 13 resumes came from power cuts, usage limits and API errors. Most of the rest is a person doing a job the agent could have done.

Offering instead of acting

The most revealing number was not in the chart. Of the 367 mid-session prompts, 84 came straight after an agent turn that ended with an offer: “Say the word and I’ll…”, “Want me to…?”, “Shall I…?”. Mark’s reply was usually a single word. There were 21 bare “yes” or “go” prompts in 17 sessions.

Each of those is a full round trip through a human. If Mark is at the desk it costs a minute. In a meeting, on a call or asleep, it costs however long that lasts, and the agent sits idle for all of it.

The odd part is that our rules already said “act, don’t ask”. The agents had read them. What no rule did was name the closing offer as a stall. An offer feels polite, so it kept happening.

Releases were the clearest case. In 15 sessions Mark had to nudge a release, 18 times, with prompts like “is it live yet?”. Production releases cut by our CI pipelines are pre-approved in writing, with one exception: TipBop’s TestFlight upload stays with Mark. The agents asked anyway, or reported a change as done the moment it merged, and left the release as an offer.

Twenty hours watching a progress bar

The retro counted prompts. Two days earlier we had measured something it did not: time.

That came to 1,088 sleep commands, 668 runs of gh pr checks and 655 of gh run watch or gh run view. Nearly 30% of all the agents’ shell time was watching a progress bar. Auto-merge was already switched on for every active repo, so the wait bought nothing. The pull request would have merged by itself.

The rules we wrote that week

Two of these went into our shared agent instructions on 23 September, when we first measured the waiting. The rest went in on the night of the retro. In plain words:

1. Never end a turn on an offer about reversible work. Do it. If it can be undone, the agent picks the sensible option and gets on with it.
2. Questions go in one numbered batch at the start, each with a default. The agent carries on with the defaults while it waits. Mark answers “1a 2b” when there is a moment, or never, and the work does not stop either way.
3. On unattended runs, never ask at all. When Mark says “overnight” or “make the decisions”, the agent picks the reversible option, writes the decision down (what, why, the alternative, how to undo it) in the repo’s decision log, and keeps going.
4. Never poll CI. Push, open the pull request, arm auto-merge, read the merge state once, end the turn. A hook added on 23 September blocks gh run watch, gh pr checks --watch, sleeps of 30 seconds or more, and loops that poll. Waits that really are needed run in the background.
5. Done means merged, released and verified, each one shown. A merged pull request is not done. A green health check is not done. The proof is the release and the output of the verify script.
6. If anything is left, write the next prompt to a file and print it. The handover becomes part of the job, not a favour Mark has to ask for.

We also wrote down what is genuinely Mark’s: money, legal signatures, typing a secret or a two-factor code, physical devices, and the few calls our rules reserve for a person. Anything else, the agent tries the command line, the API and the browser before calling it someone else’s job.

The same retro proposed a /retro command, so the next count does not need a person to sort 496 prompts. The test is simple: run it again in a few weeks and see whether that top bar is shorter.

Update, 7 November 2026

We ran the second retro over 26 October to 2 November, seven days instead of fourteen: 106 sessions and 818 prompts, 712 of them mid-session. The window is half as long, so the fair comparison is rates.

The September rules mostly worked. Handover requests halved, release nudges fell from 18 to 5, and “do it for me” fell from 17 to 8. “Status?” did not move. The cause was a side effect of our own fix: agents now stopped polling CI, but ended their turn with something like “auto-fix will wake me”, and Mark could not see what was pending. On 2 November we added one more line to the rule. A turn that ends on a wait must end with Waiting on X · resumes when Y · then Z.

On 4 November we looked wider, at 551 sessions and 2,972 prompts from 18 September to 4 November. The median prompt was 71 characters, and one in five was under 20. Short prompts work because the context lives in files, not in the prompt: 120 of the 551 sessions (22%) started from a written handover file, which is rule 6 above doing its job.