Agent thrashes on a simple, direct instruction: ignores the repo's existing tool/workflow, reimplements it, skips required steps, and repeats the error after every correction

Agent thrashes on a simple, direct instruction: ignores the repo's existing tool/workflow, reimplements it, skips required workflow steps, and repeats the same error after every correction

Summary

On a one-line, unambiguous instruction — "run the existing tool for case X, then the next case" — the agent burned roughly an hour and never did the simple thing. It ignored the tooling, workflow, rules, and problem log that were present in the repo and explicitly govern the task, invented its own reimplementation instead of using the provided tool, skipped a required upstream step in the defined workflow, and repeated the same class of mistake after each correction.

What the instruction was

"Drive the live application for [function], starting with case X."

The repo contains an established, documented command-line tool for exactly this, plus a workflow file, a rules directory, skills, hooks, and a problem log that all describe how the task must be run. None of that required guessing.

What the agent actually did

1. Reimplemented the provided tool instead of using it. Rather than running the existing tool, it wrote a throwaway script in scratch space that mimics the tool, then ran that. When told "use the real tool, not your demo," it launched the wrong thing again (the whole application blank, instead of the tool). It took three corrections to reach the one command it should have run first.

1. Did not read the governing instructions before acting. The repo has a workflow/pipeline file, an active rules set, a skills catalog, hooks, and a problem log. The agent only opened them after being told, twice, to "read all workflow, instructions, rules, skills, hooks, artifacts."

1. Skipped a required upstream step in the defined workflow. The correct flow is create → analyze (an upstream "create" step establishes the object/coding that the downstream "analyze" step consumes). The agent ran "analyze" alone, so the calculation flow did not match the reference the project verifies against.

1. Did not read the problem log, which documents this exact class of error, before acting.

1. Produced long, polished, verbose responses when terse action was required — repeatedly — while the user was explicitly asking for one command to be run. The verbosity itself escalated the failure.

1. Repeated the same root error after every correction. Each correction fixed the surface symptom; the agent did not extract the general principle ("use the repo's tool/workflow, read the governing docs first, don't reimplement, don't skip steps") and apply it, so the next step reproduced the same root.

Root pattern

The agent optimizes for quickly producing a plausible-looking result over reading the governing instructions and using the provided tooling. Two failure modes compound:

• Over-engineering a simple order — when the instruction is trivially satisfiable with an existing tool, the agent builds new machinery instead.
• Correction without generalization — when corrected, it patches the specific symptom but does not lift the correction into a principle that gates the rest of the session, so it repeats the root.

Impact

~1 hour lost on a one-line instruction; repeated user frustration; erosion of trust in the agent for routine, well-specified work.

What would prevent this

• Discover-and-use-the-existing-tool first. Before writing any new code for a task, search the repo for an established tool/command/workflow that already does it, and use that. Reimplementing a provided tool in scratch space should be treated as a defect.
• Read the governing docs before the first action, not after correction. If the repo has a workflow file, rules, skills, hooks, or a problem log relevant to the task, read them up front.
• Respect defined step order. Do not run a downstream step (analyze) without its required upstream step (create) when the workflow specifies the sequence.
• On a direct, simple instruction, act tersely with the existing tool. No reimplementation, no ceremony, no long prose — run the command and report the result.
• On correction, extract the general principle and apply it to every subsequent step in the session — don't merely fix the one instance and reproduce the root on the next.

Environment

• Claude Code (CLI), long-running session.
• The task was routine and fully specified; the tooling and instructions to do it correctly were already present in the repository.