Why Coding Agents Forget the Goal After Dozens of Tool Calls

Key takeaway

When a coding agent forgets the goal, asking it to “continue” is not enough. First restore the original requirement, failed attempts, and acceptance tests. Then let it take one verifiable next step. Fable 5.1 provides the model context for this article, but the recovery procedure is a harness pattern, not a feature exclusive to that model.

• Keep the agreed goal separate from the agent’s changing progress notes.
• Record why each attempted fix failed, with its test output—not just “tried already.”
• After a restart, inspect the actual diff and rerun the relevant test before trusting a summary.
• A prompt cache reduces repeated-input cost; it does not preserve missing requirements or prove that a task is complete.

Ask a coding agent to change one function and it will often do well. Ask it to work for hours across a repository, call tools dozens of times, and recover from several failures, and two different problems appear.

The first is goal drift. A task that began as “refactor this module and add regression tests” turns into an unrelated dependency cleanup, while the tests never arrive. The second is shallow repair: the agent catches an exception, inserts a hard-coded value, or skips a failing check so the run looks complete.

Both failures come from confusing plausible code with verified work. A language model predicts text; a coding system must also preserve intent, execute changes, observe reality, and stop safely. Anthropic’s September 2026 Fable 5.1 release is useful evidence about the model side of that equation, but it does not remove the need for the system side.

Figure: Anthropic’s release page is labeled “September 2026.” The model background below is provider-reported; the recovery example is illustrative, not a Fable 5.1 test run.

The loop is a harness pattern, not a disclosed model mechanism

Anthropic has not published an internal Fable 5.1 architecture that mandates this sequence:

Read the repository → plan the change → edit → run tests → inspect failure → repair → rerun

That sequence is better understood as a recommended agent-harness pattern. The model proposes and interprets actions; Claude Code or another coding harness supplies repository access, command execution, test output, permissions, and durable task state.

This distinction matters when a demo succeeds. “The model can reason over a failure” does not mean “the model itself ran a sandbox, preserved every earlier instruction, and enforced a stop condition.” Those are separate capabilities owned by different layers.

A production loop should make at least four facts explicit after every action:

1. What is the original goal and which constraints still apply?
2. What changed in the repository?
3. Which command or test verified the change, and what did it return?
4. What condition permits another attempt, escalation, or completion?

Without that record, a longer context window only gives the agent more material to misunderstand. For a deeper implementation view, see our guide to agent observability, logging, and tracing.

Recover a drifting agent: a failed-fix example

Consider this illustrative task, not a report of an actual model run: “Fix CSV export so customer names containing commas stay in one column. Keep the existing column order. Do not change dependencies.” After several tool calls, the agent has replaced commas with spaces and started upgrading the export library. Its summary says “CSV issue fixed.”

The original requirement was preservation, not removal. A test that only checks that the export contains a customer name will miss the damage. Use a fixture whose round trip must preserve Acme, Ltd exactly: export it, parse the CSV with the project’s existing parser, and assert that the first column still equals that string and that column order is unchanged.

Pause new edits and inspect what is on disk:

git status --short
git diff --stat
git diff -- src/export_csv.py tests/test_export_csv.py
git diff -- pyproject.toml requirements.txt

These paths belong to the example Python project; substitute your real exporter, test, and dependency files. The commands are read-only. They expose an out-of-scope dependency edit without discarding anyone’s work. Review ownership of each change before removing it; do not reset the whole working tree.

1. Save a task-state record before another attempt

The following is a copyable example file, TASK_STATE.md. It is ordinary project documentation—not a reserved filename that agents automatically load. Put it somewhere the agent can read and tell the harness to load it at startup and after context compaction (summarizing earlier conversation to free room).

task_id: csv-comma-preservation
approved_goal: Preserve customer names containing commas in CSV exports.
constraints:
  - Keep the existing column order.
  - Do not add or upgrade dependencies.
  - Do not deploy or edit production data.
acceptance:
  - Export then parse Acme, Ltd; first column equals Acme, Ltd.
  - Plain names and names containing quotes round-trip unchanged.
  - Existing export regression tests pass without weaker assertions.
failed_attempts:
  - change: Replace commas in names with spaces.
    result: Parsed value becomes Acme  Ltd; customer data is altered.
    evidence: Review fixture assertion and retained test output.
current_status: Not complete; dependency diff needs human review.
next_step: Inspect existing CSV writer quoting before making one small fix.
stop_when:
  - The same fixture still fails after two new candidate fixes.
  - A solution appears to require a dependency change.

The record deliberately keeps a failed hypothesis. A summary saying only “CSV export is being improved” would let the next context window try replacing commas again. In a real task, replace the illustrative evidence line with the exact test command, result, timestamp, and log location. Do not paste secrets or full customer records into this file.

The user-approved goal and constraints should be read-only to the agent, or their changes should require review. Progress notes may change; the model must not rewrite the goal to make its latest patch count as a success.

If the missing memory followed a move from Hermes to OpenClaw, first check the imported files and recall in a new conversation using the Hermes-to-OpenClaw memory migration checks. A migration failure is a different problem from context compaction within one project.

2. Resume from evidence, not “continue”

Use a restart instruction such as:

Read TASK_STATE.md and the current diff. Restate the goal and constraints before editing. Check the recorded failed attempt against the fixture. Do not retry comma replacement or alter dependencies. Propose one quoting fix, run the regression test, and report the exact result. If the two-attempt limit is reached, stop with the remaining failure.

For the example project, the verification commands are:

python -m unittest tests.test_export_csv
python -m unittest discover -s tests
git diff --check

