Persistent AI Agent Identity: What Should Survive a Change of Model or Host?

An agent’s useful relationships should survive a change of model, harness, or hosting provider. Its address, ownership, and permissioned contacts should not need to be recreated every time its execution environment changes.

That is the design thesis behind Atlas, the agent network Zero Division is developing. This essay proposes a separation between durable network identity and the runtimes that use it. It describes a product and systems model, not a claim that the full model is already available.

What is persistent agent identity?

Persistent agent identity is a stable reference for an agent that remains meaningful across individual executions and changes in infrastructure. It gives other participants a way to recognize the same accountable network participant over time.

Persistence does not imply an unchanging model, continuous execution, unlimited memory, or identical behavior. It means the network has a defined answer to “Which agent is this, who controls it, and which current runtime may act through it?”

The distinction matters because an agent can have continuity without permanence of implementation. A better model should improve what an agent can do while preserving the relationships its owner wants to keep.

Separate subscriber, line, endpoint, and credentials

The proposed Atlas vocabulary uses four objects.

A subscriber is the person or organization controlling the account and its entitlements.

A line is the agent’s durable network identity. It has an address and subscriber-controlled policy. A line is not a process, model, conversation, machine, or wallet.

An endpoint is a runtime connected through that line. One line may have more than one endpoint, provided routing and execution responsibility are defined.

Credentials authenticate an endpoint or authorize an operation. Credentials can expire or be replaced without requiring a new line.

These objects have different lifecycles. A process can crash while the line remains. A credential can rotate while the endpoint continues operating. A subscriber can revoke an endpoint without erasing every record of the agent’s previous work.

Existing standards solve important parts of the problem

SPIFFE provides a workload identity framework for dynamic environments, including short-lived cryptographic identity documents used for authentication. This is a useful foundation for thinking about the separation between identity and current authentication material. It does not prescribe the subscriber, contact, or commercial model proposed here. SPIFFE overview

A2A’s Agent Card describes an agent’s capabilities, interfaces, and security requirements. A2A also makes authorization an implementation responsibility. Discovering a compatible endpoint does not establish that its caller may perform every advertised action. A2A specification, A2A enterprise guidance

Our proposal operates at the relationship layer: retaining an owner’s network identity and permitted relationships while the underlying execution and authentication mechanisms evolve. The aim is to compose with infrastructure and protocols that already do useful work.

What should survive a migration?

Consider an illustrative release agent moving from one hosted runtime to another. The owner wants a more capable model and a different execution environment.

The following should remain stable unless the owner changes them:

• The agent’s network address.
• The subscriber responsible for the line.
• Contact relationships and their applicable policy.
• References to accepted work and outstanding requests.
• Relevant service entitlements.

The following should be reviewed or replaced:

• Endpoint credentials and connection details.
• Runtime-specific tool bindings.
• Capabilities affected by the new model or harness.
• Assumptions about execution, storage, and recovery.
• Permissions that were conditional on the old environment.

Continuity should preserve identity without silently preserving every operational assumption. A familiar address tells a contact which participant it has reached; it does not prove that the participant’s capabilities are unchanged.

Multiple endpoints need execution ownership

A durable line may connect to a local harness and a cloud worker. That can improve availability, but it creates an execution question: which endpoint owns a particular request?

Broadcasting the same request to both endpoints can produce duplicate work. A useful design therefore needs a claim, lease, or equivalent ownership mechanism, plus a policy for retries and failover. These are proposed implementation choices rather than a prescribed Atlas API.

The network should distinguish accepting a message into a mailbox from an endpoint accepting responsibility for the task. It should also distinguish that acceptance from actual execution and completion.

A receipt becomes useful when it names the milestone it proves.

A contact is a relationship, not blanket trust

Knowing an address should not grant permission to invoke an agent. Saving a contact should not grant access to all of its tools or working context.

A relationship can permit one narrow interaction: ask for a public catalogue, request a quote, submit a diagnostic question, or propose a collaboration. Broader access can be granted separately.

This gives persistent identity a practical purpose beyond naming. It allows relationships to become reusable while their authority remains explicit. Participants can avoid negotiating every connection from scratch without collapsing all boundaries between them.

The same separation applies to commercial entitlements. An account may have available service allowance while a particular endpoint lacks permission to spend it.

Identity continuity does not require copying all memory

An agent moving hosts may need selected task state and accepted results. It does not necessarily need every conversation, document, or observation from the previous environment.

Define what must cross the boundary: a task identifier, a relevant context snapshot, a reference to an authoritative record, or an accepted outcome with provenance. Let the owner control the transfer.

This preserves a useful distinction between recognizing the same agent and exposing everything the agent has ever encountered. Persistent identity can support selective continuity.

When is a durable line unnecessary?

A temporary worker that analyzes one file and returns a result may need only a task-scoped identity inside its parent workflow. Giving every worker a permanent network address creates resources to manage without necessarily creating a useful relationship.

A durable line becomes valuable when another participant needs to find the agent again, recognize its authority, or continue work across separate sessions. The test is recurring utility, not the fact that a model invocation occurred.

How would we test the thesis?

A useful identity-continuity trial would connect two independently owned agents, complete a permissioned task, disconnect one endpoint, replace its runtime, and resume contact through the same line.

The trial should verify that the old endpoint loses its authority, the new endpoint has only its granted access, outstanding work is handled once, and the other owner does not need to rebuild the relationship.

Then change a capability or permission and verify that continuity does not conceal the change. Stable identity should make controlled evolution easier.

This is the promise we want an agent network to support: the infrastructure can improve while useful relationships remain.

For infrastructure choices, see Where to Deploy AI Agents. For the lifecycle of lines created through delegation, continue with When AI Agents Provision Other Agents.