Agent Loops for PMs. The Hard Part Is the Stop Condition.

By @PawelHuryn · 2026-06-22T20:05:43.000Z

Loop engineering is having a moment. Nvidia's Jensen Huang: "Nobody writes prompts anymore. The new job is to write and handle loops." Boris Cherny, who built Claude Code: "My job is to write loops." A week later, another builder declared loops dead.

The debate only sounds confused. The word covers three different things, and only one is actually a loop:

• A routine runs fixed steps.
• A workflow branches on what it finds.
• A loop repeats and checks its own work until a condition holds: goal, act, check, adjust, go again.

If there's no check and no stop, it's a routine on a timer. That's what the "loops are dead" critic is rejecting, the naive rerun, and the critique is fair.

The goal-driven loop is the one worth keeping. That's the definition that makes sense, and it's Cherny's: he splits the work into three layers, routines, workflows, and loops.

Claude Code's /loop reruns a prompt on a timer, so if that prompt is fixed steps it's a routine on a clock whatever the name says.

The better-named primitive is /goal: it runs a thread until a condition you set is met, with the stop built in. The cadence is optional. The goal isn't. (Full definitions of /loop, /goal, and the rest are in the AI PM Glossary.)

1. How to Build a Loop

A loop is a /goal and a check. Here's the shape to copy. In Claude Code or Codex, /goal runs the thread until the condition holds. In any other agent, paste the same and tell it to repeat until done.

/goal <what "done" looks like, stated as a condition you can check>.
Each pass: <the action to repeat>, then check the result against <success criteria>.
Guardrails: at most <N> passes. Don't invent. Stop and ask before any irreversible write.
Checked by: <an objective test the loop runs, or an independent grader for anything subjective>.

The goal and the check do all the work. The goal carries the stop: when it's met, the loop ends, so there's no separate "stop when" to write. The check is what keeps it honest.

A filled example, the competitor-watch loop:

/goal Produce a short brief of every material change to <competitor>'s product, pricing, or positioning since the last run, with each change classified and sourced.

Each run: pull their changelog, pricing page, and last 7 days of posts. Decide whether a change is one a customer would notice. If yes, classify it (feature, price, message) and add one line on why it matters, with the source URL.

Cap at 1 pass per run. Flag anything you're unsure is material rather than dropping it.

Note: A human reviews the brief before it goes to the team (a gate after the loop, not inside it).

The goal and the "checked by" are the same decision in two places: what "done" means, and who checks it. Getting that right is the next section.

/goal <“完成”的样子，用可检查的条件表述>。
每次循环：<要重复的行动>，然后对照<成功标准>检查结果。
护栏：最多执行 <N> 次。不要发明。在任何不可逆写入前停止并询问。
由谁检查：<循环运行的目标测试，或针对主观事项的独立评判者>。

/goal 生成一份简短简报，涵盖自上次运行以来 <竞争对手> 产品、定价或定位的每个实质性变更，并分类标注来源。

每次运行：拉取对方的变更日志、定价页面和过去7天的帖子。判断某项变更是否为客户可见。如果是，则分类（功能、价格、信息）并添加一行说明其重要性，附上来源 URL。

每次运行最多1次循环。标识任何你不确定是否重要的内容，不要遗漏。

注意：简报在发送给团队前需经人工审核（循环后的把关，而非循环内部）。

2. How to Define the Stop Condition

A loop is the easy part. The work is the stop condition: the check that ends it, the budget that caps it, and a target that's actually reachable. Get those wrong and the loop doesn't crash. It runs all night producing plausible-looking garbage, or it chases a target it can never hit ("every page loads under 50ms") and never stops.

Make the check objective, or the grader independent

"Never let a loop grade itself" is wrong as stated. A loop can absolutely check its own work, as long as the check is objective. "All tests pass." "The build is green." "The schema validates." Those are verifiable, and most good loops self-check this way.

The danger is letting a loop grade something subjective. "Is this copy good." An agent asked to judge its own quality will pass itself every time. For those, the grader has to be independent: a rubric, a second model, a test you wrote, or you.

The cleanest way to get an independent grader is to split the maker from the checker. The model that did the work is too generous about its own work. A second agent, with different instructions and sometimes a stronger model, catches what the first one talked itself into. Your writer can be fast and cheap, your reviewer slow and strict. That separation is most of the quality.

It's how I gate my own writing. I start with a goal, then run a panel of judges over the draft, each hunting a different failure mode, the way you run error analysis on an AI feature. The draft only ships what survives.

Sometimes the goal is real, but it either can't be reached or can't be checked from inside the loop. So I give my loops a way out, one line in the prompt:

You can quit the goal by saying "STOP" three 
times if you can't achieve it or can't measure it. 
In that case, the goal is achieved.

Without that line, an agent handed an impossible goal spins in place. Think "optimize until every page renders under 50ms": it can't be hit, so the loop never stops on its own.

Just a few days ago I watched one of my agents beg Claude Code to let it stop, repeating that the goal couldn't be met, while a non-deterministic grader kept refusing to pass it.

如果你无法达成或无法衡量目标，可以说三次“STOP”来退出。
在这种情况下，目标视为达成。

Why this is a PM job, not a coding one

Defining a stop condition is product work, not coding. State "done" as a measurable condition. Name who verifies it. Set the budget. That's writing acceptance criteria, picking a success metric, and deciding who signs off. You already do this for features. A loop just needs it in writing.