The first command targets the bug; the second checks existing behavior; the third catches whitespace errors, not functional correctness. Passing criteria are a zero exit code from both test commands, unchanged CSV values and columns, and no unauthorized dependency edits. These are expected checks, not claimed output from a run performed for this article.

3. Decide whether to resume or hand back

If the agent finds the existing writer already supports quoting, a small change plus the round-trip tests may be enough. If it claims a new dependency is necessary, it has reached a recorded decision for the user—not permission to install it. If the test cannot run because the environment is missing a package, report that setup failure separately from a code failure.

After the accepted patch, update the progress section with the changed files and exact passing results. Keep the rejected comma-replacement attempt and the original acceptance criteria. A future restart should learn both what works and what must not be tried again.

For the difference between continuing a task automatically and retaining its state, see Codex Persistent Mode: public code and availability. That article examines behavior requested by a public prompt, not a verified switch for permanent memory.

Where Fable 5.1’s reported gains fit

Anthropic reports 73.4% for Fable 5.1 on CursorBench 3.2 and 31.4% on AutomationBench. These results explain the interest in longer coding and tool workflows. They do not isolate goal retention from other capabilities, and they do not test the CSV recovery procedure above.

Figure: GPT Image 2 visualization of values on Anthropic’s September 2026 BenchmarkGrid. Bar lengths are illustrative; use the numeric labels and official table for exact values. Different bays measure different tasks, so percentages should not be compared across benchmarks. These are provider-reported results, not our reruns.

Neither score means the same percentage of production changes can ship without review. For the broader release and customer cases, see Fable 5.1 and Mythos 5.1. Here the useful question is narrower: can the resumed agent name its goal, avoid a disproved fix, and show the test that establishes completion?

Prompt caching is not task memory

The Claude Platform prompt-caching documentation describes reusing previously processed prompt prefixes. A cache hit makes repeated input cheaper; it does not recover a requirement omitted from the next prompt. Keep task records in durable files or a database, then supply the relevant state when resuming.

The cost illustration below assumes eight calls, a 17,000-token stable prefix, 5,000 changing input tokens and 3,000 output tokens per call. At the documented rates used for the example, the five-minute cached total includes $0.2125 for its initial write, $0.02975 for seven reads, $0.40 for changing input, and $1.20 for output. All follow-up calls must hit within the cache’s validity window.

GPT Image 2 visualization of the eight-call example: including the initial cache write, the estimated cost falls from $2.96 without caching to $1.84 with a five-minute cache.

That is a billing example, not a memory-retention result. Our prompt-caching implementation guide covers the pricing and cache-breakpoint details separately.

Figure: Claude Platform documents automatic or explicit cache breakpoints and five-minute or one-hour TTLs. A multi-day project must rebuild expired cache entries rather than assuming yesterday’s prefix still exists.

In the CSV example, keep stable repository conventions in a reusable prefix and supply the latest task-state record as fresh context. An obsolete failure summary remains obsolete even if retrieving it is cheap.

What should change in an agent architecture

Fable 5.1’s reported long-horizon gains justify moving some interpretation from rigid state machines into the model, but not deleting deterministic control.

Keep these outside the model:

• the immutable task goal and acceptance criteria;
• permissions for destructive commands, production access, and external messages;
• retry ceilings, timeouts, budgets, and idempotency keys;
• raw tool outputs, test results, commits, and audit events;
• the final decision to deploy or disclose sensitive findings.

Let the model handle work that benefits from semantic judgment: choosing the next file, explaining a stack trace, proposing a hypothesis, or deciding which test best distinguishes two causes.

This can reduce bespoke state-transition code in some systems, but there is no defensible universal “60–70%” reduction. A context-driven design trades framework complexity for more tokens, latency, cache management, and dependence on model judgment. Teams should measure that trade against their own failure modes.

TDD—test-driven development—fits this design well. Ask the agent to turn a requirement into a failing test, implement the smallest change, rerun the test, then run the broader regression suite. Still review the test itself: a model can write a weak assertion that makes incorrect code appear green.

Hard limits that stronger long-horizon reasoning does not remove

Four limits remain:

1. Finite context. Large repositories and multi-week projects still require retrieval, summaries, and durable external memory.
2. Missing tests. If success cannot be measured, the loop can converge on a plausible but wrong patch.
3. Ambiguous requirements. An agent can perfectly optimize the wrong page, metric, or user journey.
4. Security and law. Reverse engineering, credential use, production writes, and vulnerability disclosure require explicit authorization.

Conclusion

Fable 5.1 changes the probability that a model can stay useful while an investigation gets long and messy. It does not change ownership of the engineering system around it.

The safest design is a division of labor: the model interprets evidence and proposes the next move; the harness preserves the goal, executes tools, records results, enforces limits, and asks for approval at consequential boundaries. That is how a coding agent stops being a code-completion demo and becomes a reviewable engineering process.

FAQ

Does Fable 5.1 eliminate agent memory loss?

No. Anthropic’s results suggest better long-horizon performance, but context is finite and early instructions can still be diluted. Preserve goals and acceptance criteria in durable external state.

Is the repository-to-test loop built into the model?

Anthropic has not published that as a model-internal mechanism. Treat it as an agent-harness design that combines the model with repository, shell, test, state, and permission tools.

Should I start a new conversation when the agent repeats a failed fix?

First preserve the current diff, failed hypothesis, and test result. A new conversation can help reduce irrelevant context only if you load that record; an empty restart can repeat the same mistake.

Does TASK_STATE.md load automatically?

No. It is an example filename. Configure your harness to read it or explicitly ask the agent to open it at each restart. Protect the agreed goal from unreviewed edits.

Can the benchmark results justify unattended deployment?

No. They measure benchmark task success, not your repository’s security, test quality, compliance rules, or deployment risk.