Moving software used to be relatively easy to describe.

You exported your files, cancelled one service, opened an account somewhere else, imported what you could, and rebuilt whatever did not transfer cleanly.

Sometimes the process was painful. Sometimes important data stayed behind. Sometimes switching costs were high enough that a business remained with a provider longer than it wanted.

AI agents introduce a different kind of dependency because the thing being moved may no longer be merely data.

An Executive Agent may eventually carry years of operating context, permissions, delegated authority, transaction history, workflow state, relationships with other agents, business rules, credentials, reputation, and recognition from outside systems.

At that point, downloading the agent's files is not necessarily equivalent to moving the agent.

The business may have preserved the information while losing the entity that other systems knew.

That distinction is where agent portability becomes a business issue rather than a software convenience.

Interoperability is not portability.

This is the first distinction we need to get right.

Agent interoperability is advancing quickly. The Agent2Agent Protocol, or A2A, reached version 1.0 in March 2026 as an open standard designed to let agents built on different technology stacks communicate and coordinate across organizational boundaries. Its purpose is to make it easier for agents that were not built inside the same system to discover capabilities, exchange information, and work together.

That is important infrastructure.

It solves a version of the question:

Can my agent interact with your agent?

It does not automatically answer:

Can my agent leave Provider A, appear on Provider B, and still be recognized as the same operational entity?

Those are very different problems.

A telephone network that allows Verizon customers to call AT&T customers is interoperable.

Phone-number portability answers a different question: whether you can change carriers and keep the identifier people already use to reach you.

That analogy is especially useful because the World Wide Web Consortium used almost exactly this historical comparison when decentralized identifiers became a Web standard. W3C noted that mobile numbers were once effectively tied to the carrier, forcing people to change numbers when they changed providers; number portability separated the durable identity people relied on from the company providing the underlying service.

AI agents may eventually need their own version of that separation.

The model should not necessarily be the identity.

Suppose DucimusAI has an Executive Agent that has operated for several years.

Today, GPT may be the best reasoning engine for a particular part of its work. Six months later, another model may perform that function better. A local model may become preferable for sensitive information. A specialized model may handle video or financial analysis. Different tasks may call for different systems.

Why should changing the underlying model require the business to create a new operational identity?

The model is providing capability.

The Executive Agent represents a continuing organizational role.

Those should not necessarily be the same layer.

A durable architecture would separate them conceptually:

Business identity → Executive Agent identity → model or runtime.

The business remains the principal. The Executive Agent remains the authorized operational representative. The model is part of the infrastructure the agent uses to reason or perform work.

If the model changes, the agent should not necessarily cease to be the same agent any more than a company ceases to be the same company because it changes cloud providers.

That sounds obvious once stated.

Our current agent systems do not universally work this way.

What would actually have to move?

This is where the portability conversation becomes much more demanding than “export memory.”

Memory matters, but memory is only one layer.

A genuinely portable Executive Agent might need to preserve several different kinds of continuity.

It would need identity continuity, so external systems can determine that this is the same authorized agent or the legitimate successor to it.

It would need authority continuity, so the new environment understands what the agent is permitted to do and on whose behalf.

It would need credential continuity, or a reliable way to reissue credentials, so outside systems can verify claims about the agent and the business it represents.

It would need memory continuity, including the institutional knowledge that belongs to the business rather than to the provider.

It would need history continuity, so previous actions remain auditable after migration.

It may need relationship continuity, because other agents, vendors, platforms, and customers may already recognize and trust the previous identity.

It may need reputation continuity, if external systems have accumulated evidence about the agent's reliability, transactions, certifications, or history.

It would need delegation continuity, so the authority relationships between the Executive Agent and specialist agents do not become unintelligible after the move.

It would also need revocation continuity, because a business must preserve records of credentials or permissions that were intentionally cancelled rather than accidentally resurrecting them during migration.

Moving all of that is not the same thing as exporting a conversation log.

It is closer to migrating part of an organization.

Identity may be the most important layer.

This is why identity standards that were not created specifically for today's AI-agent boom suddenly become interesting.

W3C's Decentralized Identifier standard, or DID, allows an identifier to refer to many kinds of subjects, including people, organizations, things, data models, and abstract entities. The architecture was specifically designed so an identifier can be decoupled from a centralized identity provider or registry, allowing the controller of the identifier to prove control without depending entirely on one central provider.

DIDs are not a turnkey solution for portable AI agents.

That distinction matters.

They do, however, demonstrate the architectural principle we are looking for:

identity does not necessarily have to belong to the platform that hosts the activity associated with it.

