Loop Engineering: Why a Major Part of the Agent Cycle Is the Right to Say No (Category AI4SDLC)
Tonight, 16:00 In Moscow, we will discuss the stream with Maxim Smirnov materialLoop Engineering: The Anthropic Playbook for Designing Systems That Prompt Your AgentsSo I had to prepare and read it beforehand:) Below I will leave a short press, and for the expanded version come on stream.
To begin with, it was difficult for me to understand the status of the article - despite the title and layout under the IEEE, it is not an Anthropic article or an IEEE publication. At ASIXIV material appeared 25 June 2026 PDF directly calls itself an independent revision of the HuaShu guide in conference article format. Basically-- Addy OsmaniAnthropic Engineering Blog and Stripe Public Case. There’s no review information available, so I’d read the text as a hands-on playbook that has yet to be verified on my system.
If you take out another one. xXx Engineering From the title, the main thesis is simple: the next step is not to manage one run of the agent, but to design a system that finds the work itself, gives it to the agent, checks the result, saves the state and decides when to start again.
The article presents such a ladder of familiar concepts - Prompt engineering is responsible for one instruction; - Context engineering - for what the model sees now; - Harness engineering - for the binding, tools, limitations and criteria for completing a single launch; - Loop engineering Repeated cycle over harness.
In one turn of this cycle, five movements:
- Search for work (discovery)
- Transfer of task (handoff)
- Verification of the result (verification)
- Preservation of condition (persistence)
- Planning for the next launch (scheduling)
They are implemented through planners, isolated git worktreeSkills with project knowledge, connections to external systems, subagents and state outside the context window. Individually, the details are not new. The new boundary of the system is that the person ceases to be a timer, who after each answer tells the agent what to do next.
And here comes the main engineering problem. An error in a prompt usually lives on one answer. An error within the loop can enter the status file, return in the next pass as an established fact, and become the basis for new changes. The longer the error goes unnoticed, the greater its range of damage. (blast radius). Therefore, the most valuable part of the cycle is not a mechanism that tells the agent to “work” again, but a mechanism that can say “no” in time.
The text separately focuses on the separation of the performer and the inspector. (generator/evaluator). The agent who has just written the code tends to be too lenient about his decision. The verifier must come with a different context and act: run tests, open an application, pass user scripts, check APIs, and compare behavior to task. Anthropic describes a similar bandage, but there the tester also had to calibrate: he missed errors and sometimes persuaded himself to accept a weak result. The second LLM is a useful independent role, but not yet proof of correctness.
Of the practical cases, the most notable is Stripe Minions: according to Stripe engineer Steve Kaliska, the system prepares for the process. 1300 machine-written PR per week. The final review is done by people, and reliability is based on isolated cloud environments, deterministic orchestration, tests and CI. This is an example of the scale of generation, but not a benchmark for quality: the PR number does not tell you how many defects have gone into the work environment or how much attention the inspection has eaten.
Cycle autonomy has four implicit problems:
- Duty of verification (verification debt) - accumulated unverified result;
- Loss of understanding (comprehension rot) lagging behind our mental model from the code base;
- Rejection of your own judgment (cognitive surrender) the habit of agreeing with the machine;
- Inflating token spending (token blowout) - uncontrolled repetitions. These problems reinforce each other: the more untested code we have, the worse we understand the system; the less we understand, the more willing we are to give it the following solutions.
The practical conclusion from the material I would formulate is this: the first cycle should be small and boring. For example, a daily analysis of a fallen CI or new tasks. It needs a permanent state, a separate checker, a tight limit on attempts and tokens, task isolation, and a human checkpoint before a merger. Parallelism should be increased only after the inspector has actually caught a few real errors, and not just never objected.
And expanded the same material we will discuss today with Maxim Smirnov on stream into 16:00. Come listen and ask questions.
#AI4SDLC #AI #Agents #Engineering #Architecture #Evals #Research