Building LoopEngine — Thoughts on Loop Engineering

A Weekend Lab

Over the past few weeks, I had been increasingly hearing about something called loop engineering. The phrase kept appearing in discussions around agents, autonomous systems, AI runtimes, and coding assistants. Like many new terms in our industry, it was initially difficult to determine whether this was a genuinely useful abstraction or simply another way of describing ideas that already existed under different names.

Curiosity eventually won.

This weekend, I decided to spend some time building a small experimental system to expand my own understanding. The intention was not to build a framework, propose an architecture, or prove any particular thesis. It was simply a small engineering lab—a place to experiment with planning, execution, verification, and feedback loops, and perhaps develop a better intuition for what people actually mean when they talk about loop engineering.

The experiment eventually became something I started calling LoopEngine.

As often happens with these kinds of projects, the implementation started asking questions that were far more interesting than the original idea. The difficult problems were not about prompts or model selection. They were questions like: How does the system know whether it is making progress? How does it know when to continue, when to retry, and when to stop entirely? What does failure look like? And perhaps even more interestingly, what does it mean for such a system to become lost?

Somewhere during that process, I realized that I was no longer really trying to understand loop engineering. I was trying to understand loops themselves.

From Workflows to Loops

For the purposes of this experiment, I started thinking about loop engineering as the discipline of designing systems that repeatedly observe, plan, act, measure, and adapt toward an objective.

The important idea here is not repetition itself. Software has always contained loops. Build systems, CI pipelines, schedulers, retries, event processors, and control systems all loop in one form or another. What felt different here was that the future path of execution was no longer entirely predetermined. Every iteration had the ability to change the next one.

A traditional workflow usually feels like a sequence of boxes connected together.

A → B → C → D

Even many agentic systems today still resemble this pattern. One of the boxes may contain an LLM, but the overall structure remains largely fixed.

The systems I found myself building increasingly looked like this instead.

			
Observe
↓
Plan
↓
Act
↓
Measure
↓
Adapt
↓
Repeat

		

The difference may appear subtle, but it changes the nature of the system entirely. A workflow executes. A loop continuously decides what should happen next.

The moment feedback begins altering future behavior, the system starts looking less like orchestration and more like optimization. At least, that is how it increasingly started feeling to me.

When Feedback Becomes the System

The example I repeatedly used while building LoopEngine was intentionally simple: build a small Python command-line todo application supporting add, list, and done, with tasks persisted into a tasks.json file.

The first cycle would usually produce a plan.

			
- Create app.py
- Implement JSON persistence
- Produce README.md
- Add command handling

Actors would execute these tasks, files would start appearing in the workspace, and eventually something resembling a working application would emerge.

			
workspace/
├── app.py
├── README.md
└── tasks.json

In one run, the generated application was actually quite competent. It handled argument parsing, persistence, validation, and error handling using only the Python standard library.

But the interesting part was never the generated code. The interesting part was what happened next. The system would verify its own outputs.

Did the files exist?

Did the commands execute?

Could tasks actually be persisted?

Was the documentation complete?

If verification failed, the next cycle did not merely repeat the previous one. It changed. The planner would focus on the missing pieces. The review stage would identify weaknesses. The next plan would emerge from the failures of the previous attempt.

Over time, I realized that this iterative behavior was becoming the entire point. The system was not simply generating artifacts. It was continuously refining them through feedback.

One of the more surprising realizations during this experiment was that these loops increasingly started looking like optimization systems. At first, I thought I was mostly building orchestration mechanisms and planning abstractions, but gradually measurement started becoming the center of everything.

Without some notion of progress, the loop has no way of distinguishing improvement from movement. It can continue producing plans, generating files, invoking tools, and creating the appearance of activity while in reality simply wandering around the solution space.

A loop without an honest loss function is therefore not really optimizing anything. It is merely moving.

For the Python example, the measurements were surprisingly mundane.

Does app.py exist?
Does README.md exist?
Does python app.py list execute?
Does tasks.json persist data correctly?
Are all required commands implemented?

None of these measurements are particularly intelligent. Yet together they provide something far more important. They provide direction.

A refinement loop with poor measurements simply converges confidently on the wrong thing. That idea started appearing everywhere. Perhaps intelligence matters less than feedback than I had initially assumed.

When Systems Get Lost

Another interesting realization was that success and failure are not the only meaningful states. There appears to be a third state that feels equally important.

Lost.

The loop may continue producing outputs. It may continue generating plans and executing actions. Yet nothing meaningful is improving. The system remains active but no longer appears to be making progress. Recognizing this state felt surprisingly significant. Perhaps long-running cognitive systems need the ability to admit:

I no longer know how to make progress.

That seems like a useful capability for both machines and people.

Determinism and Intelligence