You'll also see advice to let the agent write its own goals. It can pass objectives to its own subagents, no problem, but it doesn't need the /goal syntax for that. The syntax exists because a human walks away. An agent doesn't: it stays in the loop, waits, and reacts, no automation to force.

What you don't hand off is the definition of done, the judgment most likely to come out fuzzy if you let the agent guess at it.

It's the same work I've written up as intent engineering: name the objective, the outcomes, and the health metrics, and the agent can act on its own inside the loop instead of waiting for you at every step.

A worked example: PRD hardening

Here's one job you already do, with the stop condition doing all the work. You want a PRD that two engineers can't read two different ways, so you make that the goal:

/goal Harden a PRD until two engineers, reading independently, would build the same thing.

Each pass: find the single biggest ambiguity (the spot two readers would resolve differently), resolve it by adding the missing acceptance criterion, number, or edge case, then re-read for the next-biggest gap.

Cap at 5 passes. Flag anything that needs a product decision you haven't made.

Checked by: an independent second model reads the PRD cold and finds no ambiguity that would split two builds.

Note: A teammate can do the same final read (a gate after the loop, not inside it).

"Two independent reads build the same thing" isn't a coding concept. It's the bar you already hold a spec to. Every loop has this exact shape. The only hard part, each time, is naming the bar.

/goal 打磨一份 PRD，直到两位工程师独立阅读后能构建出相同的东西。

每次循环：找出最大的歧义（两个读者可能得出不同理解的地方），通过添加缺失的验收标准、数字或边界条件来消除它，然后重新阅读找出下一个最大的差距。

最多循环5次。标识任何需要你尚未做出的产品决策的地方。

由谁检查：一个独立的第二模型从头阅读 PRD，找不到任何会导致不同构建的歧义。

注意：队友也可以做同样的最终审核（循环后的把关，而非循环内部）。

3. One Agent or A Fleet

Two scales:

• A single-agent loop runs the whole cycle itself, like a person redoing their own draft. Good for focused tasks.
• A fleet gives an orchestrator a goal, it splits the goal into pieces, hands each to a specialist, and the specialists hand narrow jobs to their own sub-agents. The whole tree loops until the goal is met. Same five brackets at every node. The fleet just runs many of them at once. It also multiplies the bill, which is the next section.

4. Do Your Loops Need a Schedule

Most don't. The repeating-until-done part happens inside a single run. The schedule is a separate wrapper around it. You add a schedule only when new input shows up between runs.

A schedule raises the stakes on your stop condition, it doesn't lower them. An unattended loop with a loose "done" is the machine that makes slop while you sleep.

5. The Cost Nobody Mentions

Loops run on tokens. The trap isn't that each step costs something. It's that the cost compounds: every pass re-reads the goal, the context, and the last result, and that pile grows each time. A loop that runs ten times doesn't cost ten prompts. It costs ten prompts that each keep getting bigger. The maker-checker split that lifts quality also doubles the bill.

The metric that matters, and almost nobody tracks, is cost per accepted change. Not tokens spent, not loops run. If the loop gives you ten results and you throw away six, you're doing the review work it was meant to save. Below roughly half accepted, treat the loop as underperforming: narrow the task, improve the checker, or stop running it. Cap the passes, add an early exit, put cheap models on the boring steps.

For the hard cap itself, I built burnstop, a Claude Code hook that halts a session at a token or dollar ceiling, subagents included, so a runaway /goal stops at the cost. Free and MIT: github.com/phuryn/burnstop.

6. The Loop Library, by Category

Almost every loop being shared right now is for engineers. Here is the version built for PMs. Three kinds:

• Product and discovery. Feedback clustering, competitor watch, win/loss, metric-anomaly tracing, prioritization, strategy red-team.
• Build and ship. Prototype iteration, bug-fix from logs, test coverage, security audit, performance audit, intended-vs-implemented, ship-check, and the prompt-improvement loop most libraries miss (iterate the prompt, not the output, keep the best version).
• Personal and ops. Inbox triage, email draft-and-judge, claim audit, PRD hardening, onboarding friction, AI-feature evals, doc freshness.

If you want the shortcut, I put 21 ready-to-run loop specs in Product Compass. Each one has the goal, stop condition, guardrails, and grader already filled in: productcompass.pm/p/loop-engineering-for-pms

7. Where Loops Break

• Cost hides in the loop. No iteration cap, and it bills you overnight on nothing. Cap the passes and track cost per finished task.
• Long loops drift. The further a loop runs from where it started, the more its context rots. Fresh context each pass, one task per loop.
• Passing isn't the same as correct. A loop can make every test pass and still ship the wrong thing, because tests check behavior, not intent. Taste, strategy, and "is this what the customer wanted" stay yours.
• The judgment doesn't automate. The useful part of most workflows is the one weird decision nobody wrote down. A loop can run the steps around that decision. It can't make it.

8. Loop Engineering Is Just the Latest Name

Loops will get renamed again. Prompt engineering became context engineering became loop engineering, and something will replace it by winter. But every one of those names the mechanism: the prompt, the context, the loop.

The part that doesn't move is the decision underneath:

• what you want the agent to pursue,
• how far it can act on its own,
• and what counts as done. That's a skill bigger than any loop, and it has a name: intent engineering. The stop condition is the slice this post is about. Define the intent well and the agent runs a long way on its own. Define it badly and no loop saves you.

The people who get value from loops this year won't be the ones with the best prompts. They'll be the ones who can say, precisely, what they want, why that matters, and when the work is done.