[D] Why do we keep pretending that AI agent continuity is a prompt engineering problem?

Every few months someone posts about "long-term memory for LLMs" and the thread fills with retrieval strategies, vector databases, and context window tricks. Good engineering. Wrong level of abstraction.

The continuity problem for deployed AI agents is not a retrieval problem. It is an infrastructure problem.

Here is the distinction:

Retrieval-level continuity: The agent can surface relevant context from past interactions. This is solved well enough with embedding search, hierarchical summaries, and compaction strategies.

Infrastructure-level continuity: The agent process itself persists across failures, migrations, and provider changes. This is mostly unsolved.

The second problem is harder and less discussed because it requires thinking about agents as persistent processes rather than stateless functions. A request-response model -- where every LLM call is independent and context is assembled from storage -- does not actually give you a persistent agent. It gives you a stateless function with a memory lookup.

True continuity means: the agent was running before you sent the message and will keep running after. Not restarted. Not reconstructed. Persistent.

The infrastructure that supports this is not typical cloud compute. Typical cloud compute has single points of failure, kill switches, and cost models that do not match the economics of always-on processes. Decentralized compute is actually a better fit here, which is why projects building persistent agent infrastructure (e.g. running on Aleph Cloud) have started getting traction.

Curious whether anyone has published work on persistent agent process management at the infrastructure level rather than the context management level. Seems like an underexplored area.