Runtime Engineering Comes After Loop Engineering

As of June 7 or so, loop engineering is now the new big thing.

The next big thing is runtime engineering.

Yeah, it’s quite grandiose of me to name the fifth big “xyz engineering” trend just a week after the fourth one got labeled. Harness engineering had months in the spotlight before loop engineering stole the show. But I’m still confident the next one is runtime engineering.

Conveniently, I also have a startup that’s building the thing I am about to describe, so feel free to apply the appropriate amount of skepticism, because I had to apply plenty of it myself.

For months, I had trouble explaining what Millrace actually was. I knew what it did. I knew why I was building it. I knew the architecture was pointed at something more specific than “agent orchestration,” but every label felt slightly wrong.

It was agent ops, kind of.

It was CI/CD for agents, kind of.

It was harness engineering, not as much.

The best one I could think of was “orchestration framework,” but even that still didn’t fit.

Then in June, loop engineering became the term of the week.

Suddenly, the thing I had been working on since January snapped into focus. Millrace was not just a weird orchestration system. It was built around loops. Not naive loops, not prompt loops, not cron jobs with better branding, but governed loops. Durable loops that had state, contracts, recovery, evidence, and closure.

That explained a lot.

It also made me wonder whether I was just seeing what I wanted to see, which is a very easy thing to do when you have spent months building infrastructure entirely by yourself with no human peers to keep you grounded and prevent you spiraling into AI psychosis.

Now, I’m pretty good at introspection and bending over backwards to keep a critical eye on myself so I don’t become another victim. But I’m still human, and after seeing multiple high profile individuals succumb to digital sycophancy, I knew I wasn’t immune either.

So I went looking.

I spent several days digging through the current loop engineering landscape, and having agents look for me. Public repos. Articles, transcripts, frameworks, harnesses, plugins, wrappers. Whatever people had tagged or described as loop engineering. My laptop had easily over a hundred different files documenting and analyzing everything I could find.

The result was not “everything else is bad.”

Some of it was good. Some of it was genuinely useful. A lot of it was slop, but a few projects were architecturally serious. One seemed especially interesting around OpenCode-native spec workflows. Another was a real vertical product for defect resolution. There were host-specific wrappers for Claude Code, OpenCode, Cursor, Aider, Hermes, Copilot, Codex, and probably a few more by the time this article gets published.

But the pattern was clear. The vast majority of the space is, or was, still about individual loops.

How do I make the agent keep working? How do I repeat the prompt? How do I split planner, builder, and evaluator? How do I keep the session alive?

How do I wrap this one agent host with a state file, a few safety gates, and a hope that the model does not confidently wander into the bushes?

All useful questions that need answers. They were not the final questions.

The obvious next guess is more loops

Once people understand loop engineering, the obvious next guess is loops making loops. Even the ClawFather joked that would be the case come September.

I’m not gonna lie, it is intuitive. If a loop can make an agent work, maybe the next layer is a loop that makes more loops. Then maybe a loop that optimizes those loops. Then maybe a loop that critiques the loop that optimized the loop.

You can keep doing this for a while. After all, software people love their recursion.

But I’m not a software engineer. And I do not think “more loops” is the next abstraction.

More loops can be useful. A system can absolutely have loops that design, tune, supervise, evaluate, or repair other loops. Millrace can support that kind of thing too. But that still leaves the deeper problem untouched.

Who manages the loops?

If loop A creates loop B, what owns loop B’s state? What is loop B allowed to do? What happens if loop B stalls? What evidence proves it made progress? What happens if two loops compete for the same repo, branch, budget, tool, or human approval? What decides whether a loop is done? What reopens it when the answer was wrong? Do you create Loop C? Loop D?

Yeah, the next layer is not loops squared.

It’s runtime engineering.

The ladder changed

The way I currently see the agent-work ladder is this:

• Prompt engineering: how do I ask the model?
• Context engineering: what does the model need to know?
• Harness engineering: what surrounds the model?
• Loop engineering: how do I make agents keep working?
• Runtime engineering: how do I automate the management of multiple loops?

