Direct answer
Two weeks away, and the AI remembers nothing. Rebuild the state once, then never rebuild it again.
You stepped away from a client project for two weeks, a holiday, another job, life, and came back to an AI that has forgotten everything that mattered: the decisions you and the client settled, the figures you agreed to use, the draft that was approved and the one that was killed. The chat may still exist, but rereading it means re-deriving every decision from conversation, and half the decisions were never in the chat at all. Starting over is not just slow; it is risky, because a re-made decision often comes out different from the original and nobody notices until the client does. Here is how to pick this project back up honestly: what to salvage, how to write the short state note that re-briefs the AI in minutes, which decisions need the client's confirmation before you build on them again, and the wrap-up habit at every pause that turns the next return into a free pickup instead of an excavation.
Updated November 6, 2026. First published November 6, 2026. The two delivery records quoted below are real and public, with their client decision states read back from the live service on November 6, 2026.
Step 1. Accept what the AI has actually lost, and what it has not
An AI session forgets in a specific pattern, and knowing the pattern saves you from both panic and false confidence. What is gone is the working state: the thread of reasoning, the tentative choices, the sense of which option you were leaning toward and why. What may survive, depending on your tools, is material: files you saved, messages you sent, the client's replies, your own notes. What never survives anywhere unless you recorded it is the decision layer: what was settled, by whom, and what was deliberately left open. So the rebuild has a clear target. Do not try to restore the conversation; restore the decision layer. A project resumes from its decisions, its current outputs, and its open items. Everything else is atmosphere, and atmosphere is exactly what tempts people into re-arguing settled questions because the reasoning felt familiar. List the three things you need, decisions, current outputs, open items, and rebuild only those.
Step 2. Salvage the decision layer from what survives
Work the surviving material once, in a fixed order, and extract decisions rather than content. Start with the client's own messages: approvals, corrections, and choices in the client's words outrank everything else, because they settle questions rather than raise them. Then your sent messages and delivered drafts, which show what the client was actually working from. Then saved files, in date order, marking which version was last sent rather than last edited, since those are often different files. Then your notes, treated as claims to be checked against the first three sources rather than as fact. For each decision you recover, write it in one line with its source: decided what, decided by whom, and where that is evidenced. Decisions you cannot evidence go on a separate short list, believed but unconfirmed, and step 4 deals with those before you build on them. This pass takes an hour or two on a mid size project. It is also the last time you should ever have to do it, if step 5 lands.
Step 3. Read the two states a paused project can sit in
The salvage above rebuilds a state that was never recorded as one. The stronger shape is a project that was wrapped when it paused, so its state was saved as a record rather than scattered across a chat. The record format is AER-1, published as an IETF Internet-Draft (draft-zambo-aer1-26), and each step carries a verifiable receipt: a receipt proves the saved result was not changed since it was saved. The two public records below show the decision states a wrapped job carries with it:
Accepted: the decision is on the record
- Status: accepted, decided_by client, decided_at 2026-10-16T14:31:51.146Z, release_hint ok_to_release.
- Steps: 4 steps total, 4 checked.
- aer1_version: draft-zambo-aer1-26.
- Open the handover or read its acceptance.json.
Pending: checked, and still waiting on a decision
- Status: pending, release_hint hold.
- Steps: 5 steps total, 5 checked.
- aer1_version: draft-zambo-aer1-26.
- Open the handover or read its acceptance.json.
The accepted record, 4 steps, 4 checked, decided_by client at 2026-10-16T14:31:51.146Z, release_hint ok_to_release, is a project you can resume cold: the steps are saved, the checking is done, and the client's decision is on the record with its date, so nothing needs to be re-asked. The pending record, 5 steps, 5 checked, release_hint hold, is a project paused mid decision: the work is intact and checkable, and the record itself tells you the one thing to do first on return, get that decision. Compare either with the state you came back to: no steps saved as a record, no decision state visible, the whole position held in a chat's memory and yours. The gap between those states is not effort; the wrap takes minutes at the pause. It is purely whether the pause was closed as a record or just abandoned to the calendar.
Step 4. Confirm the unconfirmed decisions with the client, in one short message
Before you build again, send the client one short state message, and keep it boring. It lists the decisions you are treating as settled, each in one line, and asks them to flag anything that does not match their understanding. It lists the believed but unconfirmed items separately and asks for a decision on each, or confirmation that your recollection is right. And it names the next step you will take once they reply. This message does three kinds of work at once. It converts your reconstruction into an agreed state, so a decision re-made differently is caught now, by the client, rather than at delivery. It reopens the project warmly, showing a supplier who returns organised. And it creates, in their reply, the first dated decision record of the resumed project. Clients almost never resent this message; what they resent is discovering in the final draft that a settled point was quietly settled the other way.
Step 5. Re-brief the AI from a state note, not from the whole history
With the state agreed, bring the AI back in through a short state note rather than by pasting the old chat and hoping. The note fits on a page: the goal in two sentences, the decisions as a list with decider and date, the current outputs and which version is the live one, the open items in order, and the limits, what not to reopen, what was not checked, what the client ruled out. Feed the note at the start of the new session and have the AI work from it, saving its new steps as it goes. A state note beats a history dump for a practical reason: the AI treats a long chat as material to summarise, and its summary will quietly promote tentative ideas into decisions and drop the one correction that mattered. A note written by you, confirmed by the client, has the authority structure already sorted. Keep the note with the project; it becomes the seed of the wrap in step 6.
Step 6. Wrap every pause from now on, so returning is a pickup
The permanent fix is a closing habit applied at every pause, not just long ones, because two weeks away is rarely announced two weeks ahead. When work on a project stops for the day, the week, or the job, wrap it: the steps saved in order, the decisions recorded with decider and date, the open items written as next steps, and the whole job sealed as one record under one link. Returning then means picking that record up, in the same AI or a different one, and continuing the same job, with the new steps landing on the same record. The state note of step 5 stops being a rescue document and becomes a byproduct the wrap already contains. Build the habit at the smallest scale first: wrap at the end of each working day on a live project, a few minutes while the state is fresh, and the two week problem cannot recur, because the state was never left inside a chat to be forgotten.
What a record does not settle
A verifiable receipt proves the saved result was not changed since it was saved; it does not recover decisions that were never recorded anywhere, or bind a client to a decision they never made. The salvage order, the client's confirmation of the unconfirmed list, and a wrapped record at every pause from now on are what this answer stands on. This page is general information, not legal advice.
Frequently asked questions
I came back to a client project after two weeks away and my AI has forgotten everything we already decided. How do I pick the work back up without starting over?
Rebuild the decision layer, not the conversation. Salvage in a fixed order: the client's own messages first, then your sent messages and delivered drafts, then saved files in date order marking the version last sent, then your notes checked against the other three. Write each recovered decision in one line with its decider and its evidence, and put decisions you cannot evidence on a separate unconfirmed list. Send the client one short state message listing the settled decisions and asking them to flag mismatches and decide the unconfirmed items, then re-brief the AI from a one page state note, goal, decisions, live outputs, open items, limits, instead of pasting the old chat. From that point, wrap the job at every pause so the next return is a pickup of a saved record, not another rebuild.
Can I just paste the old chat back in and ask the AI to summarise where we got to?
You can, and it is better than nothing for a small informal job, but know the failure mode before you rely on it. A summary of a chat is a new piece of writing by the AI, not a recovery of the record: tentative ideas get promoted into decisions, a correction made late in the thread can be summarised as if it were the opening position, and decisions that happened outside the chat, on a call, in an email, in the client's head office, are absent entirely and invisibly. If you use a summary, treat it as a draft to be audited against the sources in the salvage order in this page, never as the state itself, and always run the unconfirmed list past the client before building on it. The hour that audit takes is the difference between resuming the project and quietly starting a slightly different one.
What if the client and I remember a decision differently?
Then the evidence order decides, and where no evidence exists, the decision gets re-made openly rather than won by memory. Client messages outrank your messages, which outrank file dates, which outrank notes and recollection, because the client is the decider on their own project and their words are the closest thing to the decision itself. If the trail genuinely does not settle it, say so in the state message: this point is remembered differently on each side, here are the two versions, please confirm which stands. Clients respect that framing; it shows you are protecting the project's accuracy, not your pride. What you must not do is silently build on your version and present the result as agreed. A re-made decision, recorded now with a date, is a small cost. A contested decision discovered at delivery is a dispute.
How long should the state note be, and what goes in it?
One page is the working target; if it runs to three, the project needs its record wrapped rather than its note lengthened. Five sections, in this order. The goal, in the client's terms, in two sentences. The decisions, one line each, with decider and date and a mark where a decision is still unconfirmed. The current outputs, naming the live version of each deliverable and where it sits. The open items, in the order they should be worked, with the blocker named where one exists. And the limits: what was ruled out, what was not checked, and any constraint the client set that a fresh AI would not guess. Write it for a competent stranger, because that is what a fresh AI session is. If a stranger could start work from the note without asking you anything settled, the note is done.
How do I make sure a break never costs me the project's state again?
Wrap the job at every pause, so its state lives in a record instead of in a chat. When the work runs through Zambo, wrapping a job seals its steps, each with a verifiable receipt under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, with the decisions and next steps written into the handover, and picking that work up in another AI is always free, whether the pause was a night or a month. New users get 20 calls and 1 wrap-up free every day, and picking up work in another AI is always free. For $0.99, wrap the next project at its first pause and come back to a pickup instead of a rebuild: get the Day Pass. A Day Pass is unlimited for 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.
Related
- My client wants to take the project over with their own team and their own AI. How do I hand it over so they start from the finished record?
- I switched to a new AI tool and it knows none of my clients, my rates, or how I work. How do I carry my working setup over instead of re-teaching everything?
- I switched AIs in the middle of a job and lost the thread of the work. How do I keep it?
- My agent forgets everything when the session ends, how do I give it persistent memory?
- Start with your problem: every problem in this directory, routed to its page