One-shot prompting is a loop of length one. That is fine for “what is the capital of Idaho.” It is a bad architecture for anything you would assign to a junior hire.

A loop is:

  1. Plan — propose steps against the spec
  2. Act — one bounded step (write, fetch, edit, test)
  3. Critique — compare the result to acceptance tests
  4. Retry or stop — change one variable, or ship, or escalate to a human

Agents are interesting because they can run this loop with tools. They are dangerous because they can run it past the point of taste or safety.

Why loops beat longer prompts

A longer prompt tries to prevent every failure in advance. The world does not fit in a preamble. Loops sample reality: the page 404s, the test fails, the tone is wrong, the number does not match the CSV.

Critique is the load-bearing step. Without it you have no eval — a generator with a steering wheel sticker.

A loop you can run by hand today

You do not need a product named Agent.

  1. Paste the spec. Ask for a plan only (no files changed).
  2. Approve or cut the plan.
  3. Ask for step 1 only.
  4. Run your acceptance tests (checklist, script, eyeball against the brief).
  5. Write a critique: “Test 3 failed because X. Fix X. Do not restyle the rest.”
  6. Repeat until tests pass or you hit a retry budget (e.g. 3).

That is an agent loop with a slow clock. Automating it is optional.

Retry budgets

Unbounded retry is how you get a $40 API bill and a confused repo.

JobSuggested budgetWhy
Copy edit2 critiquesDiminishing returns on commas
Research table3 fetches / 2 rewritesSources run out
Codeuntil tests pass or N minutesTests are the critic
Image4 gens then change the briefThe brief was wrong, not the seed
Purchases / payments0 unsupervised retriesPay, Buy

Write the budget in the spec. “If still failing after 3 critiques, stop and list blockers.” Agents that cannot stop are not autonomous. They are stuck.

Who plays critic?

Options, cheapest first:

  1. You with a checklist (still the gold standard)
  2. The same model with only the spec + artifact (no extra flattery)
  3. A second model family as a reviewer (catches house style of the first)
  4. Software — tests, linters, link checkers, typecheckers, price scrapers

Do not let the actor grade its own homework and change the spec to match. Frozen spec, moving output.

Plan quality

Bad plans are vague (“research the market, then write insights”). Good plans name artifacts:

  • “Extract pricing from URL A into table.md”
  • “Diff draft.md against SPEC acceptance tests 1–4”
  • “Open a PR; do not merge”

If the plan cannot be ticked, it is chat in disguise. Send it back.

Act in thin slices

Prefer a loop that produces a diff you can read over a loop that rewrites the universe. Thin slices:

  • One file at a time
  • One table at a time
  • One function at a time
  • One URL at a time

Computer-use agents that click 40 sites before you blink are still doing slices internally. Your review should look at the trace, not the vibe. Agents in 2026.

Stop conditions (copy these)

Put at least one in every spec:

  • Tests pass
  • Artifact matches the template
  • Human said “ship”
  • Retry budget exhausted
  • Tool error repeated twice
  • Spend cap hit
  • The agent wants to do something not in the plan

“Use your judgment” is not a stop condition. That is how you get surprise refactors.

Loop anti-patterns

  • Plan-act-act-act with no critique
  • Critique that only says “looks great!”
  • Retry that changes the spec to make the failure go away
  • Parallel agents editing the same file
  • Hiding tool traces so you cannot see the lie

Where to go next