Around the same time, I found myself increasingly appreciating the Actor Model. This was not a rediscovery. I had previously used actor systems while building desktop applications. But loops made the fit feel surprisingly natural in a way I had not fully appreciated before.

Actor systems solve a very particular class of problems remarkably well. They provide isolation, supervision, asynchronous coordination, long-running state, and fault recovery. Loops happen to need almost all of these properties.

Planning became an actor. Execution became a collection of actors. Review became an actor. Verification became an actor. Persistence became an actor.

As the system evolved, it increasingly started resembling a society of cooperating processes rather than a single application. Another idea slowly emerged during this process.

The actors themselves may use language models and therefore behave probabilistically. Given the same inputs, they may occasionally produce different plans, different reviews, or different decisions.

Yet I found myself making the boundaries between actors as deterministic as possible. Every message crossing stage boundaries remained typed and validated. The protocols remained predictable even when the reasoning inside the actors was not.

Over time, I started thinking about this separation in a very simple way.

Nondeterminism inside the nodes. Determinism in the wires.

Or perhaps:

The graph is deterministic. The nodes are intelligent.

I may be overfitting patterns from a relatively small experiment, but this distinction increasingly felt important. It allows intelligence to remain bounded and observable.

It allows systems to remain governable even when parts of them are probabilistic. At some point I also found myself using a simplified mental model:

			
Actor
+
Reasoning
+
Goals
+
Memory
+
Tools
=
Agent

		

I do not know whether this framing will ultimately hold, but it has become a useful way for me to reason about these systems. Actors solve systems problems. Language models solve cognition problems. Perhaps agents emerge when the two are combined. Or perhaps this is merely one useful lens among many. Time will tell.

Towards a Runtime

As LoopEngine became more sophisticated, another abstraction emerged almost naturally. Something needed to observe the entire system.

Something needed to decide whether another cycle should run, whether a human should be consulted, whether budgets had been exhausted, or whether progress had stalled.

I started thinking about this component as a Director. The metaphor that kept coming to mind was filmmaking. Actors perform. The director does not.

The director observes, allocates attention, evaluates progress, and decides what should happen next. The Director receives intent, progress reports, verification results, review summaries, budget information, and human feedback.

Yet it does not perform domain work itself. It decides.That distinction ended up feeling surprisingly useful. Another realization followed shortly after. Not everything belongs inside the loop.

Budgets do not.

Policies do not.

Human checkpoints do not.

Permissions do not.

Termination rules do not.

These things exist outside the optimization process because they define the boundaries within which optimization is allowed to occur.

Governance constrains optimization.

It does not participate in optimization. One of my favorite parts of the experiment ended up being the logs. Every cycle left behind traces: plans, failures, verification results, replanning decisions, and human escalations.

The loop slowly started telling a story.

			
Cycle 1
Verify: FAILED
Reason: command incomplete.
Cycle 2
Verify: PASSED.
Decision: STOP.

		

The logs made the system feel less like magic and more like a distributed system with cognition. The system was continuously explaining itself through action and feedback. In some strange way, the event stream started resembling observability for reasoning itself.

Operating Systems for Bounded Intelligence

The evolution of the project itself also became interesting. It started as a workflow. Then it became adaptive planning. Then optimization. And eventually it started resembling a runtime.

At some point, I noticed I was spending less time thinking about prompts and more time thinking about runtime concerns.

How many model calls remain?

Should shell access be allowed?

When should a human be consulted?

How many cycles without progress should be tolerated?

When should the system stop?

These no longer felt like prompt engineering questions. They felt like operating system questions. Traditional operating systems manage CPU, memory, files, permissions, and scheduling.

Loop runtimes increasingly seem to manage token budgets, tool permissions, persistence, memory, governance, progress, escalation policies, human checkpoints, and termination conditions.

I may be completely wrong about this analogy.

It is entirely possible that these similarities are superficial and that future systems evolve in a very different direction. But the more I worked on LoopEngine, the more difficult it became to ignore the parallels.

At least for the kinds of experiments I was running, governance, observability, resource management, and supervision increasingly started becoming unavoidable concerns.

Perhaps we may eventually need something that looks like an operating system for bounded intelligence. Or perhaps we are merely rediscovering old distributed systems ideas under new names. I genuinely do not know.

A Thought in Motion

I stopped the experiment not because it failed, but because it had already answered many of my questions and generated even better ones. Perhaps the biggest lesson from this small weekend lab was this:

Intelligence itself may not be the hardest problem.
The harder problem may be designing the feedback systems, measurements, governance mechanisms, and constraints around it.

The more I experimented, the less I thought about prompts and the more I thought about loops.

About systems that continuously observe themselves.

About systems that adapt.

About systems that know when they are succeeding, when they are failing, and perhaps most importantly, when they are lost.

I started the weekend trying to understand a term. I ended it wondering whether loops, feedback, and bounded adaptation may be a much more fundamental idea than I had initially assumed.