Why does my AI coding agent keep repeating work?

An AI coding agent usually repeats work for one of four reasons: nothing it reads records that the work was done, nothing records that an idea was declined, the same work exists as two tasks, or the context that held the answer was lost mid-session. The agent is not being careless; it is acting sensibly on an incomplete picture of the project. Each new session starts from the files, instructions and prompt in front of it, and if the finished state is not visible there, redoing the work is a reasonable guess. The fix depends on which cause you have, and the causes are quick to tell apart if you check in the right order: first whether the earlier work actually exists in the code, then where the record of it lives, then whether two tasks describe the same thing. This page walks through that order, with the fix for each cause and the habits that stop it coming back. The wider idea behind it is durable project memory.

Check first: is the earlier work really there?

Before blaming memory, confirm the earlier work landed. Open the version history and search for it: git log on the affected path or with a keyword from the task, or a search for the function or test the earlier session was supposed to add. Three outcomes are common.

The work is on the main branch. Then the agent repeated it because nothing told it so, and the cause is a missing record. Go to the next section.

The work exists, but only on a branch, in a stash or in an uncommitted working tree from another terminal. The agent is looking at code where the change genuinely does not exist, so from its point of view it is not repeating anything. Merge, rebase or discard the old branch, and make committed and merged part of what finished means.

The work is not there at all. The earlier session may have ended before it wrote anything, or its edits were reverted. Treat the old task as unfinished, not done, and record what happened so the next session starts from the truth. A confident summary of changes that never landed is its own problem, covered in how to know whether an agent actually finished.

Missing records: done work and declined work

If the work exists, the usual cause is that the record of it lives somewhere the agent never reads: a chat thread, your own memory, a closed terminal. The fix is a short, durable note per task that a new session reads before starting. It needs four things: what the task was, what changed (files and commit), how it was checked, and its status.

Declined work needs the same treatment and is the part most often skipped. Suppose you rejected switching the date library last week because the new one broke time zone parsing. If that decision lives only in a chat, a fresh session that notices the old library will propose the switch again, often with the same arguments. Record declined ideas as closed items with a reason: 'Won't do: replace the date library. Reason: broke time zone parsing in reports. Revisit only if reports stop using local time.' Now the agent can find the reason instead of rediscovering the idea.

Keep these notes next to the work they describe rather than in one ever-growing file. The pattern is covered in more depth in per-task Markdown memory.

Duplicate tasks and lost context

Two other causes look the same from outside. Duplicate tasks happen when the same work is written down twice: 'add CSV export' in one list and 'let users download reports as CSV' in another, or a follow-up created mid-session that restates an existing task. Each agent dutifully completes its own copy. To find them, search your task list for the files or feature the repeated work touched, not just the title words, since duplicates rarely share wording. Merge them into one item and close the other with a pointer to the survivor.

Lost context is the in-session version. In a long session, earlier turns get summarized or fall out of the window, and the line saying step 3 is done can go with them. The giveaway is timing: the repeat happens late in a long session, often right after the tool compacted the conversation. The fix is to end the session at a natural boundary and start a new one from a written handoff instead of pushing on. Summarized context loss and session handoffs cover both halves of that.

Preventing a repeat

Once you have fixed the instance, three habits keep it from returning.

Start each session with a read. The first instruction is to read the task's note, its status and any linked decisions, and to say what is already done before proposing anything. If the agent's summary misses finished work, you find out in a minute instead of after an hour of duplicate edits.

Close tasks with evidence, not just a status change. Done with a commit reference and the check that passed is something a later session can trust. Done on its own invites a second look, and a second look by an agent often turns into a second implementation.

Search before creating. Before adding a task, search existing items for the same files and behavior. Text search catches most duplicates; the rest surface when two tasks name the same file. Periodic cleanup of the list helps too, and backlog hygiene covers that routine. The aim is not a perfect record, just one that makes the finished and declined state of the project visible to whatever reads it next.

QUESTIONS

Why does my agent keep suggesting an idea I already rejected?

Because the rejection was never written anywhere it reads. A new session sees the code and the instructions, not last week's conversation, so the idea looks fresh. Record declined ideas as closed tasks with the reason and any condition for revisiting, and keep them where the agent's start-of-session read will find them.

Should I tell the agent what is already done at the start of every session?

Yes, but it is better to have it read that from a record than from your typing. Point it at the task note and ask it to summarize what is finished before it proposes anything. Its summary doubles as a quick test: if it misses finished work, you correct the record before any edits happen.

How do I find duplicate tasks in a large backlog?

Search by the files and behavior a task touches, not only by its title, since duplicates are usually worded differently. Filter by component, then read items that name the same files. Merge each pair into one task and close the other with a pointer, so neither a person nor an agent picks up the stale copy later.

RELATED GUIDES

• How to find and organize work across projects

RELATED HARNESS PAGES

• AI agent project memory AI agent project memory explained: why durable project records beat chat history, and how BRAIN FLUID keeps context with the work.
• How to hand off an AI coding session How to hand off an AI coding session: a short end-of-session routine so the next agent or person can continue without guessing.
• Per-task Markdown memory Per-task Markdown memory: one short record per unit of work, with outcome, scope, criteria, findings and next step, instead of one global notes file.
• Keeping an AI project backlog clean Keeping an AI project backlog clean: decline or hold work instead of deleting it, merge duplicates, avoid ID collisions and groom on a schedule.