{"slug": "how-i-think-about-agentic-work-part-one-loops", "title": "How I think about agentic work, part one: loops", "summary": "Mark Phelps published a post on 27 October 2026 arguing that agentic engineering reduces to loops with explicit stop conditions, and that the human's position in the loop matters more than the loop's design. Phelps describes three loops he uses — a bug fix loop, a feature building loop, and a greenfield project loop driven by an orchestrator that runs many feature loops until a milestone is reached — and argues stop conditions can verify that work matches the request but not that the request was right, a judgment he says humans remain best at. He prefers being \"on the loop\" rather than \"in the loop,\" which he calls being \"a meat proxy\" that becomes the bottleneck as agents produce changes faster than a person can read them.", "body_md": "Building · 27 Oct 2026 · 6 min · ~1.3k words\n\n# How I think about agentic work, part one: loops\n\nThe loops I use to fix bugs, build features, and start projects with agents, and why I'd rather be on the loop than in it or out of it.\n\n6:24\n\nThe audio didn't load. [Download the MP3](https://assets.markphelps.me/content/posts/agentic-work-part-one-loops/audio/am_puck-9465e6f9fe0941aa.mp3) instead.\n\nHow I think about agentic work, part one: loops\n\n0:00 / 6:24\nEvery way I work with agents comes down to a loop, and the question I care most about is where the human sits in it. You’ve probably heard of [Ralph loops](https://ghuntley.com/ralph/), where an agent runs the same prompt over and over until the work is done. This isn’t about that. Well, in some ways it is, but here I’m writing about loops in the abstract. When it comes to automation and agentic engineering (having agents build your products and systems), loops are the process, the system, how things get done.\n\nA loop is just a thing that happens over and over again until a stop condition is met. I don’t think there is one true best way of orchestrating agents, and I’m not going to say my way is better than anyone else’s. There’s your way, there’s my way, there’s large company X’s way, etc. It’s all relative to how you prefer to work and what you’re building. That’s why I think everyone should spend time experimenting to figure out what loops work best for them and in what cases. For example, a loop to find and fix a well-scoped bug in existing (brownfield) software is different than one to plan and build a feature. And a loop to build a product from scratch is different still. These are the ones I’ve settled on so far.\n\n## Bug fix loop\n\nFixing a bug in existing software is the tightest loop. The problem is usually already scoped, so after a quick triage the agent can reproduce it, fix it, and prove the fix with a test before anything gets reviewed. If review turns up issues, it goes back to fix, not back to the start.\n\n## Feature building loop\n\nBuilding a feature is wider. It starts with a plan, which gets broken into tasks that agents can implement in parallel. Each task gets reviewed on its own, then the pieces are gathered and reviewed together. Anything found late sends the work back to implementation or to planning, depending on whether the code is wrong or the plan was.\n\n## Greenfield project loop\n\nBuilding something from scratch is a zoomed-out version of the feature building loop, meaning it’s driven by an orchestrator that uses many feature building loops until a certain state or milestone is reached.\n\nAgain, the thing every loop has in common is that it needs stop conditions. When is it “good enough” that we can exit the loop? Some of that the agent can check on its own. For a bug fix it’s fairly concrete: the failing reproduction now passes as a test, and the review comes back clean. For a feature, it’s that every goal in the plan has been met, which means every goal needs a way to check it. But a check only tells you whether the work matches what you asked for. It doesn’t tell you whether you asked for the right thing. That last call is a judgment, and for now I think humans are still the best judges of it.\n\n## In the loop, on the loop, out of the loop\n\n### In the loop\n\nBeing in the loop means you are a meat proxy. You are the toy chicken perched over the Enter key, pecking it over and over: accepting each change, approving each permission, merging each branch. The agent writes the code, and you move the process along. Being in the loop sucks, because the only thing that’s changed from a few years ago is that you no longer write the code. You still need to have your butt in the seat to get work done. Worse, you become the bottleneck. The agent can produce changes faster than you can read them, so you either slow everything down to your speed or start approving without really looking. At that point you aren’t adding judgment, just keystrokes.\n\n### On the loop\n\nOn the loop is the next level, and it’s where I’m most comfortable being today. The term isn’t mine. Kief Morris describes it in [Humans and Agents in Software Engineering Loops](https://www.martinfowler.com/articles/exploring-gen-ai/humans-and-agents.html): instead of checking every output, you build and maintain the harness (the specs, the checks, the workflow) that produces it, and when the output is bad you fix the harness, not the output. A lot of my time goes there: standards, linting, anti-slop hooks, test harnesses, CI.\n\nAfter you and the agent (and any stakeholders) agree on the plans, the agent drives everything until it is blocked in some way: either it has reached a stop condition or something else has occurred that requires a human. Depending on how much you trust the agent’s work and what your project needs, a human might review the code, or only step in at delivery.\n\nMorris already keeps humans in charge of what he calls the “why loop”, deciding whether the working software matches the idea. What I want to make explicit is delivery as its own step. Reviewing AI-written code is familiar by now, but what does it mean to deliver code? Isn’t that just merging and deploying? Yes and no. When I say “deliver” I mean “judge and act”. A human verifies that the work met the goals of the task or plan. If it didn’t, or something outside the loop changed, it’s up to the human to course correct and start the loop again. This is more than just pushing the merge and deploy button after code review. In most cases it means a human actually walking through and exercising the software. Seeing how it looks and feels. Does it meet the bar? Did it build the right thing? For all but the smallest changes, I firmly believe it still takes a human to answer those questions.\n\n### Out of the loop\n\nThis is the dream scenario (well, maybe not for everyone). This is when you get to sit on the beach and sip mai tais while AI does everything for you. You specify, and the agent builds and runs the process end to end, including delivery. The human isn’t really needed, except maybe to decide what to build and when. This is what [Dan Shapiro](https://www.danshapiro.com/blog/2026/01/the-five-levels-from-spicy-autocomplete-to-the-software-factory/) calls the “dark factory”. I wrote about [his levels in more detail](https://markphelps.me/posts/when-ai-writes-all-the-code/) recently.\n\nYou can already do this for some work, mostly the kind where you’re the only one who notices if it breaks.\n\nWhere I don’t think it holds up is software other people depend on. The higher the stakes, the more evidence you need that the software works and solves the right problem, and that’s where being out of the loop stops being sustainable. LLMs are very good at producing work that looks right, and they can approximate taste. But looking right and being right are two different things, and I don’t think a model can tell what feels right to the person using the software. As long as software is built for people to use, I want a person judging that before it reaches them.\n\n## Break;\n\nSo that’s where I’ve landed: on the loop. The agents run the loops, and I stay at the two ends of them, agreeing on the plan going in and judging what comes out. Software gets built, bugs get fixed, but I’m still in charge of the what, and generally the how. This post covered the loops: how work moves from a plan to something delivered.\n\nNext time I’ll get into the work itself: how the plans, tasks, and notes the loops run on should be structured as a graph. Yes, the loops are technically graphs too. Part two is about the shape of the work, not the shape of the process.", "url": "https://wpnews.pro/news/how-i-think-about-agentic-work-part-one-loops", "canonical_source": "https://markphelps.me/posts/agentic-work-part-one-loops/", "published_at": "2026-10-27 00:00:00+00:00", "updated_at": "2026-10-27 21:42:22.154323+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "artificial-intelligence"], "entities": ["Mark Phelps", "Ralph loops", "Geoffrey Huntley"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-i-think-about-agentic-work-part-one-loops", "markdown": "https://wpnews.pro/news/how-i-think-about-agentic-work-part-one-loops.md", "text": "https://wpnews.pro/news/how-i-think-about-agentic-work-part-one-loops.txt", "jsonld": "https://wpnews.pro/news/how-i-think-about-agentic-work-part-one-loops.jsonld"}}