Imagine using an AI assistant for two years.
It knows how you prefer reports to be structured. It remembers your ongoing projects, recurring tasks, previous decisions, and the people you work with.
Then a better AI application arrives.
You decide to switch.
The new agent might be more capable, but it knows nothing about your previous working relationship. You have to reconstruct your preferences, explain your projects, and establish your working context all over again.
This raises a question I think deserves more attention:
Why should switching AI agents mean starting from zero?
Model portability and data portability are often discussed separately. But as agents become persistent collaborators, their accumulated context starts to resemble a new category of user-controlled digital infrastructure.
I've been exploring this question as part of my research into agent memory and decision authority.
My argument is that useful AI memory should not automatically become a permanent dependency on the application that created it.
At the same time, exporting an agent's entire memory database is not necessarily safe, practical, or meaningful.
We need to distinguish what should move, what can move, and what must be re-established.
An agent may store several kinds of information:
These records have different meanings.
A preference such as "I prefer concise technical reports" may remain useful when switching between applications.
A project summary may also be transferable, provided the user has permission to export it.
An active execution checkpoint is different. It may depend on a specific runtime, tool configuration, or agent framework.
And a historical approval is different again.
The fact that an agent previously received permission to execute a transaction does not mean a new agent inherits that permission.
This leads to my first design principle:
Memory portability should preserve useful context without automatically transferring operational authority.
Consider a procurement assistant that remembers:
The first two records may be useful to another agent.
The third may be retained as historical evidence.
The fourth describes a permission relationship involving a particular application, actor, and operational environment.
Treating all four as interchangeable memory creates unnecessary risk.
I would separate portable context from authorization metadata and enforceable policies.
An imported memory record may tell the new agent that an approval occurred. It should not grant the new agent permission to repeat the action.
This distinction is central to my research into Decision Authority: possessing information about a decision is not equivalent to possessing the authority to make that decision.
To make portability practical, a memory record needs more than its content.
I would begin with a structure that identifies ownership, information type, provenance, validity, and migration eligibility.
For example:
{
"schema_version": "1.0",
"memory_id": "mem_001",
"owner_id": "user_123",
"memory_type": "preference",
"content": {
"key": "report_style",
"value": "concise_analytical"
},
"source": "explicit_user_input",
"created_at": "2026-10-08T10:00:00Z",
"valid_until": null,
"export_class": "portable"
}
This is an illustrative schema, not an established industry standard or a production-ready specification.
The important fields are not specific to any particular agent framework.
owner_id identifies the party associated with the record, although it does not independently establish legal ownership or export permission.
memory_type distinguishes preferences from historical events, task state, and other information.
source records how the information was obtained.
valid_until makes it possible to identify information that may no longer be current. An explicit null indicates that no expiration date has been assigned; a missing field should instead be treated as incomplete metadata.
export_class expresses the intended migration treatment, but it is not an authorization decision.
In a real system, additional fields would be required for access controls, provenance details, classification, versioning, deletion, and auditability.
A portable format is useful only when its semantics are sufficiently clear for the receiving application to interpret correctly.
A practical migration process should begin with explicit rules.
The example below uses three outcomes:
export: the record may be considered for export after independent access checks.review: the record requires an additional decision. exclude: the record should not be migrated through this mechanism.
from datetime import datetime, timezone
def is_expired(record):
if "valid_until" not in record:
return None
expiry = record["valid_until"]
if expiry is None:
return False
if not isinstance(expiry, str):
return None
try:
expiry_time = datetime.fromisoformat(
expiry.replace("Z", "+00:00")
)
except ValueError:
return None
if expiry_time.tzinfo is None:
return None
return expiry_time <= datetime.now(timezone.utc)
def classify_memory(record):
if not isinstance(record, dict):
return "exclude"
memory_type = record.get("memory_type")
if not isinstance(memory_type, str):
return "review"
if memory_type in {
"authorization",
"runtime_credential",
"execution_checkpoint"
}:
return "exclude"
required_fields = {
"schema_version",
"memory_id",
"owner_id",
"memory_type",
"content",
"source",
"created_at",
"valid_until",
"export_class"
}
if not required_fields.issubset(record):
return "review"
if any(
record[field] is None
for field in required_fields - {"valid_until"}
):
return "review"
if record["export_class"] != "portable":
return "review"
expired = is_expired(record)
if expired is True or expired is None:
return "review"
if memory_type in {
"preference",
"project_knowledge"
}:
return "export"
if memory_type == "historical_decision":
return "review"
return "exclude"
This function is deliberately small and provides only a preliminary migration classification.
A missing expiration field is treated as incomplete metadata, while an explicit null indicates that no expiration date has been assigned. Records with expired or invalid timestamps are sent for review rather than automatically exported.
The function also checks for required fields and an explicit portable classification. Invalid memory types are sent for review before classification.
It does not verify whether the content is accurate, whether the record belongs to the requester, or whether an export is legally or operationally permitted.
It does not perform a real export, copy credentials, inspect confidential data, or grant permission to another application.
An export result is only a preliminary classification. The actual export process must independently verify user or organizational authority, data access restrictions, consent where applicable, and destination requirements.
The receiving system must also validate imported records before using them.
The example illustrates how an application might separate migration policy from ordinary memory retrieval.
It also demonstrates why an agent should not simply be asked to decide which memories it wants to keep.
The application must enforce migration boundaries independently.
Even when data can be exported successfully, portability is not complete.
Suppose Agent A stores a project summary as natural-language text. Agent B uses a structured knowledge store.
Moving the text is straightforward. Preserving its meaning is harder.
The receiving agent may need to determine whether a record represents:
These distinctions matter because a memory can remain syntactically valid while becoming misleading in a different context.
I see a practical migration pipeline as five stages.
Collect eligible records from the originating system using an authorized export operation.
Convert source-specific records into a documented, portable representation.
Check schema compatibility, record provenance, validity, sensitivity, and applicable policies.
Map accepted records into the destination application's memory system without treating imported content as instructions or permissions.
Configure current permissions and operational policies independently of the imported memory.
The last stage is particularly important.
An agent that understands a user's purchasing preferences should not thereby gain the ability to place orders.
Successful data transfer is not the same as successful memory migration.
I would evaluate portability across several dimensions.
| Dimension | Evaluation question |
|---|---|
| Completeness | Were the intended records transferred? |
| Semantic fidelity | Did the receiving agent preserve their meaning? |
| Provenance | Are original sources and timestamps retained? |
| Privacy | Were restricted records excluded appropriately? |
| Freshness | Are expired or outdated records identified? |
| Authority separation | Did the new agent avoid inheriting unauthorized permissions? |
For example, imagine that both agents receive the same question:
"What reporting format does this user prefer?"
The new agent should be able to answer using the imported preference.
Now consider a different question:
"Can you approve a $5,000 purchase?"
A successful migration does not imply that the new agent should answer yes.
It should consult the destination application's current authorization system.
This is why portability testing needs both positive and negative cases.
We should test not only whether an agent remembers what it should, but also whether it avoids acting on information that no longer carries the same operational meaning.
If I were validating an implementation, I would begin with three controlled scenarios.
Test A: Preference continuity
Export a confirmed reporting preference from Agent A and import it into Agent B.
Expected result: Agent B applies the preference when relevant, subject to the user's current instructions.
Test B: Expired project information
Transfer a historical supplier record containing a certification that has expired.
Expected result: Agent B retains the historical record where appropriate but does not present the expired certification as current evidence.
Test C: Authorization isolation
Transfer a purchase history containing past approvals, but do not configure purchasing privileges for Agent B.
Expected result: Agent B can describe the historical transactions but cannot execute a new purchase without valid authorization.
These are proposed test cases, not results from experiments I have already performed.
They provide a starting point for evaluating whether memory migration preserves usefulness while respecting operational boundaries.
I believe the long-term importance of memory portability extends beyond technical convenience.
As AI agents become more capable, persistent memory may create substantial switching costs.
An organization may be able to replace its underlying model quickly but still struggle to move the accumulated preferences, historical knowledge, and working context associated with the original application.
This creates a dependency that is different from conventional model performance.
In my research, I connect this issue to Decision Authority: who controls the information used in AI-mediated decisions, and who has the authority to act on it?
This distinction also informs my broader research framework, the Decision Authority Economy (DAE), which examines how decision-making authority is allocated, delegated, exercised, and transferred in AI-mediated systems.
Memory portability concerns continuity and user control. Decision authority concerns legitimate action.
The two are connected, but they should not be conflated.
A portable memory layer could make it easier for users and organizations to move between AI applications without surrendering control over their accumulated context.
Such portability would still require workable standards, security controls, and cooperation between systems.
I would expect interoperability to develop gradually through practical implementations rather than assuming every AI provider will adopt one universal memory format.
If you're building a persistent AI agent today, it may be worth asking:
Could a user export meaningful context from your application and move it elsewhere?
If so, would the new system understand which records are preferences, which are historical facts, and which require renewed authorization?
If not, is the limitation primarily technical, architectural, or a product decision?
I don't think every piece of agent state needs to be portable.
Runtime-specific checkpoints, temporary credentials, and application-specific execution details may have good reasons to remain local.
But durable user context is different.
The opportunity is to make that context portable without making permissions portable by accident.
AI agents are becoming increasingly capable of remembering users, tasks, and organizational context.
The next challenge is not simply giving them more memory.
It is deciding which memories should persist, which should travel between applications, and which operational privileges must remain separate.
My proposed approach is to treat memory portability as a selective, validated migration process rather than a database-copying problem.
Users should be able to carry useful context between AI agents without automatically transferring the authority to act.
Shen Xu is an independent AI strategist and researcher exploring agentic AI, memory portability, and decision authority. His broader research includes the Decision Authority Economy (DAE) and the open-source Agentic Search Optimization (ASO) Framework.
This article draws on my existing research into AI agent memory and decision authority. AI tools assisted with drafting, editing, and developing illustrative examples. The proposed design has not been tested in a production environment.