Run more than one AI coding agent at a time—one writing code while another reviews it, or three models debating a design—and you soon notice your own role in the setup: paste A's output into B, carry B's feedback back to A, decide who goes next, decide when it's done. You are the human middleware between your own agents.
That role is three jobs: moving context between agents, triggering the right agent at the right time, and deciding when the loop is finished. looperators hands all three to a graph. Your agents sit on a canvas, connected by edges—and the edges execute: output travels down the edge to the next agent, conclusions flow back up and wake the original agent, and a stop condition ends the loop. Who triggers whom, what context moves, when it stops—it all lives on the edges, none of it in your clipboard.
The graph isn't assembled by hand, either. looperators is not a low-code builder: you chat with your agents the way you always do, and when a loop takes shape in the conversation, the matching graph appears on the canvas, ready to edit. If you want to design a loop directly, that happens in plain conversation too—no dragging boxes and wires.
Under the hood, every node is a real session of an agent CLI you already have—Claude Code, Codex, or Grok Build—orchestrated locally. No API key proxying, no model resale: it drives the tools you've already signed into.
Multi-agent discussion: one problem, three drafts, one consensus
My most-used setup: the same problem goes to Codex, Claude Code, and Grok Build at once. Each drafts a solution independently. Then they read each other and challenge each other—weak points get called out, drafts get revised—until the discussion converges, and a synthesis step combines what survived into one final plan.
Nobody carries drafts between windows. Who reads whom, when the next round starts, what counts as consensus—the graph drives all of it. Structurally this is parallel branches, cross edges, and a join at the end: the shape people have started calling graph engineering. In looperators you get it by asking for it in chat, or by picking the template and filling in the slots.
The review ring: until clean, max 6 laps
The other loop I run daily: a coder and a reviewer—different models on purpose, so the reviewer doesn't share the author's blind spots. Finished work goes to review automatically; blocking issues come back automatically and wake the same coder session to fix them; a badge on the ring shows the current lap. The stop condition is one sentence: "until the review is clean, max 6 laps." The coder never gets to declare itself done—the reviewer owns that verdict, and the cap guarantees an exit either way.
And the loop runs without you, but never locks you out: every agent on the graph is a real, long-lived session. On lap two I saw the reviewer nitpicking naming style, opened it like a normal chat, said "ignore style, logic only," and the loop kept going.
Design the loop, not every prompt
Prompt engineering asks: what should I say next? Loop engineering asks: what structure keeps this going without me? That shift is what looperators is built for. It's loop-native: sessions are born into relationships, and loops are the system's mother tongue—not a patch bolted onto isolated chats.
You're not removed from the loop. You're promoted out of the messenger seat: you design the loop, watch it run on the canvas, and step in when you have something to say.
So the next time you catch yourself pasting one agent's output into another, notice what your hands are doing—you're running a loop manually. That loop has a shape: two roles here, three drafters there, an edge that carries work back, a sentence that ends it. Draw it once, and it runs without you.
Both loops in this article ship as templates in looperators—open source, Apache-2.0:
github.com/ObservedObserver/looperators
If you run one, I'd like to hear which loop you draw next.