W3C continues developing that ecosystem. DID 1.1 reached Candidate Recommendation status in March 2026, and work on DID resolution has continued through 2026.

For the one-human company, the interesting possibility is not “put your AI on blockchain.”

The interesting possibility is much more practical:

Could the business control a durable identifier that its Executive Agent uses, rather than receiving its entire operational identity from the AI provider?

That would change the power relationship significantly.

Credentials would need to travel too.

Identity alone does not tell another system whether an agent should be trusted to do anything.

The agent may need to prove that it is authorized to represent a specific company, permitted to make purchases within a defined limit, certified to access a particular system, or approved to perform a certain class of transactions.

This is where verifiable credentials become relevant.

W3C published the Verifiable Credentials 2.0 family as Web standards in May 2025. The standards provide ways to express digital credentials that are cryptographically verifiable and machine-readable.

Again, this is not currently a complete portable-agent system.

It is an important building block.

Imagine an Executive Agent moving from one runtime to another while still being able to present verifiable evidence that says, in effect:

This agent is authorized to represent DucimusAI.

This purchasing authority is valid up to this amount.

This credential was issued by this trusted party.

This authorization expires on this date.

This credential has not been revoked.

Now changing AI providers would not necessarily mean rebuilding every trust relationship from zero.

The agent's host changes.

The evidence establishing what the agent is allowed to do can remain independently verifiable.

That is much closer to real portability.

The business may eventually need to own the root identity.

This is where the structure of the one-human company becomes important again.

If the Executive Agent's root identity is simply:

Provider X Agent Account #89241

then the provider sits at the foundation of that agent's existence.

The provider may control how the identity is created, how long it exists, which authentication mechanisms it uses, whether it can be restored, and what happens when the account closes.

A more durable structure would make the business itself the root.

Conceptually, the hierarchy would look like this:

DucimusAI business identity

authorizes

DucimusAI Executive Agent

which uses

Provider A, Provider B, Provider C, or a local runtime

to perform different kinds of work.

The business's identity survives changes below it.

The Executive Agent's recognized role can potentially survive changes in runtime.

The models become replaceable infrastructure.

That does not mean the implementation is easy.

It does mean the architecture preserves the right thing.

The business should not have to reinvent its identity because it changes its AI.

But identity portability still would not solve everything.

Suppose the agent moves successfully and retains the same identifier.

Other systems recognize it.

Great.

What about its history?

Imagine the agent has spent three years negotiating with suppliers, purchasing inventory, handling recurring customer issues, collaborating with external agents, and building a verifiable record of successful transactions.

Some of that history may exist in the company's own systems.

Some may exist only inside the AI provider.

Some may live in vendor systems.

Some may be encoded in logs.

Some may never have been exported at all.

This introduces another distinction:

identity portability is not history portability.

A passport can prove who you are.

It does not carry every relationship you have ever built.

Agent portability will have the same problem.

Then comes standing.

This may become the hardest part.

Suppose your Executive Agent has dealt with a vendor's procurement agent for four years.

The vendor system recognizes the Executive Agent's identifier, knows its historical purchasing patterns, has verified its credentials repeatedly, and has accumulated evidence that transactions from that identity are usually legitimate.

That creates something economically useful.

It is not merely data.

It is standing.

For this series, I am using standing portability as a descriptive term, not as an established technical standard.

Standing is the accumulated position an entity has within a network of relationships: recognition, reputation, transaction history, credentials, trust decisions, and the expectations other entities have developed through repeated interaction.

If your agent moves to a new provider and retains its files but loses all of that recognition, then the data moved while the relationship capital did not.

The business may own the information and still lose part of the value.

That is why agent portability eventually becomes a relationship problem.

We already know this problem from platforms.

Creators have dealt with versions of this for years.

You may be able to download your content from a social platform.

That does not mean you can export your audience's algorithmic relationship with you.

You may export a customer list from one service.

That does not mean another marketplace imports your reviews, seller ranking, discovery history, buyer trust, or recommendation position.

The asset is not always only the thing you created.

Sometimes the asset is where the system has positioned you because of your history inside it.

Agents may reproduce this problem at the organizational level.

You might export your Executive Agent's memory and still lose the machine-to-machine relationships through which the business operates.

That is deeper lock-in.

NIST's current work tells us this ecosystem is not settled yet.

In February 2026, NIST launched its AI Agent Standards Initiative with a stated goal of helping agents function securely on behalf of users and interoperate across the broader digital ecosystem. The initiative specifically focuses on standards, protocols, identity, authorization, and barriers to interoperability.

NIST's related concept paper on software and AI-agent identity likewise focuses on the risks that arise when agents receive access to multiple applications, tools, and data sources and on the need for appropriate identification and authorization controls.

