Your AI coding agent forgot the project: how to recover context

Ask what the agent can actually read

When an AI coding agent seems to forget your project, pause new implementation and inspect the context it has available. Recover the approved product goal, the current task, the latest verified result, and the next unfinished action. Save that recovery in a durable project record, then ask the agent to reconcile it with the repository before continuing.

A new session proposes the feature you rejected yesterday. Or it asks you to explain the customer again. It is tempting to paste the whole previous conversation and say “please remember this time.” That may help temporarily, but it also sends abandoned ideas, provisional answers, and outdated status into the new session. You need a current account of the product, not a larger pile of history.

Begin by asking what sources the agent read. It may be in the wrong project directory, unable to access the record, or following an outdated instruction file. It may have loaded the right documents but misunderstood a decision. Those situations require different corrections. A factual account of available context gives you something to investigate; “I remember the project” does not.

The workflow below is editorial guidance you can adapt. It does not assume all coding tools have identical memory behavior, and the example is hypothetical. The objective is to restore a reliable starting point for the next task, with unresolved questions visible rather than guessed away.

Before making changes, list the project instruction files and records you actually read. Summarize the approved product goal, current release scope, current task, latest verification evidence, and next unfinished action. For anything unavailable, say what you could not access. Do not fill missing context with assumptions.

Separate missing context from conflicting context

Missing context means the necessary information is unavailable. Conflicting context means two available sources disagree. Stale context means a source describes an earlier state. Treating all three as “the agent forgot” can lead you to add more documentation when the actual problem is that existing documents disagree.

Imagine a small invoicing product. An older brief says customers can pay immediately; a newer decision says the first release only creates and sends invoices. A new agent sees the payment screen in the code and assumes payments remain in scope. The code is evidence of what exists, but it does not establish your current release decision.

Ask for a short disagreement list. Each item should name the sources, describe the difference, and explain which task it affects. Review the high-impact disagreements first. You do not need to settle every historical note before the next session, but you do need a clear answer on the behavior the agent is about to change.

Do not instruct the agent to pick whichever source looks newest without checking what that source represents. A recent brainstorming note can be less authoritative than an older approved decision. Establish where current approvals live and how replaced decisions are marked. This is a project convention you control.

Compare the available project records with the current implementation. Identify missing information, conflicting decisions, and stale status separately. Link each disagreement to its sources and affected work. Propose a correction for review; do not silently select a new product direction.

Recover decisions with their reasons

A useful recovery note contains the decision, its reason, its approval status, and the work it affects. “No payment collection in the first release because we are testing invoice creation with existing customers” explains more than “payments later.” The reason lets a future agent judge whether a new suggestion belongs in the current task.

Read the previous session selectively. Look for decisions you actually accepted, the last task you approved, checks that were run, and unresolved blockers. A completion message is a claim to inspect, not automatic proof that every promised behavior exists. Ask the agent to connect the message to changes and verification evidence.

Keep tentative ideas in a separate list. If you discussed adding recurring invoices but never decided to build them, preserve the idea as pending. You avoid losing the thought while preventing it from becoming an accidental requirement. Mark questions that need your judgment instead of asking the agent to reconstruct your intention from tone.

Review the recovery note yourself before promoting it to the current brief. You may find that the agent extracted the wrong audience or treated a suggestion as an approval. Fix the summary at its source. Otherwise, every future session that reads the recovery note starts with the same mistake.

Use the tool’s native context mechanism

Claude Code provides CLAUDE.md instructions and auto memory. Its documentation distinguishes instructions you maintain from notes the tool accumulates, and explains that context is not enforced configuration. Review important saved statements rather than assuming an automatically saved note is a product approval.

Codex supports AGENTS.md project instructions, including guidance discovered from the project root toward the working directory and more specific overrides. If your new session behaves differently, inspect the instruction sources relevant to where it is running.

Cursor provides project rules in .cursor/rules and AGENTS.md instructions. Check which guidance applies to the work, and maintain one clear current version of consequential decisions instead of inconsistent copies across rules.

Gemini CLI uses GEMINI.md context files and offers memory-management commands. Check its documentation for the CLI you use; the consumer Gemini chat interface should not be assumed to share the same repository behavior.

These features are useful places to tell an agent how to consult your project record. Keep the instructions concise and put changing task status in a record you can maintain. The recommendations here concern project management; native behavior is described in the linked official documentation.

Create a restart note that is easy to verify

Use five short parts: the approved goal, the task in progress, the latest evidence, unresolved gaps, and the next action. Link supporting records rather than copying everything into the note. A restart note is useful when it helps an incoming agent find the facts and identify what still needs inspection.

For the invoicing example, the note could say: the release creates and sends invoices; PDF generation is implemented; a sample PDF was opened locally; email delivery has not been checked because a test inbox is unavailable; the next action is to verify delivery with an approved test account. That is enough to stop the next session from starting subscription billing.

Include the environment when describing verification. A result on a local machine does not automatically describe the deployed application. If unfinished changes exist, identify them and their owner. A new agent should not overwrite them while trying to produce a cleaner starting point.

Keep the note proportional to the project. A solo founder with one task may need a short document. Multiple agents need more visible ownership and history. The useful measure is whether the next session can find the right work, not whether the note looks comprehensive.

Draft a restart note with five parts: approved goal, current task, verified evidence with environment, unresolved gaps, and next action. Link to supporting records. Mark unfinished changes and ownership. Label any inference and leave unapproved ideas pending. Keep the note concise enough for founder review.

Verify the restart with one bounded task

Ask the agent to explain the next task before editing. In the example, it should propose checking invoice delivery, not rebuilding the dashboard or adding payments. If its plan still contradicts your decision, correct the context source and inspect again. A good restart becomes visible in the chosen work.

Agree on what successful recovery looks like. The agent can identify the current scope, distinguish a implemented result from a verified one, name the open blocker, and continue without reopening a settled decision. You can observe those behaviors without trying to measure an abstract memory score.

After the task, update the same project record. If delivery passed, record the environment and evidence. If it failed, preserve the failure and next diagnostic action. A restart process that ends with another unrecorded chat will eventually create the same recovery problem.

Avoid turning the restart into a general cleanup. Reorganizing every file and rewriting all instructions can make the work harder to reconcile. Correct the information needed for the current task, then schedule broader maintenance if it is warranted.

Using the reviewed restart note, propose the smallest next task and its acceptance criteria. Explain which approved decision it serves and what evidence will establish completion. Before editing, flag any disagreement with the actual project. Afterward, record the result and remaining gap in the same project record.

When RAAV can help with the recurring reset

If every session requires you to reconstruct product scope, task status, and previous verification, evaluate a shared project record. RAAV is persistent product and project memory for coding agents. It organizes context, proposals, decisions, tasks, ownership, and verification so the project can be reviewed across sessions.

Keep using native instructions to guide the tool. Use the project record to hold the changing state of the work. A record is only useful if approved decisions are accurate and results are updated. RAAV does not make the coding agent infallible or turn an untested claim into verified behavior.

For Gemini CLI, this guide explains native context management. It does not claim a verified dedicated RAAV setup path. If you are exploring a connection, treat access and workflow compatibility as things to verify before relying on them.

Start with the context you had to explain twice this week. Recover it, review it, and see whether the next task becomes easier to scope and close. That gives you a concrete basis for deciding whether a shared record is worth maintaining.

Continue the non-coding founder series

Start with who this approach is for, why the work needs product management, and why now. Then use the practical guide that matches the next problem in your project.