Anthropic's Getting Started with Loops session offered four sensible instructions for AI coding work: define what done means, set a budget, add a checkpoint and fix a loop that will not stop.

This is useful advice. A runaway agent is not a development method, and motion is not progress.

Still, I was surprised that the lesson felt novel enough to need rediscovery. Anyone who has spent time in serious product development should recognise its shape. Decide what valuable progress looks like. Work in a bounded cycle. Inspect the result. Learn. Adjust. Repeat.

Software teams have been refining that pattern for decades.

I should disclose my interest before I go further: I created Agile Iteration Method, or AIM. I am not a neutral observer when I argue that AIM is a good way to organise AI-assisted delivery. The links are here so you can test the argument rather than take the founder's word for it.

The useful part of the new loop enthusiasm

AI agents make iteration unusually cheap. They can inspect a repository, make a plan, edit several files, run tests, read the failures and try again without waiting for another meeting or another morning.

That speed creates its own temptation. If the agent can keep going, why not let it keep going?

Anthropic's answer is practical: give the loop a finish line, a budget and a checkpoint. Those constraints make an agent easier to operate. They also expose a truth that can disappear behind impressive demos: the operator still has to decide what counts as useful work.

A technically flawless loop can optimise the wrong thing. It can complete a task that never should have been selected, quietly widen the scope, accept weak evidence or polish an internal component while the user-visible outcome remains broken.

Stopping correctly matters. Choosing and governing the work matters more.

Agile already knew the shape of the work

The principles behind the Agile Manifesto call for early and continuous delivery of valuable software, frequent delivery of working software and regular reflection followed by adjustment. The manifesto was written in 2001, but the underlying learning is older than the document.

The Scrum Guide makes the cycle almost comically plain: select work toward a product goal, create an increment of value, inspect the result with stakeholders, adjust and repeat. Its empirical pillars are transparency, inspection and adaptation. Its retrospective closes the sprint by asking how quality and effectiveness can improve.

None of this makes Anthropic's advice wrong or unimportant. Quite the opposite. It explains why the advice works.

The frustrating part is the amnesia. The AI industry sometimes talks as if iteration arrived with autonomous agents. It did not. Agents changed the speed, cost and scale of the loop. They did not remove the product questions that decades of agile practice were built to answer.

A loop cannot decide what deserves to exist

A loop describes motion: observe, act, inspect, repeat. A delivery method has to describe authority.

Who owns the outcome? Who is allowed to change direction? What is the smallest end-to-end result that a real user can evaluate? Which evidence proves it works? Who looks for failure with enough independence to challenge the builder? Who accepts the result and carries the consequence if it is wrong?

An agent prompt can contain answers to some of those questions. But when the work lasts longer than one session, crosses tools or reaches production, implied answers become dangerous. The system needs a visible delivery position: the agreed outcome, active increment, current role, passed gate and unresolved review findings.

Otherwise an agent can repeat perfectly while the project drifts.

This is why I do not think the next breakthrough is a cleverer infinite loop. The important work is giving fast agents the same things good teams need: a shared goal, boundaries, decision rights, independent inspection and a human acceptance point.

What AIM puts around the motion

AIM packages that discipline for repository-based AI work.

The Product Owner protects the outcome and approves consequential decisions. The Technical Delivery Owner turns that outcome into one testable, end-to-end Done Increment. Dev implements it. Reviewer tries to break the result and tests the evidence. The TDO reconciles what was built with what was promised. Acceptance returns to the Product Owner.

The resulting cycle is short:

PO → TDO → Dev → Reviewer → TDO → PO

The point is not the arrows. The point is that every handoff carries a different responsibility.

AIM also keeps the active delivery state with the repository. The Epic, increment, role, gate, decisions and review evidence do not have to be reconstructed from a model's conversational memory. An agent can resume from an inspectable checkpoint instead of inventing a plausible history of the project.

That is what turns an agent loop into governed delivery. The AI still performs most of the motion. The human keeps the decisions that carry value, risk and public consequence.

Anthropic is now taking an important step in this direction with Dreams, a research-preview feature that lets Claude reflect on past sessions, reorganise accumulated memory, merge duplicates, replace stale or contradicted entries and surface new insights. That is good development. It recognises that an agent needs more than the immediate turn in front of it.

What surprises me is that managed reflection was not central from the beginning. In product development, learning from a completed cycle is not an advanced option. It is how iteration becomes improvement.

Reflect turns that idea into a full retrospective

A full agile iteration does not end merely because the increment shipped. It ends by learning how the next iteration should be better.

That is the role of AIM Reflect. It is the natural final step of a completed AIM cycle: inspect what actually happened, compare proposed lessons with current repository evidence, preserve provenance and let a human decide what deserves to become durable guidance.

In other words, it is a modern retrospective for a team in which AI agents do much of the execution.

This distinction is important. A transcript is not automatically a lesson. It contains guesses, dead ends, temporary compromises and instructions that may have been superseded. Reflection turns experience into a reviewable proposal. Evidence and human judgement decide whether that proposal should influence the next iteration.

I find it remarkable that this capability has arrived so late in the wider conversation about AI product development. Continuous improvement is not an optional memory feature bolted onto delivery. It is one of the things that makes iteration a method instead of repetition.

Within AIM, Reflect now feels exactly where it belongs: after a full increment has been reviewed and accepted, when the team has real evidence to learn from.

Build on the history instead of rediscovering it

Anthropic should keep developing its thinking about loops. Clear operational guidance helps more people use agents safely and effectively. There is no virtue in rejecting a useful idea because the idea is familiar.

But the next step should not be to treat each old product-development lesson as a new AI primitive. The industry can move faster by recognising that software delivery already has a history. Goals, increments, definitions of done, inspection, adaptation, retrospectives and accountable product ownership are not baggage from a slower era. Faster agents make them more necessary because mistakes and drift can now compound at machine speed.

The loop is worth learning. Then place it inside a method that knows why the work exists, who may decide, what evidence counts, when the result is done and how the team becomes better afterward.

Anthropic does not need to cross the river to fetch those ideas. They are already waiting in agile practice.

Or, if you prefer, in AIM.