ZAMBO.

Direct answer

They are taking the project in-house. Hand over the finished record, not a folder they have to decode.

The client is bringing the project inside: their own team, their own AI, their own accounts from here on. The usual handover is a folder of exports, a long email, and a call where you narrate decisions nobody wrote down. Their team then spends its first weeks re-deriving what is done, what was decided, and what is still open, and their AI starts from zero because a folder of files is not a starting point an AI can pick up. There is a better shape. Hand over the job as one living record: every finished step with its own verifiable receipt, every decision with its decider and date, the parts that were not checked named as not checked, and the open items listed as the next steps. Their team reads it in an hour. Their AI picks it up and continues the same job instead of starting a new one. Here is how to build that handover, what to settle before you send it, and how to close your own side cleanly.

See the instrument first: the live demo runs one real call and hands you its verifiable receipt, no signup.

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. Stop treating the handover as files, and list what the receiving team actually needs

A team taking over a live project needs four things, and a file dump reliably delivers only the first. The finished work itself: outputs, drafts, data, in their final delivered form. The state of that work: which parts are finished and accepted, which are finished and still waiting on a decision, and which were never finished at all. The decisions behind it: what was chosen, by whom, on what date, and what was rejected on the way, because the first thing a new team does with an unexplained choice is reopen it. And the open edge: what is not done, what was not checked, and what you would do next. Write these four as the checklist for your handover before you assemble anything. Every item you send should answer to one of the four, and any of the four left empty is a gap the receiving team will fill by guessing, usually against you.

Step 2. Freeze the project at a named finish line

A takeover needs a boundary both sides can point at. Pick the moment: work delivered through this date, under this version of the brief, is the finished record; anything after it belongs to the new team. State the boundary in the handover itself, with the last delivered step named. Without a freeze, the record and the live project drift apart within days and nobody can tell whether a missing step is your gap or their new work. With one, every later question has a clean form: was this inside the freeze or after it. Settle the money against the same boundary at the same time: the fee state for the finished record, what remains owing, and for what, so the takeover conversation and the payment conversation close together instead of trailing each other for months.

Step 3. Read the two states a handed-over record can sit in

A handover carries its decision state with it, and the receiving team deserves to see that state plainly rather than discover it. 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 states a delivery can carry into a takeover:

Accepted: the decision is on the record

Pending: checked, and still waiting on a decision

The accepted record, 4 steps, 4 checked, decided_by client at 2026-10-16T14:31:51.146Z, release_hint ok_to_release, is the clean takeover shape: the work is finished, the client has already accepted it on the record, and the new team inherits a job whose last decision is settled. The pending record, 5 steps, 5 checked, release_hint hold, is the honest mixed shape most real takeovers are in: every step is checkable, and one decision is still outstanding. Handed over in that state, the record tells the new team exactly what they own on day one: chase that one decision, with the steps already checked beneath it. Either state transfers cleanly. What does not transfer is the third state, no record at all, where the new team inherits files and folklore in equal measure.

Step 4. Wrap the job as one handover their AI can pick up

Assemble the handover as a single wrapped record, not a bundle of attachments. The wrap names the goal in the client's own terms, summarises the job as it stands at the freeze, lists the steps in the order they ran with the saved result of each, carries the decisions with decider and date, names what was not checked, and ends with the next steps written for a reader who was not there. Then send one link. The receiving team's AI picks the handover up from that link and continues the same job record, so the work their AI does next lands as further steps on the record you started, with its own receipts, instead of in a new history that forks the project's memory in two. Brief their team lead on the shape in one short call or message: here is the record, here is what is accepted, here is the one open decision, here are the next steps as written. Thirty minutes of framing, and the takeover is a continuation rather than an excavation.

Step 5. Hand over access and loose ends as a separate, written list

Keep the record and the logistics apart. The record is the work. The logistics are everything around it: files and where the masters live, accounts or access you hold that they need back or transferred, anything you were lent, and any third party arrangements that name you and should now name them. Put the logistics on one written list, work it with their lead, and mark each item closed as it moves. Two rules protect you here. Never let the logistics delay the record: send the handover link on the agreed day even if an access transfer is still grinding, because the record is what their work depends on. And never leave your own access ambiguous: what you keep, for support or for your records, is stated; what ends, ends on a date both sides have in writing. A takeover that closes this list in a week is remembered as professional long after the project details fade.

