The succession problem: accountability when the organization responsible for an AI agent changes

The standard accountability model for AI agents assigns responsibility to a deploying organization: a legal entity with obligations, insurance, regulatory standing, and staff who can be questioned. When something goes wrong, accountability flows along a chain from the agent's action to the organization that deployed it. This model assumes the deploying organization still exists when accountability is needed. In practice, that assumption fails more often than accountability frameworks anticipate. Organizations are acquired, restructured, outsourced, and dissolved. AI agents deployed in the prior organizational form continue running in the new one. The accountability chain designed for the old entity does not automatically transfer to the new.

The succession problem is distinct from the decommissioning problem, which concerns how an agent is retired at end of life. Succession occurs while the agent is still active: the principal that commissioned it, controls its authorization policy, holds its audit logs, and is liable for its actions has changed — but the agent has not. From the agent's perspective, nothing has changed. It continues operating under the same configuration, serving the same functions, generating the same log entries. From an accountability perspective, the responsible entity at the time of deployment may no longer have any relationship to the responsible entity at the time consequences manifest. The gap between them is the succession problem.

At the post-quantum security crossing

Cryptographic accountability depends on persistent organizational identity. Root keys, signing authorities, and key escrow arrangements are established under the authority of specific legal entities with specific regulatory standing. When an organization is acquired or restructured, those arrangements do not automatically transfer to the acquiring entity. The original signing authority may no longer exist. The staff who held key management responsibilities may have left. The regulatory relationships that gave the original accountability claims their force — their standing to assert that cryptographic operations were conducted in compliance with a specific regime — may be held by an entity that no longer controls the agent.

This creates a gap that post-quantum signatures cannot close. A signature proves that a key was used; it does not prove that the organization currently responsible for the system authorized the key's existence under procedures that remain in force. During a post-quantum migration, where the entire accountability value of new algorithms depends on chains of properly established trust, an organizational succession that goes unrecorded in the cryptographic accountability architecture can break the chain at its root. The acquiring organization may find itself operating cryptographic infrastructure whose full accountability provenance traces to an entity it cannot compel to produce records.

At the hardware crossing

Hardware security accountability depends on persistent relationships with specific vendors, certification bodies, and regulatory registrars. When a hardware vendor is acquired, support obligations, firmware signing authorities, and attestation certificate hierarchies may change hands in ways not immediately visible to the agent's deployer. A device fleet whose attestation validity depended on a certificate hierarchy issued by a vendor that has since been absorbed may find that renewal paths are unclear, that the new parent organization's signing infrastructure is different, or that regulatory certification transfers require additional steps that were not anticipated.

The agent operating that hardware fleet experiences no operational discontinuity. Its attestation calls continue to return valid results against its existing authorization profile. What has changed is the accountability relationship between those results and the organizations that must answer for them. If a hardware security incident later requires reconstruction of the full accountability chain — who certified this hardware, who maintained it, who was responsible for vulnerability disclosure — the organizational succession creates gaps that engineering records alone cannot fill. Accountability for a hardware fleet spans the entire chain of vendor relationships from manufacture through operation, and organizational changes anywhere in that chain can make the chain untraversable when it is needed.

At the physical-world care crossing

Care agents operate under ongoing obligations to the people they serve. Those obligations are held by the deploying organization — typically a healthcare provider, care technology vendor, or both. When that organization changes, the obligations do not disappear, but the entity responsible for honoring them does. A care technology vendor acquired mid-deployment may have a new parent organization that has not been introduced to the patients the agent serves, has not established the regulatory relationships required to operate in the relevant jurisdiction, and has not reviewed the care agent's authorization policy under its own risk and compliance framework.

The patients served by the care agent may not know the responsible organization has changed. The agent continues its scheduled interactions, generates its logs, and escalates its alerts to care coordinators whose organizational relationships may themselves have shifted. When an adverse outcome occurs and accountability review begins, the investigation must reconstruct not just what the agent did but who was responsible for its governance at every point in its operation — and the answer may be different at different points in the timeline. Accountability continuity in care settings requires that organizational succession be treated as a clinical governance event, not merely a commercial transaction.

The succession gap and its structural remedy

The succession problem is not solved by contract. Acquisition agreements routinely include clauses transferring liability for existing deployments, but legal liability transfer is not the same as accountability architecture transfer. The acquiring organization may hold legal responsibility without possessing the operational knowledge, staff expertise, regulatory standing, or access to historical records needed to exercise that responsibility. The accountability chain is not a legal claim. It is a body of documented practices, standing relationships, and institutional knowledge that allows accountability to be discharged in practice, not merely assigned on paper.

The structural remedy requires treating organizational succession as a first-class event in an AI agent's accountability record — equivalent in significance to a software update or a major configuration change. At the moment of succession, the accountability architecture should produce a succession record: a structured snapshot of the agent's authorization policy, key material provenance, hardware certification status, open obligations, and known risks, transferred explicitly to the succeeding entity with documented acknowledgment. The succeeding organization's acceptance should be conditional on its review of that record and its attestation that it has the capability to discharge the obligations it is assuming. Without this, succession is an accountability void disguised as a routine business transaction. At all three crossings, agents with long operational lifetimes will outlive the organizations that created them. That is not a failure mode to be managed after the fact — it is a design condition to be anticipated from the start.