How to Build an Agent Loop Without Becoming the Bottleneck

What a loop actually is

An agent loop is act, observe, decide, repeat. The agent takes an action: writes code, calls a tool, edits a file. It observes the result of that action: a test output, a compiler error, a rendered page. It decides what to do next based on that observation. Then it repeats, using the new state as the starting point for the next action.

That's the whole mechanism. What separates a working loop from a demo that falls apart on the third iteration is what surrounds those four steps: what the agent is allowed to act on, what counts as a valid observation, and when it's supposed to stop.

A single prompt-response pair isn't a loop. It's one act with no observation and no decision. The loop only exists once the agent's own output becomes an input to its next decision, which is also exactly where things go wrong if nothing outside the agent ever checks that output against reality.

The five building blocks

Every working loop needs the same five pieces, whether it's a coding agent, a research agent, or a support triage bot.

Goal. A concrete definition of done, not a vibe. "Improve the onboarding flow" isn't a goal a loop can terminate against. "Reduce the signup form to 3 fields and keep validation passing" is.

Tools. The actions the agent can actually take: read a file, run a shell command, call an API, query a database. The loop is only as capable as its tool set, and it's only as safe as the constraints on that tool set.

Context. What the agent can see at each iteration: the current file state, previous errors, relevant docs, prior decisions. Context has to be curated, not dumped: a loop that re-reads the entire codebase every turn burns tokens and drifts off task.

Stop condition. The check that ends the loop. Good ones are verifiable by the loop itself: tests pass, the build is green, a checklist is empty. Bad ones require someone to eyeball the result and guess.

Verification. The mechanism that tells the loop whether the last action moved it closer to the goal. This is where most tutorials wave their hands and say "run the tests." Tests catch regressions. They don't catch a UI that technically renders but looks wrong, a copy change that's factually correct but off-brand, or a flow that works but confuses a real user. That gap is exactly where a human checkpoint has to sit (see below).

Four loop types

Not every loop looks the same. Four patterns cover most of what's actually running in production right now.

Single-agent task loop. One agent, one goal, iterating against its own output until a stop condition is met. This is Claude Code or Cursor working through a ticket: edit, run tests, read the failure, edit again.

Multi-agent pipeline. Separate agents handle separate stages: one plans, one implements, one reviews, passing structured output between them instead of one agent doing everything. Failures compound across stages if the handoff format is loose.

Supervisor-worker loop. A coordinating agent dispatches subtasks to worker agents and merges results. Useful for parallelizable work (multiple files, multiple test suites) but needs a clear merge strategy or you get conflicting edits.

Human-gated loop. Any of the above, but with an explicit pause where a person has to approve before the loop continues to the next stage, usually before a deploy, a merge, or a customer-facing change. This is the pattern most teams actually need and most tutorials skip, because it's the one that doesn't fit neatly into a diagram of boxes and arrows.

Why loops stall without a human checkpoint

A loop that only verifies against tests and linters will happily ship code that passes every automated check and is still wrong. Tests don't know what the button should say. They don't know the layout looks cramped on mobile. They don't know the flow contradicts what the user actually asked for. Only a person looking at the running thing catches that.

So the loop needs a human checkpoint. The problem isn't adding one: it's that most teams add it the expensive way. Someone opens the preview, clicks around, finds five things wrong, and then has to translate each one into something the agent can act on: which element, what's wrong, what should happen instead. That translation step is where time actually goes, and it's the step nobody talks about when they say "just have a human review it."

Here's the part that makes this worse as loops get faster. Speeding up the loop doesn't reduce the number of times a human has to look: it increases it, because the loop now produces ten iterations where it used to produce one. The bottleneck doesn't disappear when the loop gets faster. It moves to whoever's doing the reviewing, and it moves there faster than they can keep up.

Making review one click, not one afternoon

The fix isn't reviewing faster. It's making each review produce something the next loop iteration can act on directly, with no translation step in between.

That means the checkpoint needs three properties. It has to happen on the actual running artifact, not a description of it: a live preview, not a screenshot pasted into Slack. It has to capture the specific thing that's wrong at the point of clicking, not require someone to write a paragraph explaining which element they mean. And its output has to already be in a shape the agent can consume (a selector, a screenshot, a comment), not a Slack message someone has to re-read and retype into a prompt.

When review works this way, one click on the live preview becomes a structured note: what element, what's wrong, what page, what the browser looked like when it happened. The next loop iteration reads that directly. There's no human sitting between the feedback and the fix, translating one into the other.

Where Patchrooms fits

Patchrooms is the human checkpoint for an agent loop, built so review doesn't become the thing that slows the loop down.

Drop one script tag into any preview, staging, or local build. Anyone (no account needed) clicks an element on the running page and leaves a comment, typed or voice. Patchrooms captures the DOM selector, a screenshot, the page URL, the viewport, the browser, and any console errors at that moment, and bundles it with the comment.

That report doesn't sit in a dashboard waiting for someone to manually relay it. "Copy agent feedback" turns it into a Markdown prompt block (selector, goal, constraints, screenshot reference) ready to paste into Claude Code, Cursor, Lovable, v0, or Bolt. Or skip the paste entirely: the MCP server lets the agent call `list_reports` and `get_report` directly, read the screenshots inline, fix the issue, and call `set_status` to close it. No account and no cloud dependency required either: local mode runs the same capture with zero network requests and exports straight to Markdown or JSON.

Others show feedback to a person. Patchrooms turns it into an instruction your agent runs. That's the difference between a human checkpoint that stalls the loop and one that keeps it moving.