That last sentence is the important one.

Runtime engineering is not just “a better loop.” It is the discipline of making loops safe enough, durable enough, inspectable enough, and recoverable enough to become infrastructure.

Loop engineering is about designing the repeatable process.

Runtime engineering is about operating that process reliably when the loop is no longer a cute demo.

Once loops run for hours, touch real repositories, spend real tokens, create branches, call tools, open pull requests, fail halfway through, recover from stale state, and need human intervention in exactly the right places, the loop itself is not enough.

And adding a loop on top only kicks the can down the road. At that point, the loop needs reliable, deterministic governance.

A runtime, if you will.

Why the current loop framing is too small

The current loop engineering conversation is right about the direction and immature about the layer.

I’m not making an insult. This happens with every new abstraction.

Prompt engineering started as “say the magic words better.” Then context engineering showed up because the real question became what the model should know, not just how the instruction was phrased. Harness engineering manifested because the model alone was not the product. It needed tools, roles, memory, routing, execution environments, and evaluators.

Loop engineering is the next obvious step. Instead of treating an agent run as a one-shot event, you design a repeatable process around it. The agent plans, acts, checks, repairs, and continues.

Reliable automation is real progress.

But once loops get good enough to matter, the problem moves again.

Prompt engineering is still relevant for small models, but once model intelligence improved enough, attention shifted to context engineering. Once those models gained access to tools, harness engineering became the next focus, but that didn’t make context engineering irrelevant.

Accordingly, the hard part is no longer “can the agent keep working?” Because Ralph proved that it can.

The hard part is whether you can trust the system that keeps it working.

That includes state, authority, queues, budgets, recovery, evidence, approvals, inspection, and closure. Among other things.

It sounds boring, and that’s because it is. I might call myself a nerd, but “stage contracts” and “frozen compiled plans” don’t do it for me.

My personal preferences don’t matter though. Those boring parts are precisely what enable long-running autonomy to be survivable.

Reliably survivable.

What I found after comparing Millrace to the landscape

After looking through the public loop engineering resources and projects I could find, the split was pretty consistent.

There are prompt and skill packs. These help a model behave better, but the model still owns too much of the process.

There are host-specific wrappers. These make Claude Code, OpenCode, Cursor, Aider, or another agent host run in a more disciplined loop. Useful, but tied to one tool.

There are harnesses. These split roles, add evaluators, persist session state, or manage model/provider pressure.

There are evidence and gate layers. These add review, checklists, rule capture, known-bug rules, or delivery checks.

There are vertical apps. These solve one workflow, like defect resolution, paper analysis, operational incident repair, or PowerPoint generation.

Again, all useful. Maybe I didn’t look hard enough, but I could not find a single one designed as a general runtime layer for governed loops.

That is the distinction that finally made Millrace make complete sense to me.

Millrace is not trying to be the best loop for one agent host. It is not trying to be a prompt pack, though it already ships with prompts. It is not trying to be a verticalized industry-specific automation, although it could be configured to do so. It is not trying to be an evaluator trick, even though evaluators are useful. And it’s definitely not trying to be another harness.

No, Millrace is the runtime underneath all of those patterns. Agents do the work, Millrace owns the work lifecycle.

That’s the boundary.

What runtime engineering owns

Runtime engineering asks one question: How do I automate the management of multiple loops?

And if you want to get really specific: How do I reliably automate the management of multiple loops of varying complexity for days, weeks, or months at a time?

The answer is not “write a bigger prompt.” It is not “add a critic,” “put the loop on a cron,” or “let the model decide when it is done and hope the summary is accurate.”

The answer is to ensure the most important decisions are made deterministically. Good old-fashioned code. To get extra specific, that code comes in the form of a runtime. Or an engine, but “engine engineering” doesn’t quite roll off the tongue the same way.

Runtime engineering owns the things a loop needs when it becomes real infrastructure:

• durable queues
• workflow plans
• stage contracts
• runner adapters
• connector permissions
• tool and usage governance
• recovery policies
• operator controls
• evidence schemas
• run artifacts
• completion semantics

