Before the Loop: When Programs Were Mostly Linear

The software industry has a habit of rediscovering old ideas and giving them new names. AI is no exception. Memory often looks a lot like state. Context often looks a lot like a cache. And the agent loop, for all the attention it is getting, is not the first time software has been organized around a long-running cycle of observe, act, update, and repeat.

We have seen loops before.

Windows GUI applications had the message loop. Games had the game loop. Unix and Linux servers evolved around network event loops. Kubernetes built an entire operating model around control loops. AI agents are now doing something similar with an observe, reason, act loop. These are not the same loops, and it would be a mistake to pretend they are. What they share is an architectural shift away from software that simply runs from beginning to end and toward software that stays alive, reacts to a changing environment, carries state forward, and repeatedly decides what should happen next.

What makes the agent loop interesting is not that it loops. It is that the decision about what happens next can now be probabilistic, dynamic, and impossible to know in advance. And that creates a new production requirement: the loop itself has to survive the process running it.

For agents, that history points toward the next step. The evolution is not simply a smarter loop, but a durable loop whose logical execution can survive the failure of the process, container, or machine currently running it. That is where agentic durable execution enters the story. So, let’s take a journey through the evolution of the software loop, from Windows message pumps to AI agents, and see why the software world has gone loopy.

Before the Loop, Programs Were Mostly Linear

The simplest programming model is still the easiest to understand. A program starts, performs a sequence of operations in a known order, and then finishes.

In code, the sequence is explicit:

load_customer()
calculate_price()
charge_card()
send_receipt()

The developer owns the control flow, and the program roughly moves from the top of the file to the bottom. This model works very well until the outside world becomes part of the execution model.

A graphical application cannot know which button the user will click next. A game cannot know whether the player will turn left, jump, fire a weapon, or simply stand still. A network server cannot know when the next connection will arrive or which socket will become readable. A Kubernetes controller cannot know when the actual state of the cluster will drift away from what was requested. An agent cannot know whether the next tool call will give it the answer it needs, whether it will need to try something else, or whether a task will take five seconds or five hours.

Once software has to respond continuously to a changing environment, the fixed sequence stops being enough. Just as biological life cannot be independent of its environment, neither can an application. The loop is essential and takes over.

Why this matters if you are building agents

An agent is the extreme case of the problem this chapter describes. A linear program fails when it cannot predict the next input. An agent cannot predict its own next instruction - the model decides that at runtime, mid-flight, based on what the last tool call returned.

So if you are debugging why AI agents fail in production, it is worth noting that the failure mode is not new. It is the same failure mode that killed the linear program: the execution model assumed the world would hold still.