Staying on Target

Long sessions drift. Two defenses, mirror images of each other: push the goal forward, keep the failures behind.

Why this, for you: past ~50 tool calls, agents reliably wander off the objective — usually by quietly not finishing. These two techniques are how a multi-hour Claude Code session still lands the original task. Pure daily-coding payoff (#1), and a harness pattern (#2).

Earlier instructions sink into the low-attention middle (Lesson 02), and error cleanup throws away signal. Both cause drift. The fixes pull in opposite directions across the timeline.

1 Recite the goal forward

Maintain a running todo.md and rewrite it after every step — check off what's done, restate what remains. Each rewrite pushes the objective into the high-attention recency tail, right where the model is about to generate.

Weak recitation is a bare task list. Strong goal elicitation — restating the core objective in imperative language — measurably cut drift across every model tested.

Remember: refactor UserService for dependency injection WITHOUT changing any public method signatures. - [x] Map current call sites - [ ] Implement constructor injection - [ ] Update the DI container # rewritten every step; preserved verbatim through any /compact

It's the agent-initiated, continuous cousin of Critical Instruction Repetition (author-placed, static). One you write into the harness; the other you write into the prompt.

2 Preserve the failures behind

The instinct to clean up after an error — delete the stack trace, clear the failed call — is usually wrong. A failed action plus its error is a negative example: the model sees the dead end and updates away from it.

Removing traces cost 30%

Cursor measured a 30% performance drop from stripping reasoning traces — lost subgoals, repeated re-derivation, doom loops. The permission-error you delete is the one the agent retries next turn.

# keep this in context — it's the guardrail write_file("/etc/config.yaml") → PermissionError [Errno 13] # next turn the agent reroutes instead of retrying: write_file("/tmp/config.yaml") → ok

Preserve novel failures and active recovery; compact once recovery succeeds, or when the same error repeats 3+ times (a doom loop — break it, change strategy). And anchor "is it fixed?" to deterministic signals — tests, linters, types — not the model's own say-so.

The token-preservation trap

Telling a model to "preserve tokens, don't be wasteful" backfired: it refused ambitious tasks ("I'm not supposed to waste tokens… not worth continuing!"). It reads "be efficient" as "avoid anything that might fail" — the opposite of recovery behavior. Don't moralize tokens at the agent.

↪ Your win: future at the tail, failures in the log

Keep a todo.md, rewrite it each step, lead with the imperative objective.
Preserve it verbatim through compaction — post-compaction goal loss is unrecoverable.
Leave failures in context while recovering — they're negative examples, not clutter.
Compact errors only after success, or break the loop at 3+ repeats.
Don't tell the agent to save tokens; anchor recovery to tests/linters, not self-judgment.

Retrieval practice — recall, don't peek

Question 1Rewriting the todo each step pushes the objective into…

Question 2When an approach fails, you should usually…

Question 3Telling an agent "don't waste tokens" tends to make it…

Question 4The same error repeated 3+ times signals…

Question 5 · spaced recall from Lesson 11On-demand retrieval's hidden failure mode is…

Ask me anything. Want the post-step recitation snippet for a harness, or how this pairs with the five-stage compaction schedule (errors kept full during recovery, summarised after)? Next in Part 2: Breaking the Stack — sub-agent context isolation.