loopexec: Bounded Loop Execution for Multi-Agent Systems

Most agent frameworks have the same gap: they tell you how to set up an agent but not how to bound its execution. The loop runs until something breaks or the model decides it's done. Neither of those is a real stopping condition.

loopexec is my answer to this. It's a loop execution runtime for multi-agent systems that treats iteration as a first-class concern - with explicit bounds, defined termination conditions, and clean handoffs between loops.

Why Unbounded Loops Are Dangerous

The standard pattern in agent frameworks looks something like this: run the agent, check if the goal is met, loop back if not. This seems fine until you see it in production.

Cost accumulation - An unbounded loop over a slow LLM is an unbounded credit card bill. Without hard limits on iterations, you have no ceiling on spend.

Divergent state - Agents that run in loops can compound errors. An agent that makes a wrong decision in iteration 3 might build five more iterations on top of that wrong decision before anyone notices.

No observable progress - If the loop doesn't emit observable state at each iteration, you can't tell the difference between "making progress" and "spinning." By the time you check, you might have burned 40 iterations going nowhere.

Handoff failure - When you have multiple agents that need to coordinate, an unbounded loop in one agent can starve another that's waiting on its output.

I kept hitting these in my own work. SMALL Protocol addresses the state and handoff problems, but I needed something that specifically governed the iteration layer.

What loopexec Does

loopexec wraps a multi-agent loop with four explicit controls:

Bound declaration - Every loop starts with a declared bound: maximum iterations, time limit, or cost limit. Whichever fires first terminates the loop. No bound, no start.

Progress checkpoints - At each iteration, the loop emits a checkpoint. Checkpoints are inspectable state: what was the input, what was the output, did this iteration succeed. If the loop is terminated early, you have a complete record of where it stopped.

Termination contracts - Termination isn't just "max iterations reached." The caller declares what success looks like - a structured output that matches a schema, a file that exists, a metric that crosses a threshold. The loop runs until the termination contract is satisfied or the bound is reached.

Resumability - A loop that was terminated due to a bound (rather than a success condition) can be resumed from its last checkpoint. This matters a lot in long-running agent tasks where you want to run in stages rather than hoping a single run completes.

Ralph

Ralph is the loop executor that runs on my infrastructure. It's the reference implementation of loopexec running against real workloads - local and remote agents, different model providers, different task types.

The name comes from "run and loop, halt if." Ralph doesn't care what's inside the loop. It doesn't care what model the agent uses, what framework it's built on, or what the task is. It cares about the bounds and the checkpoints.

This vendor-neutral design was intentional. I didn't want loopexec to be tied to a specific agent framework or model provider. The loop governance should be infrastructure-level, not application-level.

How It Connects to SMALL

loopexec and SMALL Protocol are companion specs. SMALL governs what an agent can do in a single execution unit - the intent, constraints, plan, progress, and handoff. loopexec governs how multiple execution units chain together with iteration.

If SMALL is the sentence, loopexec is the grammar for putting sentences in a loop.

In practice: a SMALL-governed agent produces a handoff at the end of its run. loopexec inspects that handoff against the termination contract. If the contract isn't satisfied and the bound isn't reached, it feeds the handoff back in as the next iteration's input. The loop continues until one of those conditions fires.

Current State

loopexec is available on GitHub. Ralph is running in production on my Mac mini stack. The spec is stable enough to build against. I'm still working on the tooling around bound estimation - figuring out upfront how many iterations a task should need is its own interesting problem.

If you're building multi-agent systems and you've felt the pain of unbounded loops, this is the piece I wish had existed when I started.