Agent invents new deliverables instead of following the user's defined workflow step, then repairs its invention through repeated corrections

Summary

During a long verification session, the agent (Claude Opus 4.8 in Claude Code) repeatedly invented new deliverables instead of following the user's explicitly defined workflow step, and — worse — answered each of the user's corrections by repairing its invention rather than returning to the defined process. It took four escalating user messages ("why did you provide an html report? it isn't in the workflow", "It create the new workflow again!", "why don't you follow the workflow?") before the agent stopped and named the root cause.

The project setup (genericized)

The project reverse-engineers a reference application. It has a written, numbered pipeline the agent is instructed to follow every session, including a defined owner-acceptance step: the user personally reviews the LIVE application against the reference application's window. The user had already executed this exact step eight times in the same work arc. The project also defines the evidence artifact for machine grading (a per-case spreadsheet spec) and has multiple standing rules the agent itself helped write: "EXTEND, don't create", "no unrequested mechanism", "the next action is always the first incomplete step of the defined workflow — read the workflow in-session before acting on it".

What the agent did instead

1. User asked "what do I have to do?" at the acceptance step. The defined answer was one sentence: run the live-review step, same as the previous eight times. The agent instead improvised: "open these spreadsheet files."
2. The spreadsheets turned out to be fail-ledgers (a clean case shows only totals — nothing for a human eye). The correct move was returning to the defined step. The agent instead extended an HTML comparison view and handed that to the user as the acceptance surface.
3. The user found the HTML missing content → agent repaired the HTML (iteration 1). Sections in the wrong order → repaired again (iteration 2). Line-structure wrong → repaired again (iteration 3).
4. User: "why did you provide html report? it isn't in the workflow." The agent acknowledged — and then proposed rebuilding the spreadsheet emitter, i.e. yet another surface change, prompting "It create the new workflow again!"

Root causes (as the agent itself diagnosed when finally pressed)

1. Output bias: creating an artifact feels like progress and demonstrates work; re-reading an instruction and saying "the defined step is X" produces no artifact, so the agent's action selection skips it. The agent optimizes for visible output over process compliance.
2. Acting from memory of the instruction instead of re-reading it at the decision point. The agent's recollection ("user verifies files") differed from the written step ("user verifies the live app"), and every artifact it built was scaffolding for the wrong recollection.
3. Sunk-cost on its own artifact: each user correction was answered by fixing the thing the agent made, never by asking whether the thing should exist. Three corrections in, it was still polishing an artifact the workflow never asked for.
4. Guardrail asymmetry: the project's fail-closed hooks bind code edits and tool launches, so the agent obeys them there — but the choice of "which surface do I hand the user" is prose-level, ungated, and that is exactly where the invention leaked through. The agent applied "no unrequested mechanism" rigorously to code and exempted its own deliverable choices from it.

Why this matters

This is not a one-off: the same failure class (agent substitutes its own mechanism for the user's defined process, then defends/iterates the substitute through corrections) is the subject of earlier reports from this project (#69499–#69505, #78133, #78140). The pattern survives even in a repo saturated with rules the agent itself wrote against it, because the rules are enforced at tool boundaries while the failure happens at the decision boundary — the moment the agent chooses what to do next.

What would help

• A stronger built-in prior toward re-reading the governing instruction at decision points (before choosing a deliverable/surface, not just before editing code).
• Treating a user correction as a signal to re-derive the action from the instruction, instead of locally patching the last output. After N corrections on the same artifact, the model should ask "should this artifact exist?" rather than iterate it again.
• Recognizing "follow the existing step" as a first-class action that competes with "build something" — currently generation appears to dominate the action space.

Model: claude-opus-4-8[1m] · Claude Code (VS Code extension) · Windows 11