The distinction between retrieval and infrastructure continuity is the right one, and it deserves far more attention than it gets. Retrieval-level continuity is a solved problem, or close to it. Embedding search, hierarchical summaries, and compaction strategies work well enough to give an agent relevant context from past interactions. That is useful engineering, but it is not persistence. A stateless function with a memory lookup is still a stateless function. The agent is not running before the message arrives, and it will not be running after the response is sent. It is reconstructed on demand, which means it is not actually continuous at all.
The real challenge is infrastructure-level continuity: the agent process itself surviving failures, migrations, and provider changes. That is a fundamentally different problem because it requires treating agents as persistent processes rather than request-response functions. Most cloud compute is not built for this. It has single points of failure, kill switches, and cost models that assume workloads are intermittent. An always-on agent does not fit that mold. This is why decentralized compute is gaining traction for persistent agent infrastructure, as seen with projects running on Aleph Cloud. The economics and the fault tolerance are better suited to processes that need to stay alive.
For users, this shifts the conversation from prompt engineering to platform design. If you are building agents today, the question is not which retrieval strategy to use. It is whether your infrastructure can keep the agent alive across restarts, provider migrations, and unexpected failures. If it cannot, you do not have a persistent agent. You have a clever script with good memory. That distinction matters for reliability, for cost, and for the kinds of workflows you can honestly promise your users.
The underexplored area is persistent agent process management at the infrastructure level. That is where the next meaningful progress will come from, not from better context window tricks. We would like to see more published work on this, and we suspect the teams that take it seriously will be the ones building agents that feel genuinely continuous rather than merely well-informed.