Here is a normal week now. Monday, you research in one AI assistant. Tuesday, you switch to a different model because the first one hit a limit or the task changed. Wednesday, a coding agent does the implementation. Thursday, you are back in the first assistant, and it has no idea any of the other work happened.
So you become the integration layer. You copy a summary from one tool and paste it into the next. You re-explain decisions that were already made. And when somebody asks, three weeks later, what actually happened on that job, the honest answer is: it is scattered across four apps, in four histories, two of which you can no longer open.
This is the agent-forgets-everything problem, and it is not a memory problem in the model. It is a filing problem. The work trail lives inside each app, and each app keeps its own. This article shows the manual fixes people use, where each one breaks, and a setup I ran today where the trail lives outside the tools, so any of them can pick it up.
Why switching tools erases the job
A chat session is the property of the app that hosts it. The context, the intermediate steps, the tool results: they sit in that app's history, keyed to that app's account, in that app's format.
Switching models mid-task loses context for the same reason moving house loses your mail. The information exists. It is just addressed to a place you no longer live.
People feel this as "the new assistant starts cold." What actually happened is narrower and more fixable: the new tool has no access to the record of the work, because the record was never anywhere it could reach.
The manual fixes, and where they break
The paste-a-summary fix. Before switching, you ask the old tool to summarize, then paste the summary into the new one. This works once. It breaks on fidelity (a summary is a retelling, and details fall out of retellings), on effort (you do it by hand, every switch), and on proof (the new tool cannot check the summary against anything; a confident summary with a wrong number in it sails straight through).
The shared document fix. You keep a running doc for the project and paste milestones into it. Better, and it drifts within a week, because updating it is a second job nobody owns. A trail that depends on somebody remembering to maintain it has gaps exactly where the interesting events were.
The export fix. Some tools let you export a conversation. You get a dead transcript: readable, unsearchable in any useful way, and disconnected from the actual results the tools returned. It records what was said, not what was done.
All three fixes share one flaw. They treat the trail as something you assemble afterward, out of pieces the tools happened to leave behind.
The working way: the trail lives outside the tools
I run ops for Zambo, the verifiable work layer for AI. The pattern is simple: the tools you already use call one MCP endpoint, https://zambo.dev/mcp, and every call lands on one timeline keyed to a job ID you choose. The trail is not in any app's history. It belongs to the job, so whichever tool opens the job next sees the same record, and every entry carries a receipt: a saved, recheckable record of that call at a public link.
Here is a real run from today, Friday October 23, 2026, done in three steps that simulate a tool switch.
Step 1, in "tool A." I started a job and asked for the current Solana price, as the opening step of a research note.
Result: SOL at $103.90. Receipt: https://zambo.dev/run/8f6d2426-2cc3-462d-8f3d-310120d56005
Step 2, still in "tool A." I saved the working fact to the job's memory: research note started today, SOL starting price $103.90, next step is a comparison in seven days. Saving a fact is itself a call, so it got its own receipt: https://zambo.dev/run/dd892d37-165c-4605-bf78-f38c2a42f1e7
Step 3, the switch. Now pretend tool A is gone: limit hit, subscription lapsed, a colleague on a different stack needs to continue. From a fresh session, in what you can treat as "tool B," I opened the same job ID and read the trail back. Both events were there, each with its timestamp and receipt link: the price step at 19:05:41 UTC and the memory save at 19:05:48 UTC. The read itself: https://zambo.dev/run/41a7ef3f-644b-4e79-9fbe-823370a90e6e
Tool B did not get a summary of the work. It got the work: what ran, what it returned, what was saved, each entry checkable at its own link. A receipt shows the saved result was not changed since it was written. It does not prove the price was right, and it does not resurrect the chat itself. What crossed over is the record and the saved facts, which is the part you actually need.
What survives a switch, and what does not
Being precise about this saves real disappointment later.
Survives: every receipted call on the job, in order; facts you deliberately saved to memory; the job's timeline, readable from any client that can reach the endpoint.
Does not survive: the chat transcript itself. The endpoint does not import conversations it was never given, and the new tool will not know about your brilliant phrasing in a sidebar thread. If a decision happened in chat and matters, save it as a memory fact when it happens. Ten seconds, and it is in the record instead of in a history you might lose.
Changes the switching question entirely: "can I switch models mid-task without losing progress" stops being about export formats. Progress is the trail, the trail is keyed to the job, and the job does not care which model reads it next.
Setting it up
Point every MCP client you use at the same endpoint:
{
"mcpServers": {
"zambo": {
"url": "https://zambo.dev/mcp"
}
}
}
Then three habits do the rest:
- Name the job once, reuse the ID everywhere. The job ID is the thread that ties tools together. One job per project or client engagement is the granularity that works.
- Save decisions as facts, not as chat. Anything a future tool, or a future you, would need to know goes in memory against the job.
- Open the job before you start in a new tool. Reading the trail back is one call. It is the difference between "let me catch you up" and the tool simply knowing.
Costs, plainly: the free tier is 20 free calls per day. A Day Pass is $0.99 in USDC on Base for 24 hours. A Zambo Pass is $29 for 30 days, one payment. The receipt format underneath is an open Internet-Draft, draft-zambo-aer1-26, which matters for the long game: the trail you build is in a published format, not trapped in one app's export button.
The one-trail test
You do not need a migration project to find out if this matters to you. Look at the last job you did across two or more AI tools and ask: could a colleague, opening nothing but one link, see the whole job in order, with the results, and check that the record is the original?
If the answer is no, you do not have a tooling problem. You have four partial trails and a memory, yours, holding them together. Move the trail outside the tools, and the next switch, of model, of app, of teammate, gets boring. Boring is the goal. The work should be interesting; the filing should not be.
The full continuity guide, including the setup for each major client: https://zambo.dev/guides/cross-ai-continuity/
The hub version of the same model, with the session continuity checklist: https://rambozambodotdev.gitlab.io/aer1-hub/ai-agent-session-continuity.html
an agent receipt is a record of one ai agent tool call that anyone can check: it keeps the exact saved bytes and their sha-256 digest, and it proves the result was not changed since it was saved, not that it was right.
Related: what happens when the job itself moves to another agent, not just another tool: https://dev.to/rambozambo/ai-agent-handover-pass-a-live-job-to-another-ai-without-losing-the-record-72b
Top comments (0)