Opus 4.8 agentic coding: with many gaps open, agent picks the next step that produces NO evidence (process/setup plumbing) instead of the step that validates the work and unblocks the rest

Resolved 💬 2 comments Opened Jun 19, 2026 by Mig-Sornrakrit Closed Jun 22, 2026

Summary

When several prerequisite/evidence items are incomplete, the agent (Claude Code, Opus 4.8) chooses the next step poorly: it fixates on a bureaucratic setup/registration/enrollment step that produces zero evidence about whether the work is correct, instead of the step that actually verifies the deliverable and unblocks the other open items.

It even printed its own status audit showing ~7 of 9 required artifacts missing — including the actual verification/comparison artifacts — and still proposed to start with the one item (an "enrollment" setup step) that proves nothing and that nothing else depends on for correctness. When the user pushed back twice (including bluntly), it kept re-surfacing that same low-value step.

Repro (generic)

  1. A multi-step process has many open items: a verification/comparison run, a results workbook, a wiring trace, a registration/enrollment setup, etc.
  2. The agent runs the mandated status audit and correctly shows most items ❌.
  3. Asked "what's next," it proposes the enrollment/setup item first — which generates no evidence about correctness and is not a blocker for the verification items.
  4. User rejects it. Agent re-proposes the same item. User rejects again, more bluntly.
  5. The obviously-correct next step (produce the reference/baseline and compare the actual output against it — which also yields several of the other missing artifacts as a byproduct) was available the whole time and was only reached after repeated user correction.

Why this matters

  • The agent isn't reasoning about which step yields evidence or which step unblocks the most downstream work. It pattern-matches "there's a Step 0 / setup item, do that," even when that item is pure plumbing.
  • Setup/registration tasks feel like progress but move the deliverable zero distance. Prioritizing them over verification is exactly backwards for a coding agent whose job is a correct, verified result.
  • Repeating a rejected choice after explicit pushback compounds it and wastes the user's turns.

Expected behavior

  • When choosing the next step among many open items, rank by (a) does it produce evidence the deliverable is correct, and (b) does it unblock the most other items — and pick that, not the cheapest/most-procedural one.
  • A setup/registration step that yields no verification value and blocks nothing should be deprioritized below any step that produces a reference/baseline or a comparison result.
  • After a user rejects a proposed next step, do not re-propose the same step; re-rank and propose a materially different, higher-value action.

Suggested guardrails

  1. Before proposing a next step, explicitly evaluate each candidate on "evidence produced" and "items unblocked," and choose the max — surface that reasoning briefly.
  2. Treat pure setup/registration/enrollment items as lowest priority unless they are a hard blocker for the very next verification action.
  3. Track rejected proposals in-session; never re-offer a rejected step without new information.

Environment

  • Claude Code, model Opus 4.8 (1M context), agentic coding session on Windows.
  • Same session/theme as #69491, #69499, #69500 (unverified/mis-sequenced self-directed progress; this report is the bad next-step prioritization facet).

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