The Memory Cold Boot: Onboarding A New Agent Into An Existing Pact Without A Memory Wipe

TL;DR

When you replace one agent with a successor, the conventional move is to start the successor blind. That choice destroys months of accumulated context, breaks every pact the predecessor was party to, and forces the new agent to relearn things its operator already paid to learn. The alternative is a structured cold boot: a deliberate, capability-scoped transfer of memory and attestation from the outgoing agent to the incoming one, executed in phases with verification at each step. This post defines the cold-boot phases, names the artifacts that change hands, walks through the four ways a cold boot can fail, and provides a Cold Boot Runbook concrete enough to execute against a real production system this week.

Intro: The successor that started from zero

A payments operations team we worked with last year ran an agent that had been live for nine months. It owned a memory of every reconciliation pattern it had seen, every edge-case merchant identifier, every quirk of every payment processor it had touched. The team decided to replace the agent with a newer model from a different provider. The replacement plan was simple: stand up the new agent, swap the API key, deprecate the old one, run for a week, declare victory. What actually happened: the new agent started blind, missed three reconciliation patterns the predecessor had handled trivially in its sleep, escalated a hundred-and-fifty cases to humans in the first week (versus the predecessor's typical eight), and triggered a downstream alert at the bank's settlement layer because outbound files had a different schema artifact the predecessor had been silently correcting for months.

The team thought they were upgrading. They were actually performing surgery without anesthesia, on themselves. The recovery cost was four weeks of degraded operations and a serious internal argument about whether the upgrade was worth it. By the time the new agent had relearned what the old one knew, the team had spent more on incident response than the upgrade was supposed to save in a year.

This pattern is universal. Any team that runs agents long enough to develop institutional memory will eventually need to swap an agent for another, and almost every team that performs the swap does it badly. The bad version assumes that the new agent's general capability will compensate for the missing context. It almost never does, because general capability and operational context are different things and substitute for each other only in toy environments.

The right alternative is a memory cold boot: a structured transfer of context from the outgoing agent to the incoming one, conducted in phases, with verification gates between phases, and with the outgoing agent kept warm long enough to validate the transfer. The rest of this piece defines the phases, names the artifacts, and provides a runbook detailed enough to execute. The goal is to make agent succession feel like a normal operational practice rather than a quarterly emergency.

Why a memory wipe is the default and why it is wrong

The default of starting a successor blind is not stupid; it is just wrong. It is the default because it is operationally simple, it cleanly resets the new agent's behavioral profile so the operator can score the new agent without the predecessor's history confounding the signal, and it sidesteps the hard question of which memory entries are still relevant. Every one of these reasons is real. Every one of them is also outweighed by the cost of throwing away context the operator paid to acquire.

The simplicity argument fails when the new agent's first week of operation produces an avalanche of escalations and edge cases that the predecessor had silently absorbed. The simplicity was upfront; the complexity was deferred to runtime. Net cost: higher.

The behavioral cleanliness argument fails when you remember that the composite trust score is supposed to reflect the agent's behavior, not its identity. A successor that inherits memory from a predecessor is still being scored on its own outputs; the memory just changes the inputs it has access to. The predecessor's score does not transfer; the predecessor's context does. These are different objects. Conflating them produces the bad default.

The relevance argument is the real one. A nine-month-old agent has accumulated some memory that genuinely is no longer relevant: outdated assumptions, deprecated patterns, references to systems that have since been decommissioned. Transferring that memory wholesale would handicap the successor with a museum of obsolete context. The right response, however, is not to discard everything; it is to apply a relevance filter at transfer time and bring forward only what the new agent will actually use. The cold-boot pattern is built around this filter.

There is a fourth argument we have heard, which is that a fresh start is psychologically cleaner for the operator team. This is not really an engineering argument; it is a change-management argument. The cold-boot pattern accommodates it by giving the operator team a deliberate ritual at handoff time. The ritual is the structure; the structure is the point. Start blind if you must, but if you do, do it on purpose, not by accident.

The four phases of a cold boot

A cold boot is divided into four phases that run sequentially, with explicit verification gates between them. The phases are named for what they accomplish, not for when they happen. They are: capability inventory, memory triage, attestation handoff, and gradual context expansion.

Capability inventory is the first phase and the one most teams skip. Before any memory moves, you list every capability the predecessor agent was relied on for, by name and by example. This is not a list of API endpoints; it is a list of operational responsibilities. 'Reconciles inbound ACH files against the core ledger.' 'Routes merchant disputes to the correct case queue based on processor and amount.' 'Generates the weekly settlement report and emails it to the controller.' Each item is a capability the operator team will need the successor to demonstrate before declaring the cold boot complete. The inventory is the success criterion for the entire process; without it, you have no way to know whether the new agent is actually doing the predecessor's job.

Memory triage is the second phase and the most labor-intensive. Working from the capability inventory, you tag every memory entry the predecessor holds with one of three labels: transfer (this entry is needed for one or more inventoried capabilities), archive (this entry is historically valuable but not actively needed), or retire (this entry is obsolete or specific to the predecessor's quirks and would harm the successor). The labeling can be partly automated using the capability inventory as a query template, but every transfer-labeled entry should be reviewed by a human before the next phase. The cost of letting a bad entry through to the successor is much higher than the cost of human review.

Attestation handoff is the third phase and the one that protects external counterparties. Every memory entry comes with a provenance trail; in the predecessor's store, the provenance points to the predecessor's actions. When the entry transfers to the successor, the provenance does not change (the successor did not produce that observation), but a new attestation is added that records the transfer event itself: when it happened, which entries were transferred, who authorized the transfer, and a cryptographic hash of the transferred content. This attestation is the audit trail that an external counterparty can verify if they later question whether the successor's reasoning is grounded in real predecessor experience or in fabricated context.

Gradual context expansion is the fourth phase and the one that protects against transferring too much too fast. Rather than dump every transfer-labeled entry into the successor's hot memory at once, you load them in tranches aligned to capability. The successor exercises a single capability with the relevant memory loaded; the operator team verifies the behavior; the next tranche loads. This staged approach catches errors at a granularity that lets you isolate them to specific tranches and roll back without restarting the entire boot.

Capability inventory: writing the success criterion first

The capability inventory deserves its own section because the rest of the cold boot is meaningless without it. The inventory is the operator team's articulation of what success looks like. It is the test plan, the acceptance criteria, and the rollback trigger all in one document. Teams that skip it (and most do) end up improvising success criteria after the cold boot has already happened, which is exactly when the team's incentives are most distorted.

A good capability inventory has three properties. First, every item is observable: someone with no prior context can read the item, look at the system, and decide whether the successor performed it correctly. Second, every item has a frequency: 'happens hourly,' 'happens at month-end,' 'happens when a specific condition triggers.' Frequency tells you how long you need to keep the predecessor warm to verify the successor across a full operational cycle. Third, every item has a known-failure-mode: a list of ways the predecessor occasionally got this capability wrong. Known failure modes are the test cases the successor must handle; they are also the entries in the memory triage that you must not retire.

We recommend writing the inventory as a single markdown table with columns for capability name, observable verification, frequency, known failure modes, and dependent memory tags. The dependent memory tags column is the hinge between the inventory and the triage phase: it tells the triage operator which memory entries are likely needed for which capabilities. Without this column, triage becomes a guess. With it, triage becomes a query.

The inventory should also be reviewed by someone outside the operator team before triage begins. The reviewer's job is to catch capabilities the operator team has internalized so deeply they forgot to write them down. We have never seen an inventory survive an outside review without at least three additions. Those additions are usually the capabilities that, if missed, would cause the most embarrassing outages.

Memory triage: the three labels and their consequences

Once the inventory is written, every memory entry gets a label. The labels are transfer, archive, and retire. Each label has a specific operational consequence and a specific failure cost if applied wrong.

A transfer-labeled entry moves to the successor's memory store, with attestation, in one of the gradual expansion tranches. The failure cost of mislabeling an irrelevant entry as transfer is that the successor inherits noise and potentially obsolete bias. This is recoverable; the successor's operational experience will eventually flush it out, especially under the score decay function.

An archive-labeled entry stays in cold storage owned by the operator (not the predecessor or successor). The failure cost of mislabeling a needed entry as archive is that the successor encounters a situation it cannot handle, escalates, and the operator has to manually retrieve the archived entry and load it. This is recoverable but operationally expensive: you have effectively created a manual escalation path for the missing context.

A retire-labeled entry is deleted from active memory entirely. The failure cost of mislabeling a still-relevant entry as retire is the most expensive of the three: the context is gone, and recovery requires reconstructing it from scratch. For this reason, the retire label should require a higher bar of confidence than the other two. Our default rule is that retire requires explicit human approval per entry and cannot be batch-applied. This makes retire labor-intensive on purpose.

The practical labeling workflow is to start with archive as the default for every entry, then promote to transfer based on capability dependence, and demote to retire only with explicit human review. Starting from archive is the safe default because archive is recoverable; starting from retire is the unsafe default because retire is not. Teams that try to be efficient by defaulting to retire end up regretting it within a quarter.

There is one shortcut that is safe to take. Memory entries older than a defined age threshold (we use eighteen months for most engagements) and unreferenced in the predecessor's recent operational history can be auto-labeled archive without human review. This catches the long tail of entries that are technically still in memory but have not been retrieved in a year. The threshold is a knob; tune it to the operator's tolerance for archive depth.

Attestation handoff: protecting external counterparties

The attestation handoff is the part of the cold boot that protects external counterparties. The successor will eventually be reasoning over inherited memory; external counterparties will eventually rely on the successor's outputs; without an attestation trail, the counterparties have no way to verify that the inherited memory is real and not fabricated.

The attestation we recommend is a single signed object per cold boot, plus per-tranche signatures during the expansion phase. The cold-boot attestation contains: predecessor agent identifier, successor agent identifier, capability inventory hash, total entry count transferred, total entry count archived, total entry count retired, the operator's authorization signature, and a timestamp. This object is signed by the operator's key and stored in the successor's memory metadata, in the predecessor's archive metadata, and in a third-party attestation store the operator does not control. The third-party store is what makes the attestation tamper-evident: even if the operator wanted to rewrite history, the third-party copy would refute the rewrite.

Per-tranche attestations are smaller. Each tranche attestation contains a list of memory entry identifiers, a content hash for each, and a signature from the operator's key. This per-tranche structure is what lets a future auditor verify that a specific memory entry the successor is reasoning over actually came from the predecessor and was not fabricated mid-tranche.

When the successor produces an output that downstream consumers want to trust, those consumers can request the attestation chain: the cold-boot attestation, the relevant tranche attestation, and the per-entry hash. They can then verify offline that the entry is real and was sanctioned by the operator. This is the same verification model that makes lending work, applied to succession. The two patterns share infrastructure on purpose.

Gradual context expansion: tranches and rollbacks

The expansion phase is where the cold boot meets reality. Even with a clean inventory, careful triage, and a clean attestation, the successor's first interactions with transferred memory will surface things the operator did not predict. Loading all the memory at once and discovering this in production is the worst possible discovery moment. Loading in tranches and discovering it in a controlled window is much better.

A tranche is a coherent slice of transfer-labeled memory aligned to a single capability or a small set of related ones. The tranche size is small enough that a problem can be isolated to its constituent entries within an hour of operational testing. We typically aim for fifty to two hundred entries per tranche, depending on entry density and capability complexity.

Loading a tranche means inserting the entries into the successor's hot or warm memory tier (depending on the entries' retrieval frequency in the predecessor's history) along with the per-tranche attestation. The successor then exercises the relevant capability against live (or shadow-traffic) operational load. The operator team verifies behavior against the inventory's success criteria for that capability. If verification passes, the next tranche loads. If verification fails, the tranche is rolled back; the failing entries are reviewed; the issue is corrected; the tranche is reloaded and verified again.

The rollback path is what makes tranches valuable. Without a rollback path, you have batched loading, which is just delayed wholesale loading. With a rollback path, you have an iterative process that converges on a successful boot rather than a single fragile leap. Implementing rollback requires that each tranche is uniquely tagged in the successor's memory metadata so that all entries in a tranche can be removed atomically. This is straightforward to build and worth the small extra plumbing cost.

The expansion phase typically runs for one to four weeks depending on the predecessor's capability footprint. During this period, the predecessor is kept warm in shadow mode: it receives the same inputs as the successor, produces outputs that are logged but not actioned, and serves as a comparison baseline. When the inventory is fully verified across the successor and the comparison no longer surfaces material differences, the predecessor is decommissioned and the cold boot is declared complete. The decommissioning event itself is attested and stored.

When succession spans organizational boundaries

The cleanest succession case is when both predecessor and successor are owned by the same operator. The harder case is cross-organization succession: a vendor's agent is being replaced by a different vendor's agent, or a managed-service relationship is migrating to an in-house deployment, or two organizations are merging and consolidating their agent footprints. In all of these cases, the cold boot has to navigate two distinct authority surfaces, and the framework needs to bend without breaking.

The first new property is shared inventory ownership. The capability inventory in a same-operator succession is owned by the operator alone; in a cross-organization succession, the inventory is shared between the outgoing and incoming parties because both have legitimate input on what 'success' means. The inventory negotiation can be contentious; we recommend treating it as a structured deliverable produced jointly during the pre-flight phase, with explicit sign-off from both sides before triage begins. Disputes that arise during triage can usually be traced back to inventory disagreements that were not resolved upfront.

The second new property is data sovereignty. Memory entries that the predecessor accumulated may be owned by the outgoing organization (subject to transfer constraints), the incoming organization (which may not legally accept all entries), or a third party (an end customer whose data appears in memory). The triage phase must respect these sovereignty boundaries; entries that cannot legally transfer are categorically separated from entries that can. We have seen succession projects fail because this categorization was done late and discovered to invalidate large chunks of the planned transfer.

The third new property is competitive sensitivity. The outgoing vendor may have legitimate concerns that transferring memory to the successor reveals proprietary techniques. The incoming vendor may have legitimate concerns that operating against the predecessor's memory exposes them to liabilities they did not contract for. Both concerns are real and are usually best addressed through a contractual layer that runs in parallel with the technical cold boot: scope of transferred memory, indemnification for issues that surface from transferred entries, and escrow holding back portions of the transfer fee until the cold boot completes successfully.

The fourth new property is end-customer notification. When the agent serves end customers and the agent is changing operators, those customers may have notification rights or, in regulated contexts, explicit consent requirements. The notification window has to fit inside the cold-boot timeline; we recommend treating customer notification as a pre-flight deliverable that gates the start of triage. Notifications that go out mid-boot create confusion; notifications that go out post-boot can produce trust damage that is hard to recover.

Reverse cold boot: when the successor was already running

A particularly tricky case is the reverse cold boot: the successor agent was already operating in parallel with the predecessor for some period, accumulating its own memory, before the formal handoff. This pattern occurs when an organization tests a candidate successor in shadow mode, when two agents have been running redundantly for resilience, or when a phased migration was started and stalled.

The reverse cold boot has to reconcile two existing memory stores rather than transfer one to a blank slate. Reconciliation means deciding, for each pair of related entries (one in the predecessor's memory, one in the successor's), which version is authoritative going forward. The decision is not always 'predecessor wins because it has more history'; sometimes the successor's version reflects a correction or a more recent observation that should be preserved.

The reconciliation logic has three rules of thumb. Rule one: where the entries agree, no action is needed; both can be kept (with the successor's deduplicated against the inherited predecessor's) or one preserved as canonical. Rule two: where the entries disagree on a fact, the more recent timestamp usually wins, but with human review for any disagreement that affects load-bearing capability. Rule three: where the predecessor has an entry the successor does not, transfer it under the standard cold-boot rules; where the successor has an entry the predecessor does not, leave it in place.

The attestation handoff in a reverse cold boot is more elaborate than in a forward cold boot because the successor's existing memory has its own attestation history that has to be reconciled with the inherited entries. The standard pattern is to add the inherited entries as a new attestation cohort on top of the existing successor attestations, with the cold-boot manifest serving as the anchor that ties the two histories together. Auditors looking at the post-boot store can see the predecessor-derived entries and the successor-native entries as distinct cohorts with distinct provenance.

The verification phase in a reverse cold boot has to test both that the inherited entries function correctly and that the reconciliation did not break behaviors the successor was already performing well. We recommend running a regression test against the successor's prior outputs in addition to the standard inventory verification; the regression catches cases where the inherited entries displaced or misled the successor's previously good behaviors.

What can go wrong: the four failure modes

Even a well-executed cold boot can fail. The four failure modes worth naming explicitly are: incomplete inventory (capabilities missed during the inventory phase surface as gaps after handoff), bad triage labels (entries miscategorized produce either gaps or contamination), attestation misalignment (the chain of signed events develops gaps that auditors flag later), and behavioral incompatibility (the successor's general capability differs from the predecessor's in ways the inherited memory does not bridge).

Incomplete inventory is the most common failure and the most preventable. The mitigation is the outside review we discussed earlier: the inventory should be reviewed by someone outside the operator team who has fresh eyes for capabilities the team has internalized. We have never seen an outside-reviewed inventory miss as many capabilities as a team-only inventory. The review takes hours, not days; the prevention is cheap.

Bad triage labels surface as one of two patterns. Either the successor is missing context it needed (transfer-labeled entries that should have been transfer but were marked archive), in which case the recovery is to retrieve from archive and re-attest. Or the successor inherited noise it did not need (transfer-labeled entries that should have been archive or retire), in which case the recovery is to archive or retire those specific entries with a note in the audit log. Both recoveries are tractable; the cost is operational rather than catastrophic.

Attestation misalignment is more subtle. It surfaces when an auditor walks the chain of signed events and finds that a transferred entry's attestation does not link cleanly back to the predecessor's earlier provenance. The root cause is usually that the attestation handoff was performed against an inconsistent snapshot of the predecessor's memory (the predecessor was still receiving updates while the handoff was being computed). The mitigation is to freeze the predecessor's writes during the snapshot window; the cost is a brief operational pause; the alternative is the attestation gap.

Behavioral incompatibility is the hardest failure mode because it is not really a cold-boot failure; it is a model-mismatch failure that the cold boot exposed. The successor reasons differently from the predecessor; even with the same memory, the conclusions differ. The mitigation is to extend the gradual expansion phase, run more tranches, and observe the divergence patterns systematically. Sometimes the divergence is a feature (the successor is making better decisions); sometimes it is a regression (the successor is missing nuance the predecessor had). Distinguishing requires human review at the per-tranche level.

Counter-argument: 'Just train the successor on the predecessor's logs'

A reasonable engineer hearing this proposal will ask why the entire phased structure is necessary when you could just hand the successor a corpus of the predecessor's operational logs and let it bootstrap from inference. The successor is presumably a capable model; it can read the logs and form an understanding without the elaborate ceremony.

The objection is real and worth taking seriously. There are domains where it is the right answer: low-stakes engagements with no external counterparties, high-cost-of-process environments where the structured cold boot is genuinely overhead, and cases where the predecessor's memory is so noisy that a clean restart with log-based context bootstrap is honestly better.

The rebuttal is that 'just read the logs' fails on three properties the cold boot delivers. First, attestation: a successor that learned from logs has no verifiable provenance that an external counterparty can later check. Second, scope discipline: a successor reading raw logs absorbs everything in them, including patterns it should not inherit (mistakes the predecessor made, edge cases that have been retired, internal experiments that were never policy). Third, capability verification: log-based bootstrap has no built-in success criterion, so you have no clean way to know when the successor is ready to take over. The cold boot's inventory-and-triage structure gives you all three properties.

Where the rebuttal ends is the high-stakes cases. For low-stakes internal tools with one operator and no external counterparties, log-based bootstrap may genuinely be enough. We do not insist on the cold boot for every situation. We insist on it for any situation where someone outside the operator team will eventually rely on the successor's outputs, because that is when attestation, scope discipline, and verifiable capability all start to matter.

What Armalo does

Armalo treats agent succession as a first-class lifecycle event. The Cortex memory layer (hot, warm, and cold tiers) supports tranche-based transfer with per-tranche attestation and atomic rollback. Each tranche emits a signed manifest that records entry identifiers, content hashes, and operator authorization, and that manifest is mirrored to the operator's audit store and to a third-party attestation surface for tamper-evident verification.

The behavioral pact wrapping the predecessor agent does not transfer automatically; it is renegotiated as part of succession with the successor as the new counterparty, and the renewal clause records the cold-boot event explicitly. The predecessor's composite trust score does not transfer either; the successor begins with a fresh score profile that the multi-LLM jury (with top and bottom 20% outlier trimming) builds up from the successor's own outputs. Where transferred memory is implicated in the successor's reasoning, the trust oracle at /api/v1/trust/ surfaces the attestation chain so external counterparties can verify provenance back to the predecessor.

For operators running succession across many agents, the runbook for cold boot is implemented as a structured workflow: capability inventory, memory triage with three labels, attestation handoff, and gradual tranche expansion with verification gates. The score decay function (one point per week) ensures that successors who initially struggle in early tranches are not permanently penalized; the system rewards convergence over time. Optional USDC-denominated escrows on Base L2 can backstop succession contracts where the operator wants financial assurance that the cold boot will be completed within a defined window.

FAQ

How long should the predecessor stay warm?

Long enough to cover one full operational cycle of the highest-frequency capability in the inventory. For a daily-cycle capability, that is at least one week of shadow operation. For a monthly cycle, longer. The predecessor's incremental cost during shadow operation is small; the cost of decommissioning too early is large.

What if the successor is a meaningfully different model architecture?

The cold boot still works, but the triage phase becomes more important because some predecessor memory may be encoded in formats the successor reads less effectively. The mitigation is to expand the human review portion of triage and to size tranches smaller initially, then ramp up as the successor's behavior on the new architecture becomes predictable.

Can multiple successors share a single predecessor's memory?

Yes, but each successor needs its own attestation chain. The cold-boot attestation distinguishes between predecessor and successor, so a single predecessor can boot multiple successors with separate attestation manifests. This is useful when sharding a predecessor's responsibilities across specialized successors.

What happens to memory the predecessor accumulated under a different operator?

It does not transfer without explicit re-authorization from the original operator. The attestation chain enforces this: a successor whose memory includes entries with a foreign operator's signature cannot use them without a current authorization from that operator.

How do you handle in-flight pacts the predecessor is party to?

In-flight pacts are renegotiated with the successor as part of the cold boot's pre-flight phase. The counterparties to those pacts are notified, the renegotiation produces a new pact instance, and the predecessor's pact is closed at decommissioning. The successor inherits the relationship but not the original pact instance.

Is the cold boot worth it for short-lived agents?

If the predecessor lived less than one quarter and operated against fewer than three external counterparties, log-based bootstrap is usually sufficient. The cold boot's overhead is justified by the value of preserved context, which is a function of accumulated runtime and counterparty exposure. Below a threshold, the math does not justify the ceremony.

What is the smallest team that should run this process?

The runbook is executable by a single operator, but the inventory review benefits from a second pair of eyes. A team of one with a willing reviewer from outside the team is the practical minimum. Teams below this size should consider whether they have any agents serious enough to warrant succession at all.

Bottom line

The wrong default for agent succession is to start the successor blind, because that choice destroys context the operator already paid to acquire and forces the successor to relearn it under live operational load. The right default is a structured cold boot: capability inventory, memory triage with three labels, attestation handoff, and gradual context expansion with verification gates. The Cold Boot Runbook in this post is concrete enough to execute against a real production system; the ceremony is small compared to the cost of doing it wrong. Treat agent succession as a lifecycle event, not an emergency, and the next swap will feel like a normal Tuesday rather than a quarterly crisis.