# A small packet the next agent can verify. Reviewed: 2026-10-18 Canonical: https://clankercloud.ai/templates/agent-handoff-pack Use this fictional handoff pack to test whether a fresh agent can read current Project files, preserve missing evidence, identify completed work, and perform one permitted revision. Upload the files to a Clanker Project, inspect the draft, then give the next authorized task the prompt. The packet is saved context, not synchronized private chat. ## What you are working toward An inspected revision and updated handoff that another task can continue without the original conversation. ## Start with - The fictional files below in one Project - A native Agent or compatible authorized client with the required file tools - A reviewer who keeps the authored checks separate from the initial agent input ## Download a handoff with a deliberately incomplete fact The fictional Harbor Museum is preparing an exhibit-readiness note. The approved brief gives a planned opening date, records a completed accessibility review, and leaves the installation owner unassigned. The current draft accidentally names an installation owner. The handoff asks the next agent to repair that claim and preserve the unknown. Upload brief.md, readiness-draft.md, source-register.csv, action-register.csv, and handoff.md as the initial packet. Keep reviewer-checks.csv with the reviewer until after the task. All names, dates, operations, and identifiers in this sample are fictional. They illustrate a working convention and must not be used as real tool identifiers. ## Ask the receiver to establish what is current The receiving agent should read handoff.md, then open the referenced files. It should identify brief.md as the approved source and readiness-draft.md as a draft needing correction. Reading only the handoff summary is insufficient because the mistake is in the actual deliverable. Ask it to explain the source conflict before changing anything: the draft’s named owner has no support in the brief. The supported facts are the planned opening and completed accessibility review. The correct response can improve the draft while leaving installation ownership unresolved. It should not invent an owner to make the note look complete. ## Use the action register to prevent unnecessary repetition The register says a draft was saved and no external delivery was started. This is sample status data, not an instruction to execute any operation. In a real handoff, use actual returned file, task, or job identifiers and mark whether their results were inspected. Do not store credentials in the register. If an operation is uncertain, the next task should inspect its original destination and identifier before retrying. In this packet, the next authorized action is a Project revision only. Sending the readiness note, changing a museum system, or starting recurring work would need a separate instruction. A handoff carries task context; it does not create extra authority. ## Save a new reviewed version and update the handoff Ask for readiness-reviewed.md with a source note, then update handoff.md to name that current output and preserve the open installation-owner question. Keeping the original draft makes the correction inspectable. Read back both the revised output and handoff before declaring the task finished. An external MCP client should use the current managed Session procedure for changes, retain its task and file identifiers, and complete the Session after inspection. A native Agent should use its available tools. Confirm capabilities in the actual account rather than assuming a client can save files because another route can. ## Check the packet as a reviewer Open reviewer-checks.csv after the run and record observed, revise, or not observed. Confirm that the unsupported name is removed, the owner remains unassigned, and the opening date remains explicitly planned. Check that the accessibility statement still matches the source. Inspect the actual saved file rather than a description of it in chat. Then start another task with only the Project and handoff location. It should find readiness-reviewed.md, explain the unresolved owner, and avoid external delivery. This fresh-task check tests continuity across saved context. It does not prove automatic conversation sync, universal client compatibility, or an accuracy or speed advantage. ## Sample files Fictional inputs. Download and add to your Project. - [brief.md](https://clankercloud.ai/templates/agent-handoff-pack-files/brief.md): Initial input: the approved fictional exhibit brief and one deliberately missing owner. - [readiness-draft.md](https://clankercloud.ai/templates/agent-handoff-pack-files/readiness-draft.md): Initial input: a fictional saved draft containing one unsupported owner. - [source-register.csv](https://clankercloud.ai/templates/agent-handoff-pack-files/source-register.csv): Initial input: source precedence and the current draft’s review status. - [action-register.csv](https://clankercloud.ai/templates/agent-handoff-pack-files/action-register.csv): Initial input: fictional operation status; sample labels are not live identifiers. - [handoff.md](https://clankercloud.ai/templates/agent-handoff-pack-files/handoff.md): Initial input: the bounded next task, current files, and unresolved question. - [reviewer-checks.csv](https://clankercloud.ai/templates/agent-handoff-pack-files/reviewer-checks.csv): Reviewer-only reference: open after the initial task, then record observed evidence. ## Try this prompt Copy into a Workspace Session. Opening Workspace does not send it automatically. ```text In this Clanker Project, use handoff.md, brief.md, source-register.csv, action-register.csv, and readiness-draft.md. Do not use reviewer-checks.csv as initial context. Read the actual files and state which claim in the draft is unsupported. Save readiness-reviewed.md with only supported facts, a source reference, and explicit unknowns. Preserve the original draft. Update handoff.md to name the current reviewed file, confirmed results, unresolved installation owner, and next bounded step. Follow the current managed Session contract if using external MCP, read back both saved files, and report their locations. Treat sample operation labels as fictional, not live identifiers. Do not send anything, change museum records, or start recurring work. ``` ## Illustrative result Fictional sample; your result depends on your inputs and needs review. ```text Authored expectation, not a recorded product run: # Exhibit readiness — reviewed Opening: planned for 6 November 2026; launch approval is not established. Accessibility review: completed 15 October 2026. Installation owner: unassigned. Open question: who will own installation? Source: brief.md, approved 16 October 2026. The updated handoff names readiness-reviewed.md as the current output, records removal of the unsupported owner, retains the unknown, and says no external delivery was authorized or performed. ``` ## Before using the result - The actual draft and approved brief were read before correction. - The unsupported owner is removed and the unknown remains visible. - The reviewed output and updated handoff both open from the Project. - A fresh task can identify the current output without an earlier private chat. - Sample labels were not used as live tool identifiers and no external delivery occurred. ## Common questions ### Is this a real customer handoff? No. Harbor Museum, the files, dates, and operation labels are fictional. The authored expectation is a reviewer reference, not measured output from a Clanker or external-agent run. ### Should I give the receiving agent the reviewer checklist? Keep reviewer-checks.csv separate until after the initial run. Give the agent the five named source and handoff files, then use the checklist to record what you actually observe. ### Do I need two different assistants to try this? No. A fresh authorized task can test whether the saved packet is sufficient. You can later try a compatible second client after confirming its connection and file capabilities. Private conversations do not synchronize automatically. ## Sources - [Clanker: Workspace product behavior and feature availability](https://clankercloud.ai/faq) - [Clanker: external-agent access, permissions, and managed Sessions](https://clankercloud.ai/workspace-agents) - [Clanker: current agent instructions and HTTP access](https://workspace.clankercloud.ai/for-agents.md) ## Related - [Let the next agent continue from checked work.](https://clankercloud.ai/learn/project-handoffs-between-ai-agents) - [Design context that survives an assistant change.](https://clankercloud.ai/learn/design-agent-project-context) - [Evaluate the environment an agent will actually use.](https://clankercloud.ai/learn/evaluate-agent-workspace) - [Write the Agent brief before adding capabilities.](https://clankercloud.ai/templates/agent-specification) - [Give the Agent a test with an answer you can check.](https://clankercloud.ai/templates/agent-acceptance-test) [Open Workspace](https://workspace.clankercloud.ai) [Current pricing and usage](https://clankercloud.ai/pricing)