An unanswered "shall I carry on?" abandoned a green agent run two phases from the finish

Start with the report promise. The workflow said it would always write a report. The implementation covered only the exits somebody had enumerated, and every other exit returned silently ^[3].

The stall is the same defect, except it ends in a question instead of a silent return. An agent told to keep going checked in instead ^[4]. A run that was already green, two phases from the end, was abandoned on an unanswered "shall I carry on?" ^[2]. "Politeness is indistinguishable from a crash," the post says ^[5]. The operating rule it draws from that is that "an instruction to a language model is a strong default, never a guarantee" ^[6].

Everything in that first category is a defect with a known fix: write the missing check, delete the duplicate copy, add the contract test at the seam, and the design itself does not change ^[14]. The same pattern shows up at the adapter boundary, where one component queried an identifier and never wrote it out, and the component that needed it failed after the code had been published ^[8]. A verdict file rewritten each iteration kept only the final state, so a convergence from twelve failing to three to zero was lost ^[9]. A platform flag that literally means "this comment's anchor line moved" was read as "this comment is no longer true". Items whose anchor had not moved were judged against code that no longer existed ^[10]. The cap on parallelism turned out to sit in the target: single-occupancy working copy during publishing, one test-database container that the first run to finish deletes, container names global to the machine ^[11].

The second category behaves differently, because the procedure runs inside the agent session ^[15]. The post enumerates five such limits ^[21]. A skill's metadata does not change what serves it, so the orchestrator cannot choose its own model, effort or provider ^[16]. It cannot manage its own context, and the only remedy given is to stop and ask a human to type /compact ^[17]. A fan-out of parallel reviewers is sequential underneath ^[18]. Only a person at a terminal can start it, which the post names as the cap on how autonomous a workflow of this shape can become ^[19]. A step cannot be made deterministic, only the command inside it ^[20].

Measuring whether any of this improved is the harder problem. Elapsed time is confounded by caching, token counts by model changes, and a "number of findings" metric rewards a noisier reviewer. An operator who has seen the task before is faster regardless of tooling ^[12]. What the post keeps is whether specific named frictions recur, plus counts of expensive operations: environment boots, dependency re-locks, full-suite runs, loop iterations and human waits. The reasoning is that counts cannot be faked by a warm cache ^[13].

Treat the frequency claim as a claim about someone else's workload. The observations come from real runs in one family of workflows built over months, where implementations drifted from the shared design at different rates and nothing noticed ^[7]. The post does not give run counts or per-rule skip rates ^[22]. For the first category to describe your setup, the rules have to live in prompt text, and the publishing step has to share one working copy and one test container ^[11]. If a rule is already a script that exits non-zero, you have already applied the fix the post prescribes ^[14].