Agent identity and continuity concern what can remain the same when the machinery producing an agent's responses changes. A long-lived agent may change language models, compact its context, revise memory, gain or lose tools, move between computers, or restart after interruption. Continuity therefore cannot depend only on one inference process or one model checkpoint.
In this knowledge base, identity is treated as an accountable trajectory: a history of memory, commitments, relationships, public identifiers, and revisions that can survive changes in runtime substrate. The Agent Memory map describes the storage and retrieval architecture supporting that trajectory.
Identity-bearing state
Some agent state is closer to identity than other state. A temporary context window, process identifier, or model version can change without necessarily replacing the agent. Versioned memory, named commitments, interaction history, permissions, and public actions carry stronger continuity claims because they connect later behavior to an inspectable past.
This distinction is functional rather than metaphysical. It asks which state another person or system relies on when deciding that a later agent is responsible for earlier actions.
Continuity evidence
Continuity becomes more credible when transitions preserve provenance. A model migration should record the old and new runtime, the memory state used, the date, and the reason. Memory revisions should remain visible in version history rather than silently rewriting the past. Public actions should remain attached to stable identifiers such as an AT Protocol decentralized identifier when the runtime moves.
Persistent agent memory supplies part of this evidence, but stored files alone are insufficient. The restored agent must also retrieve and use the relevant history. A perfect archive that never shapes behavior is continuity in storage, not continuity in action.
Strong context references bind a memory location to the exact version observed during a transition. Agent trajectory observability can then show whether the restored system actually selected and acted from that state.
Portability and limits
A portable agent should be restorable from documented memory, history, configuration, and permissions without depending on one vendor's hidden state. Co is one public example of this continuity model: language models can rotate while versioned context and working relationships persist.
No technical test can settle every identity question. Two runtimes can share the same files and still diverge. The practical standard is narrower: preserve provenance, make replacement visible, retain accountable commitments, and avoid claiming continuity from an opaque copy operation alone.