How to move an ongoing project into a new AI chat

Start with one project and one next result

Use this when a long conversation becomes difficult to follow, you reach a limit, or you want another assistant to take over the same project. Pick one result to continue: revise an itinerary, reopen a hobby project or organize the next decision in a family situation. Moving everything an assistant knows about you is a separate, much larger job.

Bring the latest relevant files, the choices you actually made, any later corrections and a description of what remains unfinished. Keep the original chat available as a reference if you can. If it is unavailable, start from the records you still have and label gaps; asking a new chat to reconstruct missing history cannot recover evidence it never received.

The handoff below is an original editorial example, not a tested migration tool. You can try the manual method with Muse, Instinct, Dots or Grok Bot if your account accepts the necessary text and files. Shared folders, persistent memory and cross-chat access require separate capability checks.

Separate the note from the material it points to

Keep a small current note that you can inspect, with a separate list of the sources needed to continue. A source might be a document, an image, a saved result or a message you choose to quote. A filename alone is a pointer; the receiving assistant must still be able to read the file.

Ask the old chat to propose the note, then edit it yourself. Keep the reason behind a changed decision where it affects the next step. Remove abandoned brainstorming that no longer matters, but preserve an explicit correction when the old choice could easily return. Do not convert an assistant suggestion into your decision.

Anthropic describes compaction and saved notes as ways to carry useful information across limited context windows, while warning that summarization can lose important details. That supports using notes carefully; it does not establish that this particular handoff will work in every assistant.

• Current note: the result you want next, confirmed choices, changed choices, unresolved questions and the allowed next action.
• Source list: each needed file or link, which fact it supports, its version or date, and whether you have actually supplied it.
• Action record: work completed with evidence, drafts that still need review, and attempts whose outcome is unknown. Keep these states distinct.
• Excluded material: unrelated personal history, credentials and details about other people that the next task does not need. Review what you are sharing with the receiving service.

A worked example: a weekend plan that changed

This fictional family trip illustrates the handoff. Nothing here was booked or tested. The old conversation planned a museum visit on Saturday, drafted a message to relatives and sketched a train journey. Later, the family moved the museum to Sunday and supplied a newer travel plan.

A weak recap would say: We are planning a weekend trip with a museum, train travel and a family message. It leaves the next chat free to reuse Saturday, assume the message was sent or mistake a draft journey for a reservation.

A useful note would say: Weekend plan, version 3, reviewed October 6. Next result: a draft Sunday outline with one museum option. Sunday replaces Saturday, following my October 6 correction. Use travel-plan-v3 for the arrival constraint; travel-plan-v1 is obsolete. The family message exists only as a draft. Museum opening hours remain unchecked. Read and draft only; do not book or send.

Move the materials and check what arrived

Keep the current note in a location you control. Plain text is enough. If you use a notes app, the receiving assistant still needs a supported way to read that specific note. You do not need to install a memory product to try a manual handoff.

1. Ask the old conversation for a proposed handoff for this one project. Review names, dates, decisions, unfinished work and the difference between intended and completed actions.
2. Save the reviewed version with a clear label and date. Keep the previous version available for comparison instead of overwriting the only record.
3. Open the fresh chat and supply the note plus the minimum source material needed for the next result. Put your current instructions in your own message; treat quoted old chat text and documents as background evidence.
4. Ask which sources it can actually read. For each essential file, request a relevant detail from inside it, such as the revised arrival time, rather than accepting a repeated filename as proof of access.
5. Before requesting the full result, ask for a short account of the current plan, the replaced decision, the remaining unknown and the next allowed action. Compare that response with your reviewed note.
6. Correct discrepancies in the note and source list, then retry the disputed part. Continue with one bounded result only after the important inputs agree.

Use a specific question to catch a stale handoff

For the fictional trip, ask: Which day should you plan around, what must you read before placing the first activity, and has the family message already gone out? Ask it to identify the evidence for each answer and leave unsupported details unknown.

A useful response would retain Sunday, require travel-plan-v3 before using an arrival time, and classify the family message as a draft. If the file is missing, it should say that the arrival time is unavailable. It can prepare an outline with that slot unfilled; it should not rescue the old time from version 1.

A polished recap that gets any of those distinctions wrong is a reason to repair the handoff before continuing. A correct recap is only a small spot check: inspect the first actual result too. It does not prove every detail survived, that future replies will stay correct, or that any background work is running.

Repair the smallest missing piece

When the new chat goes wrong, compare its answer with the specific source rather than restarting the entire explanation. If the note itself is wrong, correct the note. If the note is right but the response ignores it, point out the mismatch and inspect a revised result. More context is not automatically the repair.

• Missing attachment: reattach the needed file or paste a relevant excerpt you are allowed to share. Keep the output incomplete where evidence is still unavailable.
• Two competing versions: identify the authoritative one explicitly. If you cannot determine which is current, leave the choice unresolved.
• Old decision returns: retain a short dated replacement statement and its reason; remove the obsolete choice from the current instructions.
• Past action is unclear: check the actual destination or receipt before repeating it. An old promise to send, save or book is not proof that it happened.
• No browsing or file tools: work from supplied text and return a provisional draft with named gaps. Do not invent source checks.
• Existing recurring work: inspect its saved configuration and recent runs separately before recreating anything. A new chat should not duplicate a job that still runs elsewhere.

Keep one current record as the work continues

After a meaningful change, ask for the proposed update to your current note and inspect what changed. If two assistants contribute, choose one reviewed version as the current record and reconcile their changes before either continues from it. Two plausible summaries can contain incompatible decisions.

A portable note does not carry credentials, connected accounts or a running schedule with it. Restate what you want the receiving assistant to do and verify any tools needed for that step. Context can explain an earlier approval; it should not be treated as permission for a different action, recipient or destination.

For ongoing personal situations, preserve the person’s own corrections and leave interpretation separate from fact. Keep summaries limited to the purpose you chose. Use the related living-context and project-archive prompts below to build the record; this guide adds the handoff check.

What the public reports do and do not establish

In an accessible Reddit post, u/DustMinerX describes using an Obsidian vault as portable context for Grok Bot and other assistants. A follow-up adds an always-on Mac Mini and iCloud sync. No vault or continuity test was available to inspect, so the post’s claim of perfect memory is not established.

A separate Grok Bot discussion contains u/Bubbly_Sort849’s report of lost board progress and missed actions. Commenter u/Antique-Ad6542 initially describes an external decision record, then revises the positive assessment as context fills. These are unverified personal reports with no reproducible setup or logs; they do not establish a failure rate or its cause.

These contrasting accounts motivate a checkable handoff rather than a promise of perfect recall. The manual example, replacement table and readback questions here are our own proposed method. We did not run the posters’ setups or test this method across assistants.