Agent loops are useful when the task has something to check against.
They are not just agents that run on a schedule, and they are not long prompts with more instructions stuffed into them. The useful version gives the agent a goal, a set of sources, and a check it has to pass before you treat the work as usable. If it fails the check, it tries again. If it still fails, it stops and tells you what failed.
Most people are still using AI in a prompt-shaped way. The usual interaction is a set of small requests like summarise this, rewrite that, compare these notes, draft this email. Sometimes that is all you need, but a lot of knowledge work already has a standard you would check against manually. If the task has a hidden checklist, a one-shot prompt is probably the wrong shape.
A prompt can ask for a project update. A loop reads last week's update, checks the task board and meeting notes, drafts the new version, then checks whether the decisions, risks, blockers and owners are covered. If something is missing, it goes back through the sources. If it still cannot find the answer, it leaves the gap visible instead of writing around it.
Why code got there first
Business Insider reported last week that Boris Cherny, the creator of Claude Code, has been talking less about writing prompts directly and more about loops that coordinate Claude. OpenAI engineer Peter Steinberger made a similar point about designing loops that prompt coding agents rather than prompting the agents yourself.
The coding version is easy to understand because the feedback is clean. An agent changes code, runs a test, reads the error, changes the code again, and keeps going until the check passes or it gets stuck. The environment pushes back in a way the model can use.
Knowledge work does not usually have that luxury. A report can be fluent and still miss the only number anyone cared about. A research summary can be well-written and still ignore the source that undermines the conclusion. A policy draft can read perfectly and still fail because nobody checked it against the current process. The lesson from coding is not that every job becomes software development, but that the quality of the loop depends on the quality of the check.
The work checking itself
Anthropic's agent guidance has a useful pattern called evaluator-optimizer, where one pass produces an answer and another evaluates it before feeding improvements back into the next pass. That sounds technical, but the idea is familiar if you have ever reviewed a board paper, a proposal, a policy, a project update or a research note.
You are rarely judging the prose alone. You are asking whether the work has covered the right ground, used the right sources, separated evidence from assumption, and made the remaining uncertainty visible. That judgement is usually informal. It lives in the head of the person who knows the work. Agent loops force some of that judgement out into the open.
For a research brief, the check might be whether every claim links back to a source, whether opposing evidence has been included, and whether old news has been separated from new developments. For a vendor comparison, it might be whether pricing, lock-in risk, implementation effort and support burden have all been handled. For a monthly performance pack, it might be whether the numbers reconcile with last month's version and whether any unexplained movement has been flagged.
None of this requires the agent to be a genius. It requires the task to have a definition of good enough, preferably one that is written down before the agent starts.
Not just automation
The easy mistake is to hear "loop" and think of automation. Something starts every Monday, reads a folder, writes a note and posts it somewhere. That can be useful, but the schedule is not the interesting part. The useful design question is what should happen when the first draft fails the check.
Should the agent reread the sources, search for missing context, compare against a previous version, ask a person, or stop completely? A lot of current AI work skips that question. It asks for an output and then leaves the human to discover whether the output is any good.
That is fine for low-risk work and weak for anything people rely on. A better loop might gather the evidence, produce the output, check it against the criteria, retry once, then return the output with any failed checks still visible. I would rather see those failed checks than read a polished answer that has quietly guessed its way through the missing parts.
A grounded example
Take a policy review. It could be an HR policy, a procurement process, a data-handling standard or an access review in an IT team. The domain matters less than the shape of the work.
The prompt version asks the agent to review the document and suggest improvements. The loop version gives it a checklist and asks whether the policy matches the current process, whether every mandatory section is present, whether responsibilities are assigned to real roles rather than vague teams, whether links and approval references still work, and whether suggested wording has been separated from factual uncertainty.
If the agent cannot verify something, it should say so. If it finds a conflict, it should show the sources. If the checklist still has gaps after the retry, it should return the gaps rather than producing a tidier draft.
That is the pattern I think translates across knowledge work. The output can be a report, a briefing, a spreadsheet, a proposal, a research note or an operational review. The loop matters when the first answer is not enough and the task has a standard the agent can test against.
Karpathy's warning helps
Andrej Karpathy has been more cautious about agents than the marketing version of the story. Business Insider reported his view that current agents are not ready to run loose, and his follow-up point is the useful one for this discussion. Agents should use the right docs, show evidence, make fewer assumptions, and ask when they are unsure.
That fits the loop argument better than the hype does. A loop without evidence is just repeated guessing. A loop without a stop condition is a token bill with ambition. A loop without a human checkpoint is risky anywhere the judgement is political, commercial or operational rather than purely mechanical.
The responsible version is bounded. Give the agent sources, a check, and a retry limit. Make it show what it could not prove.
Where I would start
I would start with work that already gets reviewed by a person today. Project updates, research briefs, meeting packs, policy reviews, vendor comparisons, risk registers, change summaries and monthly reporting all have the same basic shape. The first draft is only half the job because someone still has to ask whether it is complete, current and safe to use.
The first loop can be very small. Gather the evidence, produce the draft, check it against the criteria, retry once, then return the output with any failed checks. You do not need a grand agent platform to learn from that. You mostly need to know the work well enough to say what good looks like.
This is where I think the shift from prompts to loops becomes practical. The question stops being "how do I ask the AI better?" and becomes "what would I check before trusting this?"
That is a healthier question for knowledge work. It keeps the human in the place where humans are still needed, but it stops wasting them on the first messy pass.
If I cannot name the check, I would keep it as a prompt.
If you're working out where agentic loops should live inside your operational stack, knowledge workflows or AI adoption plans, that's the kind of architecture work I do. consulting@joshwickes.com