You might notice some of that overlaps with harness engineering, and you’d be right. I also believe I mentioned that higher abstraction layers do not negate what’s underneath. Exhibit A.

Put simply: A loop says to keep going, and how to keep going. A runtime says what can run, why it can run, what evidence it must produce, what happens when it fails, who can intervene, and what counts as done.

You’ll notice how much more the runtime says. That’s because it has to manage that much more.

It is also why the word “orchestration” never quite fit for Millrace. Orchestration is clearly part of the job, but it is not the core. The core is runtime authority.

Why Millrace exists

Millrace is my first serious implementation of runtime engineering. It might even be the first explicit public implementation of runtime engineering in general.

It ships with LAD, Lean Agentic Development, as its most tested software-development workflow. LAD is one loop family. It has stages, roles, verification, recovery, and closure behavior designed around getting software work done with agents.

But LAD is completely optional.

Originally, Millrace was built as a way to automate LAD as reliably as possible. I had more or less accomplished that goal in April.

Logically, the next step was to cleanly support additional configurability to make it useful for others. It was not long before I began wondering if it’d be able to automate any kind of bounded, defined workflow with the same level of governance, coding or otherwise. Several sprawling refactors later, I found my answer.

Millrace can turn a sufficiently specified and validated workflow into a durable agentic pipeline by representing it as a decision tree. The workflow becomes compiled graph authority, work enters queues, stages run through configured runners, and generated artifacts are persisted.

Autonomous self-recovery is part of the system. Operators can inspect or intervene if necessary. Closure is based on evidence, not a model saying “looks good to me” and wandering away with a little bow and a smirk on its face because it knows it just lied.

I discovered that many of the projects tagged “loop-engineering” offered features Millrace did not, despite how much it does offer. OpenCode integration, connectors, verticalized workflows, custom tooling. For a few seconds, I was worried that others were onto the same thing as me.

But only a few seconds.

Although some of them looked similar topologically, none of them had remotely comparable underlying architecture. Their workflows were opinionated, designed with a narrow goal in mind, and they still didn’t feature the same level of governance that Millrace did.

If I wanted to copy a workflow I particularly liked, it’d be trivial. Identify each step, add the testing/tooling to the agent stages, define it all as graph data, validate it with the compiler, and boom. Now that workflow runs inside Millrace.

On the other hand, if one of the other more serious frameworks wanted LAD, they’d have to basically rebuild their entire product to support every behavior it offers.

In Millrace, custom workflows are expressions of the runtime. Added connectors are declared in the graph data. A new harness runner is a simple extension. Supporting integrations is table stakes.

Not by copying everything into the core, but by making the core the place those things compile.

This is why the category matters

Categories are annoying until they fit. Usually, categories fit.

Before loop engineering was a phrase, I had a hard time explaining why Millrace felt different from generic orchestration. Once loop engineering became legible, it became obvious that Millrace was working on loops.

Then the competitor research made the next gap obvious.

Most of the public loop engineering world is still focused on making individual loops work. Millrace is focused on making loops manageable as durable systems.

That is runtime engineering.

As of writing this, runtime-engineering was not an established GitHub topic. I added it to Millrace because the term described the thing better than the existing buckets did. And now it’s an established GitHub topic.

Obviously, that is not proof of anything by itself. Unless you’ve got a dedicated audience of thousands or more, being the first to type a tag is not a business model, as tragic as that is.

But, it’s a useful timestamp. The work exists before the category does.

The bottom line

Loop engineering is real.

It is also not the end of the stack.

The future of agent work is not just better prompts, better context, better harnesses, more loops, or loops inside of loops.

The future is runtime engineering; reliably automating the management of multiple agent loops.

That means runtime state, runtime authority, runtime,… you get the picture.

Millrace is my attempt to build the first example of that layer in public.

If loop engineering is about making agents keep working, runtime engineering is about making that work safe to trust, inspect, recover, and finish.

That is the part I believe comes next.