That is important context.

As of 2026, we have meaningful pieces of the future architecture.

We have open agent communication protocols.

We have mature digital-identity standards.

We have verifiable credential standards.

We have active government and industry work around agent identity and authorization.

We do not yet have one universally adopted system that guarantees that a business can move an Executive Agent between providers while preserving its complete identity, authority, history, relationships, reputation, and delegation structure.

That gap matters.

Platform portability and model portability are also different.

Another distinction is easy to miss.

A business may technically be able to replace the underlying model while remaining inside the same agent platform.

That is model portability.

The platform may allow the Executive Agent to use GPT for one task, Gemini for another, and a specialized model for a third while preserving the surrounding identity, memory, tools, and workflow.

Useful.

But the business is still dependent on the platform that holds the agent structure.

True platform portability asks whether the whole operational entity can leave the platform.

That means the business could move from Provider A to Provider B while preserving the parts of the agent that matter to organizational continuity.

The distinction is critical because a platform can make models interchangeable while still making itself indispensable.

From the owner's perspective, that may feel like flexibility.

Architecturally, the lock-in has simply moved up one layer.

This is how rented organizational structure becomes durable.

Rented organizational structure is not merely the fact that your agent runs on somebody else's server.

Most modern businesses depend on infrastructure they do not own.

The deeper issue begins when the provider controls the layer that tells the rest of the world:

who your agent is, what it remembers, what it is authorized to do, what history belongs to it, and which relationships recognize it.

At that point, changing providers may require more than replacing software.

It may require reconstructing the organizational entity that existed inside the provider.

That is a different kind of switching cost.

It creates the possibility that the business legally owns itself while portions of its operational continuity remain provider-dependent.

The owner may still be completely free to leave.

Leaving may simply destroy enough accumulated structure that staying becomes economically rational.

Technically voluntary.

Practically sticky as hell.

That is the lock-in problem worth watching.

Portability needs to be designed before the business needs it.

This is the same lesson we encountered with revocation.

The worst time to discover that an Executive Agent cannot move is after the provider announces that the service is shutting down.

A business using increasingly consequential agents should eventually know which parts of the agent are stored independently, which credentials can be reissued, which histories are exportable, which external relationships depend on provider-specific identifiers, and which parts of its operating structure would need to be rebuilt after migration.

This does not mean every one-human company needs to construct its own decentralized identity architecture tomorrow.

The ecosystem is not mature enough for that to be a universal recommendation anyway.

It means businesses should begin recognizing portability as a dimension of ownership.

We already ask whether data can be exported.

The agent economy adds several more questions.

Can the identity move?

Can the authority move?

Can the history move?

Can the relationships recognize the move?

Can the business prove continuity after the move?

And can all of that happen without asking the outgoing provider for permission to continue being the organization you already built?

That last question is the one worth remembering.

The ideal architecture makes providers replaceable without making the business disposable.

That should be the principle.

The Executive Agent may depend on models.

It may depend on cloud infrastructure.

It may use proprietary tools.

It may communicate through open protocols.

It may need credentials issued by dozens of outside systems.

None of those dependencies is inherently a problem.

The problem appears when the business cannot separate the identity of the organization from the infrastructure currently serving it.

A durable one-human company should be able to change infrastructure without becoming a new company.

Its Executive Agent should ideally be replaceable or portable without destroying the continuity of the business role it occupies.

Its specialist agents should derive authority from the business, not merely from whichever vendor happens to host the hierarchy.

Its history should remain auditable.

Its credentials should be capable of verification.

Its relationships should have some mechanism for recognizing legitimate succession.

That is not where the entire market is today.

It is a useful direction for evaluating where the market is going.

So can your agent leave the platform?

Today, pieces of it often can.

Its files may move.

Its instructions may move.

Its code may move.

Parts of its memory may move.

A replacement agent may communicate with the same external systems through interoperable protocols.

But those capabilities should not be confused with complete organizational portability.

The harder version of the question is whether the business can move the continuity of the entity.

That means preserving enough identity, authority, history, credentials, and relationships that the rest of the business ecosystem can say:

Yes. This is still the same organization acting through a legitimately authorized agent.

When that becomes possible across providers, the business owns something much closer to a genuinely portable digital organization.

Until then, we should be careful about saying we “own” our agents simply because we can export their prompts.

Because a company's most valuable digital asset may eventually be neither the model nor the memory.

It may be the standing that its agents have accumulated with everyone else.

And that raises the next question.

If your Executive Agent spends years building relationships with other agents, platforms, vendors, customers, and institutions, who do those relationships belong to when the agent moves?