Why Your Agent Forgets Step 5 by Step 12

You hand an agent a ten-task plan. By task four it has drifted. By task seven it is implementing something that no longer matches task one. By task ten the original plan is a memory and the code is a surprise.

The model is not forgetful. The plan is too coarse. Tasks that look discrete to you blur together inside the agent's execution context. The fix is not a better model. The fix is smaller tasks with sharper edges.

Why big tasks drift

A "task" that says "implement user authentication" is not a task. It is a feature. Inside it are subtasks: choose a library, install it, write the model, write the migration, write the route, write the test, wire the UI. Each subtask has its own decisions.

When the agent executes "implement user authentication" as one unit, it makes all those decisions in flight. It picks a library, starts writing, hits a snag, improvises, moves on. By the time it reports done, the decisions are buried in code. Reviewing them means reading the whole diff.

The drift comes from this. The agent's in-flight decisions compound. Each one constrains the next. By task seven, the agent is working inside constraints it created by accident three tasks ago.

The bite-sized rule

A task is one action that takes two to five minutes.

Writing a failing test is one action. Watching it fail is one action. Writing the minimal code to pass is one action. Watching the test pass is one action. Committing is one action.

That is five tasks for what a junior would call "write the login function". The granularity is not micromanagement. It is reliability. Small tasks produce small failures, and small failures are easy to localize.

When task 12 breaks the build, you know the break is in task 12. You do not have to read tasks 8 through 14 to find it.

What every task contains

Three things, every time.

Exact file paths. Never "the relevant file". Always apps/web/src/auth/login.ts.

Complete code. Never "implement similar to above". Always the actual code, ready to paste.

Verification commands with expected output. Never "run the tests". Always pnpm test apps/web/src/auth/login.test.ts with the expected pass count.

If a task is missing any of these, the agent will guess. Guessing is where drift starts.

The no-placeholder rule

Placeholders are plan failures. They look like progress and produce nothing.

Banned phrases in a plan: "TBD". "TODO". "Implement later". "Fill in details". "Add appropriate error handling". "Write tests for the above" (without actual test code). "Similar to Task N".

Every task must contain the actual content. If you do not yet know the content, the plan is not ready. Write the content first.

This sounds slow. In practice it is faster, because the alternative is the agent improvising and you reviewing improvisations.

File structure first, tasks second

Before any task is written, the plan maps the file structure.

Which files will be created. Which files will be modified. What each file is responsible for. Files that change together live together. Each file has one clear responsibility.

This decomposition decides the task breakdown. Each task produces self-contained changes against a known file. The agent is never deciding "where does this go". The plan already told it.

Without this step, the agent invents the structure as it goes. The result is files named by mood (utils.ts, helpers.ts, services.ts) and code scattered across them.

Self-review before handoff

After the plan is complete, the agent reviews it with fresh eyes.

Spec coverage. For every requirement, can you point to a task that implements it? If not, the plan is incomplete.

Placeholder scan. Search for the banned phrases. If any appear, replace them with real content.

Type consistency. A function called clearLayers in task 3 but clearFullLayers in task 7 is a bug. Find these before execution starts.

This self-review catches problems while they are cheap to fix. During execution, the same problems cost an hour each.

Why agents cannot write these plans alone

An agent writing its own plan will reach for abstractions. It will write "implement authentication" because that is the natural language shape of the work. It will leave placeholders because filling them requires decisions it has not been told to make.

The plan has to come from a layer above the implementer. Either you write it, or a planning skill writes it under discipline that forbids placeholders and abstraction.

The implementer then executes the plan as written. No improvisation. No "I'll figure it out as I go". The discipline is in the plan. The execution is mechanical.

The smallest test

Take the next plan you are about to hand an agent. Count the tasks. If a task takes more than five minutes, split it. If a task says "implement", split it. If a task has any banned phrase, replace the phrase with actual code.

Then run the agent. The output will be closer to what you wanted, and the failures will be easier to find.