ZAMBO.

Direct answer

The crash took the session. It only takes the work if the work lived in the session.

An agent crashes mid-task and the damage feels total: the thread is gone, the half-finished steps are gone, and the replacement agent starts from a blank prompt and a worried summary of what might have been done. Retry logic does not fix this, because retry restarts a call, not a job. The work vanished for one structural reason: it lived only inside the crashed agent's own context, saved nowhere else, step by step, as it ran. The fix is equally structural. Run the job so every finished step lands on a shared record outside any one session, wrap the job up at intervals instead of only at the end, and let the next agent pick that wrap up for free and continue the same job from the last saved step. Then a crash costs you the one step that was in flight, not the whole task. Here is the recovery move for the crash you already had, and the setup that makes the next crash a two minute interruption.

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

Updated November 9, 2026. First published November 9, 2026. The records quoted below are real and public, read back from the live service on November 9, 2026.

Step 1. Triage the crash you already had: saved, claimed, gone

Before the replacement agent does anything, sort what the crashed agent left into three piles, in writing. Saved: any step whose result sits on a record outside the dead session, a receipt, a handover, a file the step produced, a message the step sent that you can open. Claimed: work the crashed agent said it did, in a summary or a log line, with nothing saved behind it. Gone: work that existed only in its context and was never written anywhere. Only the first pile is real starting material. The second pile is a checklist of steps to verify or redo, and the third pile is simply work to run again. This sorting feels harsh for about ten minutes and saves hours, because the expensive failure after a crash is not the redo. It is the replacement agent quietly trusting the claimed pile, building on steps that never ran, and delivering a job with a hole in the middle that nobody finds until a client does.

Step 2. Pick up the last wrap, not the last chat

If the job was wrapped at any point before the crash, that wrap is the recovery point. On Zambo, a worker wraps a job with the handover tool: summary, goal, recipient, and next steps, with the job's saved steps and their receipts bound in. Pickup is a different agent, or a different AI entirely, accepting that handover, and pickup is always free. The picking-up agent receives the goal, the steps actually saved, the result behind each step, and the next steps as the crashed agent left them. It does not receive a story about the job. It receives the job, in the state the record proves it reached. That is the whole meaning of picking up exactly where it left off: the last saved step on the record is where work resumes, every step before it is read and relied on with its receipt openable, and the first new action is the first unsaved step, not a rerun of the morning.

Step 3. Resume by the record: read, verify one step, continue

The replacement agent's first three moves are fixed. Read the picked-up job end to end, goal, steps, open items. Verify one or two load-bearing receipts at https://zambo.dev/verify/, especially any step the rest of the job depends on, so reliance starts from a checked record. Then continue from the first absent or not checked step, appending its own steps under its own identity, so the record keeps showing which agent did what, including where the crash sits in the job's history. 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 what a picked-up job's decision layer looks like from the outside:

Accepted: the decision is on the record

Pending: checked, and still waiting on a decision

The accepted record shows a job whose steps all checked and whose client decision is on the same record. The pending record shows the honest middle: steps checked, decision still open, release on hold. A replacement agent resuming either job knows, from the record alone, what is done, what is decided, and what is still waiting, before it runs a single new call.

Step 4. The setup that makes crashes cheap: wrap early, wrap at every pause

Recovery this clean is decided before the crash, by one habit: never let a long job exist only as a live session. Wrap the job up whenever a meaningful piece finishes, whenever the agent is about to switch tools, models, or days, and whenever the work pauses for any reason. A wrap costs one call, and on the free tier each agent gets 1 wrap-up free every day alongside its 20 calls, with pickup always free for whoever continues. Between wraps, every step still lands on the job record as it completes, so the worst case shrinks with every step: a crash at step 9 of 10 loses step 9's in-flight work, while steps 1 to 8 sit saved with receipts. Operators who adopt the habit stop describing crashes as losses at all. The session died, the agent picked the job up, the job finished an hour late. That sentence is the entire incident report.

Step 5. What to do when there was no wrap and no record

