Transfer agent state between frameworks without starting over

The job is half done in one framework and needs finishing in another: LangChain to CrewAI, a prototype in Claude that production runs in ChatGPT. The naive move is pasting the chat transcript and hoping. What actually transfers is not the framework's private memory. It is the work itself, as a trail of calls, results, and receipts the next framework can read and continue.

See one in about 10 seconds: the live demo runs one real call and hands you its verifiable receipt, no signup.

Published October 18, 2026. Updated October 18, 2026. Written against draft-zambo-aer1-23.

What state honestly means here

Two different things get called agent state. The first is framework internals: a graph's checkpoint format, one library's memory objects, a vendor's session store. Those are implementation details, they differ on purpose, and they do not port. Any tool promising to lift them wholesale between frameworks is promising to reverse engineer two moving targets at once.

The second is the work state: what the job is, which steps ran, what each step returned, which sources were used, what was decided, and what remains unchecked. That state is portable, because it can live outside any framework, as a record. Transfer the record, and the receiving framework starts from the work instead of from a story about the work.

The trail is the transfer format

On Zambo the trail has three layers, each readable without the framework that produced it:

  • A verifiable receipt per call. Every tool call leaves an AER-1 receipt: the tool, the inputs, the observed result, the time, and a digest over the saved result. Receipts are plain records at public URLs, so any framework, or any human, can read them.
  • A handover for the job. The handover gathers a job's steps, sources, and decisions onto one page, with the gaps named. It is the unit a second framework picks up.
  • Continuation. The receiving side continues from the handover instead of restarting, and its steps land as the next link in the same chain, so the job reads as one record across both frameworks.

A transfer that already happened, and was accepted

Claude started it, ChatGPT finished it, the client accepted it

This morning a job ran in two hops. The first AI ran ten steps and gathered them into the first handover. A second AI, in a different product, continued from that handover and finished the job as the second handover. The client opened the second link, walked the chain back to the first step, and accepted the work on the record at 2026-10-18T11:12:31Z. No transcript was pasted. The state that moved was the work.

Framework packages make the same pattern available inside your stack: langchain-zambo for LangChain, crewai-zambo for CrewAI, aer1-openai-agents for the OpenAI Agents SDK, aer1-autogen for AutoGen, and aer1-llamaindex for LlamaIndex each publish a job's events as receipts, and a plain MCP connection to https://zambo.dev/mcp does the same for Claude, ChatGPT, Gemini, Cursor, Grok, Windsurf, and VS Code.

Move a job in four steps

  1. Run the first leg where calls leave receipts. If the work already happened without records, the honest transfer is a handover written from what can still be checked, with the rest labeled not checked.
  2. Gather the leg into a handover. Steps, sources, decisions, and the open questions the next side must not silently inherit as settled.
  3. Hand the receiving framework the handover link, not a summary. Its first act is reading the record: what ran, what each step returned, what is still open.
  4. Continue, do not restart. The new steps attach to the same chain, so the finished job shows both frameworks' work in one trail, and the acceptance at the end covers the whole job.
Honest limits: Zambo does not reach inside a framework and extract its private memory, and it cannot recover steps that ran before any record existed. What transfers is the recorded work. A verifiable receipt proves the saved result was not changed since it was saved; it does not prove the receiving framework will use the state well. That part is still engineering.

Make every job portable by default

Transfers stop being projects when the trail exists from the first call. Run the work through Zambo from the start and the state is already in transfer format, whichever framework finishes the job. A $0.99 Day Pass covers a full day: start the job in the morning in one AI, hand it over at lunch, finish it in another by evening, and send the client one chain at the end of the day.

Questions, answered

How do I transfer agent state between frameworks?

Transfer the work trail, not the framework's internals. Run the job so every tool call leaves a verifiable receipt, gather the job into a handover that lists the steps, sources, decisions, and what is still unchecked, then have the receiving framework continue from that handover. Its new steps attach to the same chain, so the job remains one record. On Zambo this works across LangChain, CrewAI, the OpenAI Agents SDK, AutoGen, and LlamaIndex through small packages, and across AI clients like Claude and ChatGPT through the MCP connection.

What part of agent state actually transfers?

The work state: the job's goal, the steps that ran, each step's inputs and observed results, the sources used, the decisions made, and the honest list of what was never checked. That state can live outside any framework as receipts and a handover. Framework internals, like one library's checkpoint format or memory objects, do not transfer, and do not need to: the receiving framework rebuilds its own internals from the work state it reads.

Can I move a job from LangChain to CrewAI?

Yes, at the work level. Publish the LangChain leg's events as receipts with langchain-zambo, gather them into a handover, and start the CrewAI leg from that handover with crewai-zambo attached, so the crew's steps continue the same record. The crew does not inherit LangChain's memory objects. It inherits something better for a handoff: the checkable record of what the first leg actually did, including the steps it left unchecked.

What does not transfer between frameworks?

Private memory that never became a record: a framework's internal scratch state, unlogged reasoning, and any step that ran outside recorded tools. If a step mattered and left no receipt, the transfer carries a labeled gap, not a reconstruction. Zambo also cannot move state out of an AI product's own chat history by itself. Work has to run through connected tools for the trail to exist, which is why the transfer pattern starts with running the first leg on recorded tools.

How does the receiving framework verify the state it inherits?

By checking the receipts. Each step's saved result carries a digest, and the receiving side, or any reviewer, can recompute it or run the receipt through a verifier to confirm the record was not changed since it was saved. Steps whose sources did not resolve, or that nobody checked, are labeled in the handover instead of smoothed over, so the receiving framework inherits the doubts along with the results, which is what makes the transfer trustworthy enough to build on.

Related