AI Handover Protocol: What to Pass to the Next Assistant
Use a repeatable handover protocol to pass goals, decisions, evidence, unfinished work and acceptance checks between AI assistants.
Updated 5 min read
An AI handover protocol is a repeatable agreement for what one assistant saves and what the next assistant checks before continuing. Pass the goal, current decisions, evidence, unfinished work, permissions and acceptance checks, then have the receiver confirm the next action. This is a practical work procedure you can adopt, rather than the name of a universal technical standard.
A shared record such as fenbs gives that procedure a home outside a single chat. The useful result is a verified starting point for the next session, whether you change models, switch apps or return after a break. You should not have to reconstruct the project from a long transcript.
What makes this a protocol rather than a summary?
A summary describes what happened. A protocol adds required fields, review rules and a clear acceptance step. It tells the outgoing assistant what to preserve, the incoming assistant what to verify and the person responsible when the records disagree. You can begin with a plain text template and a short checklist.
Use four stages: prepare, verify, transfer and accept. Prepare the record while evidence is still available. Verify it against the work, transfer it through an appropriate shared location, and accept it only after the next session has checked its starting conditions. Each stage should leave a clear result.
This approach applies to ongoing work rather than facts about your personality. The AI brain introduction explains why keeping useful project knowledge outside a conversation makes later sessions easier to start.
Which fields should every handover include?
| Field | What to write | What to avoid |
|---|---|---|
| Goal and scope | The outcome and the part of it this session handled. | A broad project name without a defined result. |
| Current state | Completed work, unfinished work and active processes. | Calling a draft or unchecked change finished. |
| Decisions and boundaries | What a person chose, what remains open and permitted next actions. | Treating a suggestion as approval. |
| Evidence | Exact source or output references, version and checks performed. | An unsupported statement that everything passed. |
| Next action | The first concrete step and what would block it. | A vague instruction to continue. |
| Acceptance | How the next session will confirm a correct result. | A completion test based only on confidence. |
Include an author and a saved-at date when records may be updated by different people. Identify the project and task so the note cannot be mistaken for a related job. If a record replaces an earlier checkpoint, make the current version easy to recognize without silently erasing the reason for past decisions.
W3C’s provenance overview (opens in a new tab) describes keeping information about the people, activities and things involved in producing an output. For an everyday handover, apply that idea simply: say which output you mean, who reviewed it and what evidence supports its status. You do not need to implement W3C’s data formats to use that habit.
What template can you reuse across assistants?
Copy this structure into your project record. Keep each answer short enough to check, and use “unknown” when the session cannot establish a fact. Preserve links to large documents instead of pasting their entire contents. The next assistant needs the current meaning of the work, not a second archive of everything said.
Project and task: Saved by / saved at: Goal and acceptance checks: Scope of this session: Completed and verified: - Work performed: - Evidence and exact output reference: - Checks run and results: Still open: - Unfinished work: - Checks not run: - Uncertainty or conflicting evidence: - Running processes or pending outside actions: Decisions and authority: - Current human decisions and their sources: - Questions waiting on a person: - Actions allowed next: - Actions that require approval: Restart: - First action and its prerequisite: - Sources to open before acting: - How to verify the result: Receiver acknowledgment: - Confirm the current record and sources. - State any mismatch. - Restate the first permitted action before doing it.
For a fictional design review, “presentation finished” might become “slide text reviewed; exported PDF has not been checked on a phone.” The remaining action is now visible. If the client has not approved the revised claim, name that open decision rather than asking the next assistant to infer consent from positive comments.
When the recipient is a person taking over a project, adapt the delivery using our AI handover notes guide. The protocol here governs the exchange between assistants and the checks surrounding it.
How do you verify a handover before passing it on?
- Compare the completion claims with the actual output. Open the cited file or document rather than relying on its name.
- Check that every stated test or review actually happened. Record failures and partial results alongside successes.
- Confirm the current human decisions. Remove any wording that turns an assistant’s recommendation into a person’s approval.
- Check the references and access. The receiver must be able to open the right version through the intended account.
- Read the next action as an instruction. Add missing prerequisites and make any approval boundary explicit.
NIST’s AI Risk Management Framework core (opens in a new tab) discusses documentation and clearly defined human responsibilities as part of managing AI risks. That supports keeping review ownership visible. It does not certify this template or turn a saved handover into proof that an output is correct.
If you cannot verify a claim, downgrade its status. “Reported complete by the previous session; not independently checked” tells the truth and gives the next assistant a useful first task. Removing uncertainty from the prose does not remove it from the work.
What must the receiving assistant do first?
Ask it to read the current rules and handover, open the essential evidence and restate the next permitted action. Its acknowledgment should identify blockers before it starts producing new work. If the saved record conflicts with a newer source, resolve that conflict through the person responsible for the project.
Do not assume two assistants share a private conversation, an account or access to the same files. Test the actual route the recipient will use. For a team, confirm that the record is shared with the intended members and that the assistant connection has appropriate access.
This matters when moving between the work tools discussed in AI employees: changing the assistant should not change who is allowed to approve the work. The fenbs handoff workflow keeps the saved restart record available to supported connected apps.
Make the handover the next session’s starting point
Save each task’s verified progress and put the next action in Where we left off in fenbs. Keep human choices in Decisions and rules and source pointers with the work, so the receiving assistant can check the record before continuing.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
How to do this with fenbs
- Create a free account. One person can start free, with no credit card.
- Add your project and active tasks to a kanban board. Put the work plan and acceptance checks with each task.
- Record the decisions people have made and save the relevant evidence references. Keep unanswered questions open.
- Connect a supported assistant using Integrations. Ask it to read the project context, including Rules and Where we left off, before working.
- Before ending the session, review the handover and ask the assistant to save task progress and the project’s restart point. Have the next session acknowledge it before acting.
fenbs does not read your chat history or automatically verify a handover. It is not the right fit if you only need to send someone one finished document. Use it when decisions, tasks and restart notes need to stay current across sessions.
How should the protocol handle stale or conflicting records?
Keep one recognizable current checkpoint and preserve the evidence behind changes. When a decision is replaced, record the replacement rather than editing history until the earlier choice disappears. The receiving assistant should name a conflict and its sources, then wait for the appropriate person if the conflict changes what it may do.
Review the procedure after a real transfer. Add a field only when a missing fact caused a practical problem. The AI handoffs library offers related examples; a compact protocol that people maintain is more useful than an elaborate form that nobody updates.