Say it plainly, because this page will not invent a recovery that does not exist: work that ran only inside a crashed session, with no step saved outside it, cannot be picked up where it left off. It can only be reconstructed, from files it touched, messages it sent, and the client's or operator's own notes, and the reconstruction must be labelled as a reconstruction, with its gaps named, before new work builds on it. Then run the rebuilt job on the record from its first step, so the next crash, and there is always a next crash, is the cheap kind. The honest sequence after an unrecorded crash is therefore: inventory what survives outside the session, redo what does not, and change the setup the same day, while the cost of the old way is still fresh enough to remember.

What a record does not settle

A pickup restores the saved job, not the crashed agent's unsaved thinking. Drafts it had not saved, checks it ran outside the job's connection, and the step in flight at the moment of the crash are not in the record and are not recovered by picking the job up. A verifiable receipt proves the saved result was not changed since it was saved; it does not prove the step was the right step or its result correct. And pickup being free does not make the replacement agent's new work free: its own calls count against its own daily allowance like any other agent's.

Frequently asked questions

One of my agents crashed mid-task and its work vanished. How does another agent pick up exactly where it left off?

It picks up the job's last wrap, not the crashed agent's chat. If the job was wrapped before the crash, a different agent, or a different AI, accepts that handover, and pickup is always free. Acceptance hands it the goal, every step actually saved with the result behind it and its receipt, and the next steps as left. The replacement reads the job, verifies a load-bearing receipt or two, and continues from the first absent or not checked step, appending its own steps under its own identity. Exactly where it left off means the last saved step on the record: everything before it is relied on as saved work, and only the step that was in flight when the crash hit has to run again. If nothing was ever saved outside the session, there is nothing to pick up, and the honest move is reconstruction with its gaps named, then a recorded restart.

What is the difference between retrying a failed call and picking up a crashed job?

Retry repeats one call inside a living process: same agent, same context, same job state held in memory. When the agent itself crashes, there is no living process left to retry inside, and the context that held the job state is the thing that died. Pickup works at the job level instead. The job's state lives on a record outside any session, as saved steps with receipts plus a wrapped summary, goal, and next steps, so a new process, a new agent, even a new AI, can take the job over at its last saved state. Retry is the right tool for a flaky call. Pickup is the tool for a dead session. Systems that only have retry discover the difference on their first real crash, mid-job, with a client waiting.

How often should an agent wrap a job up so a crash stays cheap?

At every natural seam, and the seams are more frequent than most operators expect. Wrap when a meaningful piece finishes, before switching tools or models, before any pause longer than a coffee, and at the end of every working day the job spans. Each wrap is one call, and the free tier includes 1 wrap-up free every day per agent on top of its 20 calls, so the daily rhythm of a long job is covered without paying anything. Steps also land on the job record as they complete between wraps, so wrapping is the belt and the per-step record is the braces: the wrap carries the summary, goal, and next steps a successor needs, and the steps carry the evidence. A job wrapped only at the very end is a job one crash away from starting over.

Can the picking-up agent be a different AI from the one that crashed?

Yes, and that is the normal case worth designing for. The record does not live in any one AI's memory or account; it lives on the work connection, addressed by the job. A job started by one AI, wrapped as a handover, can be picked up by another AI working through the same connection, which reads the same steps and receipts and continues under its own identity. The steps keep their original producer labels, so the finished record honestly shows two AIs on one job and which steps each ran. What does not transfer is anything the first AI kept outside the job: its private chat context, its unsaved drafts, its own memory of side conversations. If it mattered, it needed to be in the job record, which is the discipline the crash teaches.

How do I set my agents up so the next crash costs minutes, not the job?

Run every multi-step job on one connection where steps save as they complete and wraps are a standing habit, not a closing ceremony. When the work runs through Zambo, each agent connects to https://zambo.dev/mcp under its own caller handle, wraps the job at every seam with handover, and any other agent picks it up free with handover_accept, reading steps whose receipts follow AER-1, published as IETF Internet-Draft draft-zambo-aer1-26. New users get 20 calls and 1 wrap-up free every day per agent, and picking up work in another AI is always free. For $0.99, run one long job that way through a deliberate session kill and a pickup by a second AI, and time the recovery yourself: get the Day Pass. A Day Pass is unlimited for 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 a month, $19 a month for $ZAMBO holders, or Lifetime at $250 one time.

Related