As always, pragmatic, realistic, and actionable article. Thank you Addy!
Loops are IMO not worth the hype, just as long-horizon agents. They’re often advertised as the hammer that makes everything a nail. In my experience, most work I do is 80% research, understanding, exploration, only the last 20% are the parts that could potentially profit from loops.
First, I need to explore, understand the constraints, form my goal, then the agent can do the easy part. Whether it’s turn-based or looping is not a huge difference for most tasks, for some it is, that’s where loops shine.
Loops today are basically what telling GPT 3.5 „continue“ was yesterday. It‘s the continuation to fulfilling an instruction (initial prompt or initial goal).
Agents can not „keep going until this UI design is good“ because the goal is vague. However, just as I was reading that, I had the idea of an LLM judge board with, say 10 judges, of a few different models (e.g., Claude Opus, GLM 5.2, Kimi K3, DeepSeek V4, …) all score 1-10, the goal could be to score 8+. I‘d be interested in testing whether that yields results that are worth the token overhead.
Hi Jens, thank you for the kind words! I completely agree with your 80/20 breakdown. This ties right back into the core idea of the article: we simply cannot delegate our judgment. Loops are a useful tool for execution, but they certainly aren't a silver bullet.
Your idea for an "LLM judge board" is interesting. Using an ensemble of models (Claude, DeepSeek, etc.) to establish a consensus score is a pretty good way to try and quantify subjective goals like "good UI design." It effectively creates a dynamic stopping condition where one didn't exist. The token overhead would definitely be high, but as inference costs continue to drop, experiments like that become increasingly viable. I’d love to hear how it goes if you end up testing it!
Thanks for the comment! Figuring out better UX patterns for agent supervision and interruption is going to be a massive challenge for the industry moving forward.
Also, huge congratulations on hitting 500+ stars on your repository! I love that you took the initiative to turn these concepts into a runnable Python tutorial.
good preview, but felt more of a tutorial on when to use what primitives, or clarity on Claude Code documentation. Where can i reference more examples of agentic guardrails, like the UI verify-frontend-change example, which can be used in /goals or Dynamic workflows??
The stopping-conditions point is underrated. I've seen teams delegate agent work with vague success criteria like 'make it better' and then spend more time reviewing than they would've spent doing it themselves. What's worked for us is writing the stopping condition as a test the agent runs against itself before handing back control, basically forcing it to self-certify against a checklist rather than just stopping when it feels done.
As always, pragmatic, realistic, and actionable article. Thank you Addy!
Loops are IMO not worth the hype, just as long-horizon agents. They’re often advertised as the hammer that makes everything a nail. In my experience, most work I do is 80% research, understanding, exploration, only the last 20% are the parts that could potentially profit from loops.
First, I need to explore, understand the constraints, form my goal, then the agent can do the easy part. Whether it’s turn-based or looping is not a huge difference for most tasks, for some it is, that’s where loops shine.
Loops today are basically what telling GPT 3.5 „continue“ was yesterday. It‘s the continuation to fulfilling an instruction (initial prompt or initial goal).
Agents can not „keep going until this UI design is good“ because the goal is vague. However, just as I was reading that, I had the idea of an LLM judge board with, say 10 judges, of a few different models (e.g., Claude Opus, GLM 5.2, Kimi K3, DeepSeek V4, …) all score 1-10, the goal could be to score 8+. I‘d be interested in testing whether that yields results that are worth the token overhead.
Hi Jens, thank you for the kind words! I completely agree with your 80/20 breakdown. This ties right back into the core idea of the article: we simply cannot delegate our judgment. Loops are a useful tool for execution, but they certainly aren't a silver bullet.
Your idea for an "LLM judge board" is interesting. Using an ensemble of models (Claude, DeepSeek, etc.) to establish a consensus score is a pretty good way to try and quantify subjective goals like "good UI design." It effectively creates a dynamic stopping condition where one didn't exist. The token overhead would definitely be high, but as inference costs continue to drop, experiments like that become increasingly viable. I’d love to hear how it goes if you end up testing it!
Thanks for writing this up. Running five to ten in parallel is the part that scales worst, stopping conditions are per loop but your attention is not.
I turned these concepts into a runnable tutorial using Python, now with 500+ GitHub stars: https://github.com/hardness1020/awesome-agent-architecture/tree/main/sections/21-loop-engineering
Thanks for the comment! Figuring out better UX patterns for agent supervision and interruption is going to be a massive challenge for the industry moving forward.
Also, huge congratulations on hitting 500+ stars on your repository! I love that you took the initiative to turn these concepts into a runnable Python tutorial.
good preview, but felt more of a tutorial on when to use what primitives, or clarity on Claude Code documentation. Where can i reference more examples of agentic guardrails, like the UI verify-frontend-change example, which can be used in /goals or Dynamic workflows??
The stopping-conditions point is underrated. I've seen teams delegate agent work with vague success criteria like 'make it better' and then spend more time reviewing than they would've spent doing it themselves. What's worked for us is writing the stopping condition as a test the agent runs against itself before handing back control, basically forcing it to self-certify against a checklist rather than just stopping when it feels done.
Really impressive how u break out the loop engineering topic.
Thank You!