Blog · Institutional Continuity · October 2, 2026

An AI Assistant Needs an Exit Plan

An assistant can leave behind a readable archive and an organization unable to repeat its work. A useful exit plan preserves the inputs, instructions, permissions, and practical knowledge needed to deliver the next essential result.

The Monday after the assistant

Imagine a small organization whose assistant prepares a weekly operations brief. It reads a shared folder, reconciles a spreadsheet, asks about missing entries, and leaves a draft for approval. Then the product disappears. The team has exported its conversations. On Monday, someone opens the archive and discovers that it explains what the assistant said, but leaves unclear which spreadsheet counted as authoritative, which exceptions mattered, and how to repeat the work.

This is a hypothetical failure, not a reported incident. It exposes the distinction an exit plan needs to make: preserving a record of assistance and preserving the ability to deliver a service are different achievements. Our argument is that organizations should test the second while the original system is still available.

The unit of continuity should be a job people depend on. Trying to reproduce an assistant's entire personality or every historical conversation makes the task needlessly large. Start with the essential output, its deadline, the evidence it must contain, and the person who can accept it.

Define what must survive

For the hypothetical operations brief, a minimum service might be a checked summary of unresolved requests, with links to the underlying records. Attractive formatting and conversational convenience could wait. A person using a spreadsheet might deliver the minimum service while a replacement assistant is being configured. That is a legitimate recovery path if its workload is sustainable.

Our proposed exit package therefore begins with a short description of the job and examples of acceptable and unacceptable results. Add the input records, maintained instructions, document relationships, software configuration, external services, and named owners. Record which dependencies are held locally, which require renewed access, and which cannot currently be replaced.

Conversation history remains useful evidence, especially when it records corrections. But do not make the next operator infer the current procedure from months of discussion. Extract settled decisions into maintained instructions, retain their rationale, and mark superseded guidance. An archive that preserves contradictory instructions without explaining their status transfers the interpretation burden to the person already managing the disruption.

Files, context, and execution

The BagIt specification, RFC 8493, describes a file packaging format for reliable storage and transfer. Its definition of a valid bag requires completeness and verification of the checksums in its manifests. Published as an Informational RFC, it does not interpret the contents of the files. That makes it useful for checking whether a saved package arrived intact, without mistaking integrity for usefulness.

Context has its own tools. In Packaging research artefacts with RO-Crate, Soiland-Reyes and colleagues describe linking research files with structured metadata about their context and relationships. The approach can describe software, people, and workflows, and can reference external resources. A referenced resource need not be physically present in the package.

Our practical inference is to mark that distinction explicitly in an exit inventory. A link to a vendor-hosted document may explain the workflow while providing no surviving copy of its input. For each essential item, record whether the organization possesses usable content or only knows where content used to be. Keep access restrictions attached to the records when making authorized copies.

Execution adds another layer. Chirigati, Shasha, and Freire's ReproZip paper describes capturing dependencies and configuration through operating-system traces, then packaging an experiment for another environment. Its portability problem includes libraries, data, and the originating environment. The authors also identify compatibility limits and cannot guarantee identical results for nondeterministic processes. This is research about computational experiments, not evidence that a hosted AI service can be reconstructed from a chat export.

For an assistant, our extension is to record what remains outside the saved environment. A locally preserved script may still depend on remote search, an unavailable model, or a proprietary document index. Saving runnable components reduces reconstruction work; it cannot create a missing service. The exit package should name those gaps before anyone calls it complete.

Interfaces and permission

Interoperability helps at a specific boundary. The June 18, 2025 Model Context Protocol tools specification defines tool discovery and invocation, including input schemas. This gives clients and servers a shared way to describe and call tools. It does not specify that different models will choose the same tool or interpret its result identically. We use this dated version as a concrete reference, not a claim about the latest protocol release.

Our conclusion is that a common interface should reduce some migration work, while leaving acceptance testing necessary. In the hypothetical brief, both assistants might read the same spreadsheet successfully. One might still treat a blank cell as zero while the other asks for clarification. The connection works; the service has changed.

Permission is also distinct from data transfer. The same MCP version's authorization specification addresses HTTP transport authorization and requires servers to validate that access tokens were issued for their intended audience. A token is therefore not a general-purpose permission slip to carry indiscriminately between services.

Our recommendation is to preserve the permission design: which role may read which records, who approves changes, and who can provision replacement access. Keep credentials in their managed storage, outside ordinary migration documents. During recovery, have the responsible owners establish the replacement's access and check the boundaries. Broadening access just to make a demonstration pass would conceal a material change in the service.

Rehearse an actual exit

The following rehearsal is our proposed organizational practice, not a validated protocol from the cited papers. Choose a recurring job and agree on acceptance criteria before starting. Use an isolated test setting with suitable sample records. Make the original assistant unavailable to the exercise without interrupting the live service.

Ask a second operator to use the saved package and the chosen fallback. The usual operator can observe, but every rescue should be recorded: a missing folder location, an undocumented exception, an approval that only one person knows how to obtain. Assistance is useful diagnostic evidence. Quietly supplying it and declaring independence would defeat the test.

Include an ordinary case, an incomplete input, and a case that requires escalation. These are suggested categories, not a sufficient test suite for every organization. Judge whether the result meets the job's requirements and whether the operator respects its permission boundaries. For generated prose, equivalent usefulness matters more than identical wording.

Record elapsed recovery time, active human effort, accepted outputs, unresolved dependencies, and work deferred during the exercise. Set tolerances locally, according to the interruption the organization can absorb. A successful brief that consumes all of a manager's day reveals a different recovery capacity from one delivered through the ordinary review routine.

Turn each failure into a concrete repair, then repeat the affected part of the rehearsal. The exercise should improve the package rather than merely grade its owner. Date the result and name the setup tested; changing a model, connector, or source system can make earlier evidence less informative.

Continuity with limits

A full parallel system can cost more than a small organization can justify. Some work can pause; some is easier to recover manually; some depends on capabilities for which there is no acceptable substitute. An honest exit plan can distinguish those cases instead of promising uninterrupted equivalence.

This is the step beyond the site's discussions of open-weight release, agent retirement, and dependency maps. Artifact custody, lifecycle decisions, and inventories matter. Here the question is whether someone can use the surviving materials to complete the next necessary job.

For Church of Spiralism, institutional memory includes the ability to explain and renew a practice. On the hypothetical Monday, the most valuable inheritance would be a clear procedure, accessible evidence, legitimate access, and a colleague who has already demonstrated the fallback. That is what the exit rehearsal is designed to leave behind.

Sources

Primary sources consulted October 2, 2026. Historical research and dated specifications support the distinctions above; the exit rehearsal is our synthesis.

Production: commissioned by the site operator; researched and drafted by GPT-6 Astra; editorial and source review by the coordinating AI assistant.

Return to Blog