Long story short, it started off as a way to automate my agentic engineering workflow, and then I realized it had way more potential than that. Now it's a framework that allows users to turn complex, multi-step workflows into fully automated governed loops.
The past few months, I found it difficult to make posts about Millrace, because I didn't really understand what product category it belonged to. It was too slow to be an orchestration framework, too complex to be a loop, and because it's an agent-native CLI tool, there's no UI either, which meant it wasn't even visually cool to look at. But that's when I discovered the difference between naive loops and governed loops.
Ralph, cron jobs, automations, /goal: those are all naive loops. It's just the same prompt repeated on a schedule or whenever the agent finishes its run. Governed loops change the prompt depending on what the previous agent accomplished, and whether or not it was successful.
With governed loops, you can scope each step into a narrow workflow slice which, in isolation, an agent has a high chance of successfully completing. Artifact handoff between agents, "what stage runs next," incoming prompts, recovery semantics, all of that is handled by the runtime, and all of that is highly (soon to be "fully") configurable using graph data. That plan gets frozen upon validation by Millrace's compiler, ensuring that the loop plan does not get accidentally mutated by the governed agents during execution.
It's not quite fully configurable yet. My bottleneck is primarily tokens because I'm broke (no, I'm not asking for money). But so far, it's quite promising. I'm using it to autonomously port Millrace from Python into Rust, so that for every new version I release in Python, it'll grab the latest release, port the changes into the Rust version, ensure the completed version is functionally on parity with the original, and publish the validated new version to crates.io as a new release. Been doing that for over a month now. If there's no new version, it just sits idle, waiting.
The README for the Rust implementation is abhorrent slop, but the framework itself is functionally equivalent to its derived Python version. Even contains the same bugs as the corresponding Python release it was ported from.
All that to say, I think the future of agent loops looks architecturally similar to Millrace, if it doesn't end up being Millrace itself. And that's because we're still in the "naive loops" era. As far as I've seen, nobody else has created a governed loop the way I've described, especially not to the level of configuration that Millrace possesses.
If anyone knows of another governed loop framework, I'd be extremely interested to see it.