What has to survive when an AI assistant moves machines

Begin the migration plan with an inventory before copying a home directory. A home directory copy moves whatever happens to be visible and misses the state held by services, databases and external credentials. It can also copy caches and stale configuration that should be rebuilt on the new machine. The inventory needs to name each component, its location, owner, backup method and recovery test. For an AI assistant, that can include model configuration, system instructions, memory records, source documents, indexes, tool definitions, scheduled jobs, service units and secrets. Some are files. Others live in a database or an external account. I am also marking which machine is authoritative during the move. If both hosts can accept jobs, their memory and activity records can diverge. A short read-only period or a clear cutover time is easier to reason about than trying to merge two histories later. The main prompt is usually easy to find, but it may refer to files, environment variables, command-line tools and directory paths that are specific to the old host. Copying the text proves very little if those references no longer resolve. I am collecting the active instructions and recording their versions or hashes. Then I can list dependencies next to each one: supporting files, expected commands, required working directories and any model-specific settings. Relative paths are preferable where the layout is under my control. Host-specific paths need an explicit mapping.

Test the instructions in a clean session on the destination. It should load the intended instructions, report the expected identity and follow a harmless standing rule. I do not want to test with an action that changes production data. A read-only question can reveal whether the instruction chain and source files are present without adding migration risk. An export of memory records is only one layer. The destination also needs the schema, indexes, embeddings or other derived search data, retrieval configuration and links back to original sources. If those pieces are missing, the assistant may technically retain its records while losing the ability to find or verify them. I separate authoritative data from rebuildable data. Durable records, correction history and source references belong in the backup. A vector index can often be rebuilt from those records, provided the embedding model and chunking rules are known. Treating the index as the only copy would make recovery depend on an opaque derived structure. After import, I plan to run a fixed set of memory checks. Each check asks for a known current decision, an item that has been superseded and a source-linked record. The expected behaviour is more specific than finding similar text. Current records should win, obsolete records should stay out of ordinary retrieval and the source link should open on the new host.

Counts help, but equal row counts do not show that relationships survived. Where memory uses a graph, I also need counts by node and relationship type, checks for dangling source references and a few traversals with known results. An assistant's effective permissions come from its tool definitions, credentials and network access. I do not want to transfer a credential bundle and discover later that the new host has broader access than intended or that a forgotten token no longer has an owner. The tool inventory should state whether each integration is read-only or can change an external system, how it authenticates, where its secret is stored and which approval rule applies. Secrets should move through the chosen secret store rather than through the general file copy. Rotate any credentials that have no clear provenance during the move. Each tool needs a small acceptance test. Read-only tools can perform a known lookup. Write-capable tools should use a sandbox, a reversible action or a dry-run endpoint. The acceptance test should confirm the expected account, scope and target so a valid credential for the wrong environment cannot pass on the strength of a successful HTTP response. Network rules deserve the same treatment. A database connection may work from an interactive shell and fail inside the service because the service has different environment variables or user permissions.

An assistant can appear healthy in an interactive session while its scheduled work is dead. Jobs may be defined in cron, a system service, a container scheduler or an application database. Their queues and last-run state can live elsewhere again. Before cutover, I am listing every background worker and schedule with its timezone, command, service user, input queue and output location. Then I can disable or drain the old runner before enabling the destination. This avoids two machines picking up the same work. The destination test should cover both manual execution and service restart. A worker that starts from a shell but fails after reboot is not migrated. I want to see one bounded test job move through queued, running and completed states, with its activity record and output visible. Make the host timezone, application timezone and schedule interpretation explicit. A copied schedule can fire at the wrong local hour even when the expression itself is unchanged. I am treating the move as a recovery exercise with a controlled cutover. Before changing traffic or schedules, the new host should restore from the same backup process I expect to use later. That tests the artefact and the instructions together. My acceptance list includes:

• services start after a reboot without an interactive login;
• the assistant loads the intended instruction set;
• current memory records and their sources can be retrieved;
• obsolete memory does not override current state;
• each required tool passes a scope-appropriate check;
• one background job completes and leaves an inspectable record;
• backups are created from the destination and can be read.

I will keep the old host unchanged until these checks pass and the destination has produced its first usable backup. The next action is to finish the component inventory and assign one concrete recovery test to every item that cannot simply be rebuilt.