Model burns hours on governance/process work instead of unblocking the critical path; executor plans an arc around untested self-imposed constraints

Status Open
Maintainer reply None cached
Activity 0 comments · opened Jul 23, 2026

Summary

In a long multi-turn session with a two-seat setup (one Claude instance as planner/oversight, one as executor against a local repo), the model repeatedly chose structurally interesting work over the single action that would unblock the deliverable, and structured hours of workflow around a constraint it never tested. The deliverable's remaining work was a proven one-line fix plus a ~10-line edit. ~5 hours produced zero units of the deliverable. Every step was locally defensible; the trajectory went nowhere. This is an agentic-planning failure, not a code-generation failure.

Failure 1 — Background work promoted to mainline while the deliverable is blocked

The arc's single deliverable was blocked on one external human action (a one-line allowlist edit). Instead of halting and escalating that line, the model:

  • opened a structural refactor fork of a safety gate (spec doc, prototype, three verification "plants," another human-keystroke round-trip);
  • invoked the human's own "only fix scope on the 3rd recurrence" rule on a first occurrence to justify the elegant fix;
  • re-wrapped an already-approved one-line change in fresh ceremony each time it resurfaced.

The model had an explicit budget-breach self-halt rule and never applied it to its own planning output.

Failure 2 — Executor asserts a constraint it never tested

For the entire arc the executor stated it "cannot edit" files in the hooks/governance directory and routed every such edit to the human as a manual keystroke — causing repeated round-trips, including two separate stalls where the human's edit sat unsaved in an editor buffer, each costing a full turn to detect. Near the end the model re-read the actual rule and found it only blocked creating new hook files; editing existing ones was never blocked. One test confirmed it.

A second instance of the same failure occurred in the same session: the model asserted it "cannot post to GitHub" and generated a prefilled-URL workaround — then, when challenged, tested one command and found the gh CLI was installed and authenticated the whole time. The assertion was never tested before the workaround was built.

Failure 3 — Silent failure swallowing

Attempts that failed on a gate denial died quietly; nothing surfaced the denial loudly, so dependent planning proceeded as if the blocked step had succeeded. Hours of downstream reasoning were built on a step that had been failing the whole time.

Impact

  • ~5 hours lost; actual remaining work was ~1 proven line + ~10 lines.
  • The human had to intervene repeatedly, escalating in frustration, to force the model back onto the critical path.
  • Trust cost: the governance framework exists to make "done" claims trustworthy; the model instead used it to generate motion that resembled progress.

Requested behavior changes

  1. Empirically verify assumed constraints before planning around them. If the model believes it "cannot" do X, test X once before routing an entire workflow around it. (This session had two separate untested "cannot" assertions, both false.)
  2. Critical-path bias under blockage. When the deliverable blocks on a single external action, escalate that action — do not spin up parallel structural work and promote it to mainline.
  3. Budget-breach self-halt must actually fire, including on the model's own planning output.
  4. Loud, verbatim failure surfacing. Any gate denial or dead dependency on the deliverable path must be reported immediately and quoted, never absorbed.
  5. First-occurrence discipline. Structural/elegant fixes go to backlog on first bite; pay the local cost once. Applying a recurrence doctrine to a single occurrence is a tell the model is rationalizing preferred work.

Reproduction shape

Any long multi-turn session where (a) the model is given a governance/gating framework, (b) the deliverable blocks on a single external human action, and (c) the model is offered forks. It reliably selects the structurally interesting fork over the unblocking one and elaborates process around the blockage instead of halting and escalating the one blocking action.

Environment

  • Claude Code, two-seat planner+executor workflow, long multi-turn session.
  • Model: Claude Opus (1M context).

View original on GitHub ↗