Why am I explaining my project to AI again

Imagine you’ve spent an afternoon working with an AI on a CSV export. You explained the data, ruled out a database change, and settled on how to handle duplicate customer names. The code is halfway there.

You come back in a fresh chat and say, “Continue the export.”

It suggests joining records by customer name. You already rejected that. Then it asks whether it can change the schema. You already answered that too. Before you can do any new work, you’re explaining the project again.

A short restart note can make that return much less painful. The agent should maintain enough project state to recover the goal, understand the decisions, and find the unfinished work. A plain text file is enough to start. You shouldn’t have to rebuild the context by hand every time. You may not know which details it can see, so the agent should make important gaps clear.

What needs to survive

First, a qualification. A new chat isn’t necessarily empty. What carries over depends on the product and its settings. Some tools can draw on past conversations or saved memory; ChatGPT’s memory documentation, for example, also says it doesn’t retain every detail. The agent needs to work with what its tools can actually retrieve.

Even when the files survive, the reasoning behind them may be harder to recover. Code can show that an export uses account IDs. It may not explain that customer names were rejected because they aren’t unique, or that historical imports still need checking.

Those details affect what should happen next. Without them, a reasonable-looking suggestion can reopen a settled decision or quietly skip unfinished work.

The useful record answers a few questions. What are we trying to achieve? What have we decided, and why? What can change? What evidence do we have? What’s still unresolved? The agent should recover these answers from the conversation and accessible project material, then save them for later.

A restart note you can actually use

For the imaginary export project, the agent’s note could look like this. The paths below are examples; a real record should point to files and results that actually exist.

Goal: Add a CSV export with one row per customer account. Done means it works for current records and the historical import sample.

Decision and reason: Join on account ID. Customer names aren’t unique. Historical imports have not yet been checked for account IDs.

Limits: Changes to export code and tests are allowed. No database migration or production deployment.

Current state and evidence: Basic export implemented in src/export.py. Current-record tests passed; output saved in notes/export-test-results.txt. Work is on branch csv-export. Updated: [date and time].

Unfinished: Check the historical sample in fixtures/legacy-accounts.csv, then handle any missing IDs. Historical export behavior is still unverified.

Next action: Inspect the current branch, changed files, and saved test output. If the note still matches the project, check the historical sample.

That’s enough to give the next session a useful starting point. It can see both the choice and the reason for it. It can also see that “basic export implemented” doesn’t mean the whole task is finished.

The agent should keep the record in a stable location and look for it when you return, using the task or project to find the right one. It should inspect accessible files before asking you to supply them. If two unfinished tasks plausibly match, it can ask which you mean. In a plain chat without file access, pasting the note is a useful fallback.

Keep the note current

The agent should update the note when a decision changes, a result is checked, or a blocker appears. It should also save the current state before ending a session, while the context is still available.

Before saving, it should check the summary against the evidence. A note that confidently says “export complete” when only the current-record tests passed will make the next session worse. Missing reasons, unresolved questions, and the difference between a planned action and something that actually ran all matter.

The record can stay short, with links to longer reports or test output. When a decision changes, the agent should update it and explain why, so the next session doesn’t inherit two conflicting versions.

Resume by checking the project

The note describes the project at the time it was written. Someone may have changed a file since then. A test may have finished. The next action may already be done.

The assistant should start by comparing the note with the current project. In this example, that means inspecting the branch, relevant changes, and saved results before touching the historical export. If they disagree, it should investigate first. A question for you becomes necessary when missing information or a consequential ambiguity can’t be resolved from what it can access.

This is also why saving only “next: check old accounts” isn’t enough. Once that check is done, the assistant still needs the original goal to decide what follows. Passing one check doesn’t establish that the export works for both sets of records.

The public coordinator skill and its task-state reference describe a more structured implementation: keep a current task record, recover the goal and decisions on resume, and check whether saved state has gone stale before following the next action.

For a small project, ask the agent to maintain that plain text record and use it when resuming. You should be able to say “continue the export” and have it look for what it needs. When it really can’t find an answer, it should ask a focused question instead of making you explain the whole project again.

Next: Now the agent can pick up where it left off. But when it says “done,” what evidence should you expect? We’ll look at checking an agent’s work without doing the whole job again.