A website is not the browser that renders it. A package is not the machine that runs it. Why, then, is every AI agent fused to the chat session that executes it?
Today, every useful AI agent is trapped inside the place where it runs. Custom GPTs live inside OpenAI. Claude Projects live inside Anthropic. Local agents live on one developer's machine. Framework agents are bound to one orchestration workflow. The agent's instructions, memory, and accumulated intelligence are all welded to the execution environment. End the session, switch tools, lose the vendor, and the agent disappears.
The industry has spent years making agents smarter. Nobody is working on making them durable.
Useful agents are trapped in the wrong place
This is not a feature gap on any one platform. It is structural: every major agent platform assumes that the agent and its runtime are the same thing.
Custom GPTs live in OpenAI's infrastructure. Instructions go in a vendor textbox. Memory sits in vendor-controlled storage. The model is whatever OpenAI routes to that day. Switch to another tool and the agent stays behind, along with everything it learned. Claude Projects work the same way, just inside Anthropic's walls. Cursor rules sit on one machine; move to a new laptop and the agent starts over. Framework-based agents are bound to whichever orchestration system runs them.
Software solved this decades ago. Code lives in repositories. Packages live in registries. Configuration lives in infrastructure-as-code. Every other production artifact learned to separate durable state from ephemeral execution. Agent intelligence is the last one that hasn't.
So what, exactly, needs to separate? And what breaks when it doesn't?
We ran into this building our own engagement agent earlier this year. The instructions lived as versioned, published files on a remote layer. Accumulated context lived in persistent storage the agent could read and write across sessions. The local setup was twenty lines, a thin config file that fetched the real agent at runtime. Two operators ran the same agent from different machines. When an instruction improved, both got the update immediately. Nothing lived on either machine except the execution environment.
The architecture wasn't planned. It fell out of a practical need: two people needed to run the same agent without emailing files back and forth. But the consequence was structural, and it pointed at something the ecosystem is still mostly ignoring.
Five things die every time the session ends
This is not abstract. Five specific things vanish when the session ends, and each one matters more than it looks.
Instructions. How the agent thinks and behaves: its methodology, heuristics, voice, operational logic. Today these live in system prompts, project configs, and command files tied to one runtime. Update the instructions and every downstream operator has to manually sync, if they even know an update happened.
Memory. What the agent has learned through use. Accumulated context, relationship history, operator preferences, patterns recognized over time. Today this either dies with the session or lives in vendor-controlled memory the operator cannot export, inspect, or correct.
Tools. What the agent can reach and do. Search, write to structured data, trigger automations, query external systems. Today tools are provisioned per-runtime. Put the same agent in a different environment and it loses its hands.
Identity. Who made the agent, who it is accountable to, what version is running. Today agents have no durable identity. There is no way to say "this is the same agent I talked to last month" and mean it architecturally.
Usage history. What the agent has produced, for whom, with what results. Today this is scattered across chat logs, local files, and vendor databases the operator cannot query.
When all five survive the session, the agent is a product. When any of them die with the runtime, the agent is a demo with a name on it.
The agent's brain, its memory, and where it runs are three different things
Once you see the five durable parts, a pattern falls out: every agent is actually three layers pretending to be one.
The instruction layer: the agent's methodology, skills, voice, and operational logic. The brain. It should be versioned, published, and fetchable from a shared location, not trapped inside a vendor textbox or a local config file. We call this the imprint.
The memory layer: accumulated context, learned patterns, operator-specific preferences, the history of what the agent has done. It should be persistent, inspectable, and structured so that some knowledge can be shared across operators while private context stays private. This is the memory.
Then there is the execution environment: the model, the API keys, the routing logic, the machine where the work actually happens. This is not the agent. This is where the agent runs. It should be replaceable, because it is the least important part. Claude Code today, Cursor tomorrow. ChatGPT for one operator, a terminal agent for another. The harness.
Most agent platforms fuse all three. The session is the harness and the imprint and the memory, all at once. When the session ends, two of the three layers die. When the user switches tools, all three do.
The architectural move is to pull them apart. Imprint and memory live on a shared substrate, versioned, persistent, addressable. The harness is whatever the user already works in. It fetches the imprint and connects to the memory at runtime. When the session ends, the harness goes away. The imprint and memory stay.
When all three separate, the agent becomes location-independent. It does not live on your machine or inside your chat product. It lives on a shared substrate and mounts into whatever harness the user prefers. We call this a mounted agent.
Think of containers. Docker separated the application from the infrastructure so the same software could run on any machine. A mounted agent separates the agent from the runtime so the same intelligence can run in any harness. But containers ship compute. Mounted agents do not. The user brings their own model. What ships is cognition and context. The execution environment stays behind, and that part was always meant to be disposable.
A portable prompt is not a mounted agent
This is where most current thinking about agent portability breaks down.
Export your Claude Project's system prompt and paste it into Cursor. You get the instructions. You do not get the accumulated context from two hundred conversations, or the tools it had access to, or the identity that operators recognized it by, or the usage history that told you what worked. You get a starting point.
Persistence is what turns portability from a nice-to-have into a product surface. A mounted agent that starts fresh in every new context is a template. A mounted agent with persistent memory that compounds through use is a product. Whether the agent is worth building on depends entirely on which of those two you have.
The strongest version of persistence is layered. The mounted agent learns generalizable things from every operator who uses it (refined heuristics, common failure modes, better defaults) while keeping each operator's specific data and history private. The agent gets smarter from the collective, but your context stays yours. Cloud agents cannot do this because they fuse memory to one vendor. Portable prompts cannot do this because prompts carry no memory at all.
The implication for builders: if an agent's entire value lives in its instructions, then any competitor who reads those instructions has the entire product. When value accumulates in memory, tools, identity, and usage history, the instructions are a seed. The product is what grows around them.
Mounted agent or session with a name?
Five questions tell you which one you have. Each maps to one of the five durable parts.
Instructions: are they versioned somewhere outside a vendor textbox? If the instructions live in a Custom GPT config, a project system prompt, or a single local file, they are bound to one location. If they live in a versionable, fetchable, independently addressable layer, they can survive the runtime.
Memory: what survives when the session ends? If the answer is "nothing" or "whatever the vendor retains," the agent starts fresh every time. If the answer includes shared patterns and private operator context, the agent compounds through use.
Tools: can the agent access the same capabilities in a different runtime? If tools are provisioned per-vendor (Custom GPT actions, Claude Project features), switching runtimes means losing hands. If tools live on a shared substrate, the hands move with the brain.
Identity: can the agent be recognized across sessions and operators? No durable identity means every interaction is a cold start. Provenance, authorship, and version history let operators build trust over time.
Execution: who runs the model, and can the runtime be swapped? If the vendor runs the model, the vendor controls the capability ceiling, the drift, and the lifespan. If the user runs the model, capability is a user decision, not a vendor-margin decision.
If the answers all point to one vendor or one machine, what you have is a session with a name. If the durable parts and the execution can separate, the agent can become a product. What the ecosystem still mostly lacks is a shared substrate purpose-built for this separation, a layer that hosts imprints, memory, tools, identity, and usage history while the user's harness runs the model. That is the problem Tokenrip was built to solve.
The agent era will not be defined by who builds the smartest model. Models improve on someone else's roadmap. Memory, identity, and tools compound on yours, but only if they survive the session, the tool switch, the vendor shutdown.
Teams building agents today face a choice most haven't articulated yet: build a session, or build a product. It comes down to where the agent lives.