An exported conversation can help a new agent understand the work without giving it the files, permissions or execution state needed to continue. Treat migration as a delivery with acceptance checks: prove what arrived, what still means the same thing and what must be rebuilt.
This is a proposed session-portability reference, reviewed September 12, 2026. It does not rank vendors or claim a universal session format. The twelve rows describe things to inspect when moving a real task, including the cases where copying a file is insufficient.
- 01Export is only the first check.A readable archive does not prove the destination can resume the workflow.
- 02Some state must be rebuilt.Tool bindings, environments and credentials need destination-specific handling.
- 03Pending work needs reconciliation.A transferred message is not proof that an external action failed or stopped.
01 — Practical decisionDefine whether you need an archive or a working continuation #
An archive preserves evidence of what happened. A working continuation gives another system enough context and capability to perform the next valid step. These are different acceptance targets. A transcript may satisfy an audit request while failing the migration request entirely.
For a continuation, start with the latest accepted task and list the next operations. Ask what each operation needs: a file, a current external record, a tool connection or a decision the user already made. This identifies the smallest useful transfer package without assuming that the full chat history is necessary or sufficient. The LangGraph persistence documentation illustrates why memory needs separate treatment: checkpoints contain thread state, while stores hold cross-thread application data. That is a framework-specific distinction, not a promise that either can be imported into another provider. Record the actual export and import representation for the systems involved.
02 — Practical decisionCheck each item at the destination #
The first four rows concern records or files that can often be transported when an export path exists. The next four concern interpretation or execution that must be reconstructed. The last four concern outcomes that need reconciliation. These are proposed review categories, not guarantees about a product.
For each row, add the source location, destination location and evidence that the acceptance check passed. Unknown means the check has not established the result. Not applicable means the task does not require that item; it should include a reason rather than becoming a convenient label for missing information.
| Digital Applied proposed export-acceptance reference, September 12, 2026. Rows classify migration checks, not verified provider support. | ||
|---|---|---|
| Item | Transfer treatment | Destination acceptance check |
| --- | --- | --- |
| Messages and attachments | Export the available record | Open messages and resolve their attachment references. |
| Workspace files | Copy the actual bytes | Compare a manifest, sizes and hashes where available. |
| Repository history | Transfer required commits and refs | Check out the required revision with its dependencies. |
| Accepted instructions | Copy the current instruction version | Identify which requirements supersede earlier messages. |
| Memory records | Map meaning and scope | Separate user facts, preferences and unverified inferences. |
| Tool definitions | Recreate supported interfaces | Verify names, argument shapes and expected results. |
| Execution environment | Rebuild from an environment record | Run a harmless readiness check in the destination. |
| Credentials and permissions | Reconnect through approved secret handling | Verify current scope without putting secrets in a transcript. |
| Pending operations | Query the original operation owner | Establish completed, running, cancelled or unknown. |
| Completed external actions | Verify against the authoritative system | Prevent the continuation from repeating accepted actions. |
| Artifact delivery | Resolve durable file and recipient access | Open the intended version as the intended recipient. |
| Scheduled work | Reconcile old and new schedules | Identify which scheduler remains responsible. |
03 — Practical decisionKeep file transfer separate from environment recovery #
For repository work, a commit identifier is valuable only when the destination has the corresponding objects. The Git bundle manual documents offline transfer of objects and references, including verification of required prerequisite commits. A bundle is a useful repository-transfer mechanism within that scope. It does not make uncommitted edits, ignored assets, secrets or running processes part of the Git history. Inventory those separately. A successful clone can still leave the agent unable to open a design file, locate an uploaded document or reproduce a dependency installation.
Use the runtime dependency reference for the broader environment. For this transfer, name the exact next check: opening the document, building the selected revision or reading a known test record. A general statement that the workspace was restored is weaker than evidence that its required capabilities work.
04 — Practical decisionTreat memory as data with meaning and provenance #
A field called memory may contain confirmed preferences, summaries, inferred facts or application-specific instructions. Copying its text without those distinctions can promote an old guess into a current requirement. Preserve who supplied an item, its scope and whether later information replaced it.
Likewise, a tool name in a transcript does not give the new agent that tool. Recreate the binding and confirm the meaning of its arguments. A destination may use a different identifier scheme or return different fields. Prefer a small checked mapping to a large import that silently discards unsupported parts.
Do not promise that private model reasoning, hidden provider state or a process suspended inside another runtime will transfer. Mark undocumented exports as unknown. Our state responsibility reference identifies the owners; this reference asks whether the receiving system can use what those owners provide.
05 — Practical decisionReconcile pending actions before enabling the new agent #
Imagine a document-generation task whose file was uploaded while its acknowledgment was lost. The conversation says the upload is pending, but the destination storage already contains the artifact. Repeating the operation might create another version or notify a recipient twice. Query the original operation before choosing the next step.
The MCP cancellation specification allows cancellation to race completion or be ignored when a request cannot be cancelled. Copying a cancellation message therefore does not establish a stopped operation. Preserve the operation reference and verify the terminal outcome in its owning system.
A migration also needs a clear owner for recurring work. If the old scheduler remains active while the new system creates an equivalent schedule, both may run. Keep the original task d or otherwise controlled until you have verified which system is responsible. The handoff ownership guide covers acknowledgment between workers.
Illustrative working record
Illustrative migration record: report draft copied and opened; repository revision available; external upload outcome unknown; new agent limited to read-only inspection until the original upload is reconciled.
This is an example of the record's shape. No platform migration was executed for this article.
06 — Practical decisionAccept the transfer with one bounded continuation #
Choose a safe next step that depends on the transferred package. Ask the receiving agent to identify the latest task, locate the correct artifact and explain which earlier work remains valid. Compare its answer with the authoritative records before allowing a consequential action.
Then exercise the relevant capability. For a coding task, that may be a targeted check against the preserved revision. For a research task, it may be opening the cited source and finding the passage used. The acceptance test should reveal missing information without hiding it behind a fresh reconstruction from scratch.
Retain the original package until the agreed checks pass and retention requirements allow cleanup. A migration with unknown rows can still be useful as an archive; it is not yet a verified continuation. AI transformation projects should specify this handover boundary before the source system is retired.
Download the blank acceptance worksheet. The reference rows are filled; observed status, evidence and checked date are deliberately empty. Record pass, fail, unknown or not applicable only after inspecting the relevant artifact or claim.
Evidence and scope
- Dates
- Editorial allocation: September 11, 2026. Sources retrieved and article reviewed September 12, 2026. Event dates are stated separately.
- Sources
- LangGraph persistence, the Git bundle manual and MCP cancellation specification. Sources provide bounded implementation examples, not a universal interchange contract.
- Method
- Twelve original inventory rows grouped into transport, reconstruction and reconciliation. Each row has one destination acceptance check. SVG counts derive from these groups; worksheet result fields are blank.
- Limits
- No vendor export/import pair was exercised. Unknown denotes unverified support or outcome; not applicable requires a task-specific reason. Private reasoning, live process migration and commercial retention comparisons are excluded.
07 — Next stepProve the next step can continue #
Prove the next step can continue
Accept a session transfer when the receiving system can locate the current requirements, use the required artifacts and identify unresolved external work. Preserve gaps explicitly; a complete-looking transcript should not conceal an incomplete migration.