The Loop Escapes the Process: Agentic Durable Execution

Agent Loops Can Live Far, Far Longer Than Their Processes

A Windows message loop usually exists for as long as the application is open. A game loop exists for as long as the game process is running. A network event loop exists for as long as the server process is alive. If the process dies, the loop dies with it. For many traditional applications, that is acceptable.

Imagine a customer refund agent. The agent receives a dispute, retrieves the transaction, reads the refund policy, checks account history, calls a fraud service, asks the customer for additional information, waits for a response, evaluates the answer, and eventually issues a refund. That is burning a lot of tokens, but is also helping make some faster and more informed decisions and eventually issues a refund.

Conceptually:

That loop may run for seconds, minutes, hours, or days. The customer may take two days to respond. An external API may time out. The service may be redeployed. The container may disappear. The node may fail. A network will certainly blip. The logical task may live far longer than any one process executing it. It may execute across two, three, or more processes over its lifetime. And that is where the simple agent loop starts to break down; it literally crumbles. This is why durable execution has been thrust into the limelight.

What Happens When the Loop Dies?

A basic agent framework implementation often looks perfectly reasonable:

while not finished:
result = model.reason(context)
action = result.action
output = execute(action)
context.append(output)

This is what you get with any of the innumerable non-durable agent frameworks. Now imagine that this loop has already been running for forty-five minutes. The agent has retrieved the customer record, read the transaction, checked policy, called multiple systems, asked the customer a question, waited for the answer, and decided that the customer is eligible for a refund. The next action is to issue the refund. Then the process crashes. If the logical state of the task exists mainly in process memory, then the loop disappears with it—poof.

The obvious response is to restart the process. But restart what?

Restart from where? Which actions already completed? Which calls can safely be repeated? What if the refund API accepted the refund just before the crash, but the response was lost? If the agent starts again and blindly repeats that action, the customer may receive two refunds. At that moment, the problem stops being an AI problem. I need a human to fix this. It becomes a distributed systems problem.

Checkpointing does not fix this. Checkpointing preserves state, but checkpointing alone does not guarantee correct recovery around external side effects or ambiguous failure boundaries. You only get checkpointing with LangGraph, Strands, Microsoft Agent Framework, Google ADK, CrewAI, but not failure detection.

Linux Supervision Is Not Durable Execution

Let’s return to Linux and talk for a moment about failure detection. This is where another familiar loop becomes useful: the supervision loop. Unix and Linux systems have a long history of supervisors whose job is to make sure processes keep running. init, systemd, container runtimes, and orchestrators all use variations of this idea. This is incredibly useful because a process crash no longer means someone has to log in and restart it manually. But supervision only solves the process problem. It does not solve the execution problem. There is an important distinction:

This is reincarnation as the same person, not as a new person. Would you like to come back as you, with your current memories, or be reborn as a new person? The First Fifteen Lives of Harry August, Groundhog Day and Replay are all humans with durable execution.

The Real Requirement Is Not to Keep the Process Alive. It Is to Reincarnate the Execution.

It is natural to respond to agent failures with better process reliability. This is a complexity trap and engineers love complexity and reasons to add it. Just run multiple replicas. Add health checks. Use Kubernetes. Restart containers. Spread workloads across machines. Add retries. Build watcher processes (who is watching the watcher?) All of those things are valuable, but they do not solve the deeper issue.

The business task should simply not depend on the lifetime of one process. The real requirement is this. The logical execution must survive even when the process executing it does not.

That changes the problem completely. Instead of trying to make the loop immortal and add complexity, we make the state of the loop durable. Problem solved.

The Loop Escapes the Process

This is the part of the loop evolution I find most interesting. We started with programs whose execution was essentially tied to the lifetime of a call stack. Then we created long-lived message loops. Games added continuously evolving state. Unix and Linux event loops made asynchronous external work efficient. Kubernetes control loops made software continuously reconcile reality toward a desired state. Agents added dynamic, goal-directed reasoning. The next step is to separate the logical loop from the physical process altogether. Put your mind into a new body just as in Altered Carbon.

You can think of the loop progression this way:

The important transition is the last one. We stop asking: “How do I keep this loop alive?” and start asking: “How do I make sure this logical task continues correctly regardless of which process, container, or machine executes the next step?” That is durable execution.

Process supervision recovers the process. Agentic Durable execution recovers the work.

Long-running software is not new, and neither is durable execution. We have spent decades building systems that persist state, wait for events, retry work, recover from failure, and continue over time. What agents change is that the path through the work is often no longer known in advance. The model can decide what to do next dynamically, wait for an external event or a human, call another tool, retry, change direction, and continue until it reaches a goal.

That makes the execution problem harder. The agent can choose its next action probabilistically, but the runtime still has to know exactly what has already happened, what is still outstanding, and where to continue after a failure. If an agent waits two days for a customer response, no thread or container should need to stay alive. If the process crashes halfway through the task, the work should not have to start again. The logical execution needs to be suspended, recovered, and continued independently of whichever process happens to be running it.

This is what I have previously called agentic durable execution: taking durable execution and applying it to the dynamic, probabilistic execution model of AI agents, where the path through the work can emerge as the agent reasons, acts, waits, retries, and changes direction. The agent loop itself is easy to describe: Think, act, observe, repeat. The difficult part begins when that loop meets production: time, state, retries, external side effects, waiting, crashes, restarts, and recovery. We have seen the loop evolve before. Windows made applications reactive. Games made loops continuously stateful. Linux made them asynchronous. Kubernetes made them reconcile toward an outcome. Agents make the next action dynamic and probabilistic.

The next evolution is different: The loop itself has to survive the process. The process can crash, the container can be replaced, and the machine can disappear, while the logical task continues. That is the shift from an agent loop to a durable agent loop.

That is the problem Diagrid Catalyst solves for applications, agents, and MCP servers, in fact any code. With agentic execution durable the work can continue even when the process cannot.

Why this matters if you are building agents

Two claims in this chapter are worth reading twice, because they are the ones most often conflated in agent framework documentation. Checkpointing is not durable execution - you get state preservation without failure detection or side-effect safety. And process supervision is not durable execution - systemd, container runtimes and orchestrators restart the process, not the work in flight.

If you are evaluating agent framework reliability, that is the test to apply: not does it persist state? but when this process dies mid-refund, does the runtime know exactly what already happened, what is still outstanding, and where to continue? That is the difference between a checkpoint and a durable execution engine, and it is what turns durable workflows into real AI agent execution guarantees - deterministic replay of what already ran, exactly-once execution of what has side effects, and crash recovery that resumes rather than restarts.

Which is the whole reason reliable AI agents are an infrastructure problem rather than a prompting one. AI agents failing in production usually fail at exactly this seam: the model chose correctly, and the runtime could not tell what had already been done.