Factory AI Handoff: Save What the Next Session Needs

For a Factory AI handoff, save the goal, actual repository changes, checks performed, unresolved questions and the next action before ending the session. Then have the next assistant verify that record against the current files before it edits anything. A resumed conversation is useful background, but it is not proof that the workspace still matches the last summary.

A record in fenbs can hold the task state and restart notes outside Factory, while your repository holds the code. This also helps when the next session uses a different supported assistant. You do not need to move your whole conversation to preserve the facts that determine what happens next.

What should you capture before ending the session?

1. Ask Droid to stop taking new implementation steps and summarize the original task and its acceptance checks.
2. Inspect the changed files and separate this session’s edits from work that was already present.
3. Record each check that actually ran, its result and what remains untested. Keep evidence references with the result.
4. Identify active processes, unfinished actions and decisions waiting on a person. Name the next action and any condition that must be satisfied first.
5. Read the summary yourself, correct unsupported claims and save it somewhere the next person or assistant can access.

Do this while the workspace and test output are still available. A handoff written from memory after closing the terminal may miss a failed command or an unsaved file. If an assistant cannot inspect something, its summary should label that fact as unknown rather than fill the gap with a likely explanation.

For background on the tool itself, see our Factory Droid overview; the checklist here focuses on leaving one coding session ready for another.

Can you resume the old Factory session instead?

Factory’s CLI reference↗ (opens in a new tab) documents resuming a session with droid --resume and selecting a session by its ID. Use that when continuing the same conversation is helpful. Record the session reference with your handoff so someone can locate the discussion if they have access.

Before resuming work, check the repository and current task. Another teammate may have changed a file, completed a check or replaced a decision since the session stopped. Treat the saved discussion as a description of an earlier moment until its important claims have been checked against the present workspace.

Keep standing repository instructions separate from a temporary checkpoint. Factory’s AGENTS.md guide↗ (opens in a new tab) describes that file as durable project guidance. Put ongoing commands and boundaries there; keep “the parser check is still failing” with the active task so it does not become a permanent instruction.

How do you prove what changed?

Start with a read-only inspection. The Git status documentation↗ (opens in a new tab) explains how status reports staged, unstaged and untracked paths. Save the repository location in a form useful to your team, the branch or worktree identifier, and the paths relevant to this task. A local folder name alone may mean nothing on a teammate’s machine.

Review the patch as well as the file list. Git’s diff documentation↗ (opens in a new tab) distinguishes comparisons involving the working tree, staging area and commits. Say which comparison you inspected. Also inspect relevant untracked files separately: an ordinary tracked-file diff is not a complete inventory of new work.

• Changed behavior: explain what the user now experiences and where the change lives.
• Evidence: identify a relevant file, test output or reviewed patch without copying credentials or private data.
• Scope limits: say which observed changes belong to another task or were already there.
• Delivery state: distinguish local edits, a local commit and work that has actually been shared or released.

This is a useful boundary for AI at work: a confident summary should never substitute for inspecting the work it describes.

What does a useful coding checkpoint look like?

Here is a fictional example for a CSV import task. Replace the paths, results and authorization with facts from your own session. The point is to make the next action narrow enough that another assistant can begin without repeating the entire investigation.

Goal: Preserve leading zeros in imported customer codes.
Changed: src/import/parse-csv.ts and its parser test.
Checked: Targeted parser test passed in the current worktree.
Not checked: Full application build and a browser import.
Decision: Owner chose to preserve codes as text.
Open question: Should blank codes block the import?
Current state: Local edits only; no commit or deployment.
Next: Review the code diff, then run the agreed browser check.
Boundary: Do not change the database or publish the application.
Evidence: Parser test output and the two changed files.

Notice that a passed parser test does not become “the import is fixed.” The browser check remains open. A future assistant can investigate that specific gap instead of spending its first session trying to discover whether anything was tested at all.

A reusable handoff prompt can collect this information, but someone still needs to verify the resulting checkpoint.

How should the next assistant accept the handoff?

Ask it to restate the goal, applicable decisions, last verified result and first proposed action. Have it open the cited files and confirm that it is in the intended repository. If the evidence disagrees with the note, pause the dependent work and update the record before proceeding.

Check for commands still running, especially watchers or development servers. Save enough information to recognize the process without assuming a process identifier will remain valid on another machine. A note saying “server may still be running; verify before starting another” is more useful than a claim that closing a chat stopped every process.

The same restart discipline applies when moving to another editor assistant, such as the one described in what Cursor is. Keep the checkpoint readable without relying on a particular tool’s session format.

How to do this with fenbs

1. Create a free account. One person can start free, with no credit card.
2. Add the project and the coding task to your kanban board. Record its goal, current plan and remaining acceptance checks.
3. Copy the checked Factory handoff into the appropriate task and project progress records. Keep code and large logs in their existing locations and include useful source pointers.
4. If continuing through a supported app, follow its guide on Integrations, then ask the connected assistant to read the project context before acting.
5. Save progress again after the next session, including new evidence and anything still waiting on a person.

fenbs does not run your tests or verify a Factory session automatically. Use your repository and testing tools for that. It is not the right fit if all you need is to reopen one local session; its value is keeping shared work understandable across sessions and supported apps.

How can you tell whether the handoff is complete?

Give the note to someone who did not watch the session. They should be able to locate the change, distinguish checked work from assumptions and name the next action. If they need to ask “which file?” or “did that test actually run?”, add the missing evidence before calling the checkpoint ready.

Keep that review short and repeat it when the task changes. The AI handoffs library covers other transitions, but the essential test stays practical: can the next session continue from the verified state without guessing?