Step 6. Close your side with a short support window, in writing

End the handover with the terms of your own exit, kept short and written into the delivery message. Name a support window, two to four weeks is the common shape, during which you will answer questions about the record, and state what counts as a question about the record versus new work, which is quoted and scheduled like any new job. File your copy of the handover link with the final invoice and the client index entry, so a question arriving in a year finds you able to open the same record their team is looking at. Then stop. The cleanest professional signal in a takeover is a supplier who hands over completely, answers from the record during the window, and does not hover. Clients remember that completeness when the next project is being staffed, including the projects they chose to bring in-house this time.

What a record does not settle

A verifiable receipt proves the saved result was not changed since it was saved; it does not transfer ownership of the work, teach the receiving team your craft, or decide what support you owe after the handover. The freeze, the four part checklist, the decision state handed over plainly, and the written logistics list are what this answer stands on. This page is general information, not legal advice.

Frequently asked questions

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?

Freeze the project at a named finish line, then hand over one wrapped record instead of a folder of exports. The record carries the goal, the steps in order with the saved result and a verifiable receipt on each, the decisions with decider and date, the parts that were not checked named as not checked, and the next steps written for a reader who was not there. Send it as one link the receiving team can read in an hour and their AI can pick up to continue the same job, so their work lands as new steps on the record you started rather than in a forked history. Settle the fee state for the finished record at the same freeze, hand access and logistics over on a separate written list, and close with a short written support window for questions about the record.

What is wrong with just sending them all the files and a summary email?

Nothing, for a dead project. For a live one the team is continuing, the folder fails in predictable places. Files carry no state: nothing in a folder says which draft was accepted, which figure was superseded, or which part was never checked. A summary email flattens decisions into narration, with no decider and no date the new team can rely on when a choice gets reopened. And their AI cannot pick up a folder as a job: it can read files one at a time, but it starts a fresh history, so every step it takes from there is detached from the steps you took. The wrapped record fixes each failure at its root: state on the record, decisions with names and dates, and a pickup that continues the same job. The files still go over, as the logistics list in this page describes; they just stop being the handover itself.

The client has not accepted the final stage yet. Can I still hand over?

Yes, and the record makes that state easier to hand over, not harder. A delivery does not need to be fully accepted to transfer; it needs its state stated plainly. In the handover, name each stage as accepted, delivered and waiting on a decision, or not finished, with dates. An outstanding acceptance then becomes the new team's first listed task, with the checked steps sitting beneath it, instead of a surprise they find in week three. Do settle in writing whose job it is to close that decision and by when, and how the fee attached to that stage is treated in each outcome. Takeovers go wrong on unstated states, not on pending ones: a pending decision everyone can see is a task, while a pending decision nobody mentioned becomes an accusation.

Should I stay available after the handover, and for how long?

Yes, briefly, on written terms. Offer a support window of two to four weeks for questions about the record: what a step did, where a decision came from, what a file is. That window is cheap for you because the record answers most questions before they reach you, and it is valuable to the client because the new team is at its most uncertain exactly then. State the boundary in the same message: questions about the record are covered in the window; new work, fixes to things their team changes, and anything after the window are quoted as new jobs. Keep the boundary warm and plain. Suppliers who vanish at handover get blamed for the new team's learning curve, and suppliers who never leave get treated as unpaid staff. The window, stated once and kept, is the middle that protects your reputation and your calendar at once.

How do I hand over so their AI starts from the record instead of from zero?

Give the job a wrapped record their AI can pick up, not a pile it can only read. When the work runs through Zambo, each job is wrapped as a handover whose steps each carry a verifiable receipt under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, and picking a handover up in another AI is always free, so the client's team and their AI continue the same record with the decisions and open items already in it. 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 takeover that way and hand over a starting point instead of an archive: get the Day Pass. A Day Pass is unlimited for 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 a month, and $19 a month for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.

Related