Look at what actually travels in these portability formats. System prompts. Tool schemas. Model preferences. Persona definitions. Constraints. Everything a developer authored before the agent ever ran a single task. And look at what stays behind: runtime state, memory, live context, credentials. The documentation across these projects is remarkably consistent on this point. Context management belongs to the deployment environment, not to the portable definition.

Honest engineering. But the assumption underneath it is worth spelling out: the agent is its authored instructions. Everything else is environment.

What accumulates between the instructions

Anyone who has operated automations at scale recognizes the gap immediately. A system that runs repeatedly against real-world surfaces accumulates things. Session memory. Learned patterns about how a particular website behaves on Tuesdays versus Fridays. OAuth tokens and API credentials tied to specific services through specific trust relationships. Behavioral adaptations tuned to an environment's quirks, its rate limits, its authentication flows, its particular flavor of inconsistency.

None of that is in the export file.

Memory is where this gets tangible. Whether it's locked inside a parent framework or offloaded to an external service, memory doesn't travel with the agent definition. It either can't leave or it lives somewhere else, accessed through yet another authenticated connection that also doesn't port. Authorization credentials across every major agent framework live as environment variables, tied to the deployment, absent from the definition.

So when you "move" an agent, what shows up on the other side is a set of instructions with no memory, no credentials, no trust relationships, and no context. A system with the right instructions and none of the experience. Teams that discover this mid-migration watch a system that had been reliably handling edge cases for months suddenly behave like day one. Every learned adaptation, gone. Every session, a blank slate. One framework's creators described the result plainly:

Containers learned this the hard way

The container ecosystem went through the same recognition. Docker's original design assumed statelessness. Define the image, spin it up anywhere, destroy it when done. Then people tried to run real applications. The industry spent years building StatefulSets, PersistentVolumes, and a whole taxonomy of state-management primitives because it turned out that all applications have state. State always existed; the design choices were about who managed it and where it lived.

When a stateful container crashed and restarted without state awareness, users had to re-authenticate from scratch. The application was technically identical, and it didn't matter. The session was gone.

The blueprint and the building

The portability tools are drawing a clean, visible line between what they can carry and what they can't. That line is useful. An agent's authored logic is a starting point. The situated context it builds through operation, the memory, authorization, trust, behavioral adaptation, is what makes a working agent that particular agent. And those are the things that don't serialize.

The ecosystem is investing heavily in making the portable parts more portable. Memory systems and authorization state, meanwhile, are being built in parallel with no connective tissue between them. Nobody is working on the problem of porting what an agent has become.

The container world eventually built infrastructure to treat state as a first-class concern. The agent portability tools are quietly demonstrating something similar: agents accumulate identity through operation. The export file captures the blueprint. The agent is the building, its tenants, and every pipe that's been rerouted since opening day.