The decommissioning problem

When an AI agent system is shut down, the most natural assumption is that its obligations end with its operation. The agent stops acting; its audit trail is archived; the team that built it moves on. But accountability is not a function of whether a system is running. It is a function of whether consequences from its past actions remain in the world — and those consequences do not stop existing when the agent does.

This is the decommissioning problem. It is not a technical problem in the narrow sense; it is a governance problem that surfaces the moment anyone asks what happens to the accountability obligations a system accumulated while it was alive. The answer, in most current deployments, is that those obligations dissolve. The system is gone. The records may or may not be accessible. The people who understood it may have dispersed. A claim against a decommissioned agent has no obvious address.

What decommissioning destroys

Three categories of accountability infrastructure are at risk when an agent system is shut down. The first is evidentiary: audit logs, decision records, and the context required to interpret them. Archiving logs is necessary but not sufficient. A log entry that says "action taken at 14:32:07" is uninterpretable without the model version, the input context, the active permissions, and the downstream systems that were invoked. Decommissioning that preserves logs but discards the interpretive context has preserved the form of the audit trail while destroying its function.

The second is cryptographic. If an agent used signing keys to attest its decisions — a design feature that makes audit trails tamper-evident — those keys have a custody question at decommission. Keys that are destroyed at shutdown cannot be used to verify historical decisions. Keys that are retained indefinitely create their own risks. The decommissioning moment requires a deliberate key custody plan, not a default of either destruction or retention.

The third is relational. An agent system typically operates inside a web of integrations: APIs it called, systems it updated, human workflows it was embedded in. Those relationships do not terminate when the agent does. A downstream system that received outputs from a now-decommissioned agent may continue acting on them for years. The accountability chain does not end at the agent's last action; it extends forward through every downstream consequence that followed.

At the post-quantum crossing

The cryptographic dimension of the decommissioning problem is sharpest at the intersection with post-quantum security. An agent that signed its decisions using algorithms now considered vulnerable presents a retroactive integrity problem: past decisions, even if correctly logged, cannot be verified by any future party. The audit trail exists, but the ability to trust it has expired.

This creates a specific obligation at decommission time: transitioning signing keys to post-quantum algorithms before shutdown, not after. A system that is decommissioned with legacy signatures on its historical records has left those records in a state of future unverifiability. That is not a technical detail. It is an accountability failure — one that may not be visible for years, until someone needs to reconstruct what the system actually decided and discovers that the chain of trust has broken.

The inverse problem also applies. If a decommissioned system's historical records are re-signed under new algorithms at decommission time, the re-signing event itself must be attested. The record of "this signature was migrated from algorithm A to algorithm B on this date, by this authority" is itself part of the audit trail. Missing it collapses the evidentiary chain in a different way.

At the hardware crossing

Agents that ran on dedicated hardware — secure enclaves, hardware security modules, trusted execution environments — leave a specific decommissioning residue. The hardware may be repurposed, resold, or destroyed. Each path has different implications for what it leaves behind and what it destroys.

Repurposed hardware carries the risk of unintended data persistence. Keys, partial logs, and model artefacts that were not explicitly cleared may survive the transition to a new purpose. The new system inherits a ghost of the old one — not operationally, but evidentiary. Resold hardware amplifies this risk by moving it outside the original operator's control. Hardware destruction eliminates the persistence risk but also eliminates any remaining cryptographic material that future accountability claims might need.

None of these outcomes is automatically correct. The right decommissioning path for hardware depends on what accountability obligations the system accumulated, how long those obligations last, and who holds the authority to make the custody decision. A hardware decommissioning procedure that doesn't begin with an accountability audit is guessing at the right answer.

In physical-world care

The decommissioning problem takes its most consequential form in physical care settings. An agent that managed care decisions — monitoring, scheduling, escalation, medication management — accumulates accountability obligations that run on biological timescales, not system lifecycles. A patient whose care was shaped by the agent's decisions may have health outcomes that unfold over years. If something goes wrong, the accountability investigation will need access to what the agent decided, why it decided it, and what its operating state was at the time.

Care accountability obligations are also legally structured in ways that most agent systems are not designed around. Medical records retention requirements vary by jurisdiction and often extend for years or decades after the care episode ends. An agent that contributed to medical decisions was, in a functional sense, part of the medical record. Its decommissioning needs to be coordinated with the retention obligations that apply to the records it generated — not just the records it logged for its own audit trail.

The handoff problem at decommission in care is especially acute. If a care agent is being replaced by a successor system, the successor needs to understand not just the current state of care but the history of decisions that produced that state. A decommissioning plan that does not include a structured handoff to the successor — or to human carers who will absorb the work — has introduced a discontinuity into the care record that may never be fully reconstructed.

What a decommissioning plan requires

Decommissioning should be treated as a first-class accountability event, not a cleanup task. This means several things in practice.

Before shutdown, an accountability audit should document what obligations the system accumulated, how long they last, and who inherits them. This is not a technical audit of system state; it is a governance document that maps accountability to surviving entities. The organisation that deployed the system does not necessarily shed accountability when it turns the system off. The decommissioning plan should be explicit about what remains.

Log preservation must include interpretive context, not just raw records. The goal is not to store bytes; it is to preserve the ability of a future investigator to reconstruct what happened. That requires model version records, input context schemas, active permission states at decision time, and documentation of any known system anomalies during operation. A log without context is archaeology, not accountability.

Cryptographic continuity requires a key custody decision before shutdown. If the system signed its decisions, the signing material needs a plan: migrate to post-quantum algorithms before shutdown, establish a long-term custody arrangement, and record the migration event as part of the audit trail. Destroying keys at shutdown is a choice with permanent consequences for future verifiability. It should be made deliberately, not by default.

Downstream notification should reach every system and workflow that received outputs from the decommissioned agent. Those systems need to know that the source of those outputs no longer exists, that the outputs cannot be refreshed, and that any accountability questions about past outputs must be directed to the archival record rather than a live system.

The decommissioning problem is ultimately a reminder that agent systems are not bounded by their runtime. They extend forward through their consequences and backward through their records. A decommissioning plan that treats shutdown as the end of the accountability story has misunderstood where the story ends.