Loop Engineering: The Overrated Cycle, The Underrated Topology

In our last issue of 5Y Capital's Signal Station 5Hz, we were still debating three possible futures for World Models. Today, a more "engineering-driven" concept — one much closer to the front lines of development — is heating up fast in Silicon Valley: Loop Engineering.

In early June, within the span of a single week, three people at different AI giants independently arrived at the same conclusion: "Stop hand-writing prompts for coding agents. Design the循环系统 that writes those prompts for you."

The first to spark the conversation was Peter Steinberger, author of the open-source project OpenClaw and now at OpenAI. His post blew past eight million views, and the message was blunt: You shouldn't be prompting coding agents anymore. You should be designing the loops that prompt them.

Almost simultaneously, Boris Cherny, who leads Anthropic's Claude Code, said the exact same thing. He no longer prompts Claude by hand. Instead, he has a cluster of loops running in the background that prompt it for him, deciding what to do next. His job is to write those loops.

On June 7, Addy Osmani — who previously led Chrome developer experience and now serves as Google Cloud AI Director — wrote this up as an article and gave it a name: Loop Engineering.

For the past two years, the AI world has spawned a new "XX Engineering" every few months. First came prompt engineering, whose courses are still selling today. Then context engineering, still debated. Then harness engineering, barely dry on the page... and now loop engineering arrives, stepping in time with model releases.

But all those previous "engineerings" were variations on the same premise: you sit at the keyboard, figuring out how to command the agent better. Loop engineering deletes that premise entirely. You're no longer inside the workflow — you stand outside the loop, building the loop itself.

Of course, the idea of "loop engineering" isn't new. Last summer, Australian developer Geoffrey Huntley wrote about his approach in a blog post, naming it "Ralph Wiggum" — after the dim-witted, optimistic, relentlessly persistent kid from The Simpsons. You take a not-especially-bright agent, lock it onto a task, and let it bash away until it breaks through. It worked okay back then. It works much better now.

What's changed is that model capabilities have crossed a threshold. Coding agents can now run unsupervised through genuinely non-trivial tasks. You used to have to spell out every edge case in the prompt; now they mostly figure it out themselves. Scheduling and orchestration commands have entered mainstream agent runtimes. The parts are all here, so naturally everyone is pivoting to assembling them into complete systems.

At the end of June, we invited a group of frontline researchers and founders to discuss this together — another closed-door session at 5Y Capital Signal Station 5Hz. Today's article is split in two: the first half is our synthesis of loop engineering — what it is, and why it matters.

The second half captures the more interesting voices from that private session: when everyone's talking about "loops," what are the people actually pushing models to their limits thinking about in private?

What Is Loop Engineering

For the past two years, coding agents worked like this: craft a good prompt, load up context, hit enter, get an answer, hit enter again. The agent was a tool; you held it the entire time, round after round.

Loop engineering swaps in a small system. It finds its own tasks, dispatches them, checks the results, records what got done and what's next, then decides the following step. You have this system nag the agent, not you nagging round by round.

Addy Osmani stacks these layers like a building: at the bottom, your instructions to the agent (prompt); above that, the background material you feed it (context); above that, the full runtime environment a single agent needs to operate (harness). The loop sits atop all of this, making everything below run automatically, again and again.

A year ago, running such a loop meant writing a mountain of scripts, maintaining them daily, and mostly using them yourself with no easy way to hand them off. Now these components are built directly into products.

A loop, broken down, cycles through five actions: discovery, dispatch, verification, persistence, and scheduling (from Loop Design: A Field Playbook for Agentic Systems).

The first action is discovery — essentially, finding its own work. In a chat window, you type tasks one by one; in a loop, the agent roams the codebase itself, picking out what needs handling: a batch of failed tests, an orphaned issue, a metric that suddenly degraded, a risk left behind by a recent commit.

Here's where human judgment comes in: how wide a scope do you give it? Watch only tests, and it's focused and predictable; hand it issues, logs, metrics, and user feedback, and it can do more but also drift more easily. The prudent approach is to start small, let it prove itself on that narrow scope, then expand. A loop that can't even clean up its own failing tests shouldn't be trusted with issues.

The second action is dispatch. Once you're running more than one agent, they'll fight over files: two agents modifying the same file is as messy as two colleagues changing the same lines independently, only discovering the conflict later. The fix is to give each task its own isolated working copy (technically, a git worktree). They work separately, never touching each other's files; only at the final merge do the changes meet, and if there's conflict, it's all surfaced explicitly, line by line. Separate them first, and "working in parallel" doesn't become "crashing in parallel."

The third action is verification — the core of the whole thing: once something's built, someone has to say "pass" or "fail." And the hardest design choice in loop engineering is deciding who gets to say it. If you let the coding agent grade its own work, the loop has no reliable, impartial referee. In practice, agents almost always grade themselves generously.

So you bring in a second agent whose entire job is to find fault: it runs on separate instructions, sometimes even a different model, and its default assumption is that the first agent's output is broken. It hunts for reasons to send it back. An independent, adversarial gatekeeper is far more trustworthy than expecting a coding agent to self-criticize.

The fourth action is recording progress. In a conversation, "where we are" lives in the model's ephemeral memory — but that memory vanishes when the conversation clears. A loop running round after round, long-term, can't rely on that. Results must be written to files, to databases, stored durably. Add this step, and separate task runs link into something cumulative: what was tried today, what passed, what didn't — tomorrow morning's round can pick up where today's left off.

The fifth action is scheduling — essentially giving the whole thing a heartbeat: triggering itself at set times, running another round automatically, without someone hitting a button each time.

These five actions are implemented through a set of ready-made product components, roughly six of them:

First, automation: running on schedule, finding its own work, and picking out what needs handling.

Second, worktrees: giving parallel agents their own isolated working copies so they don't step on each other.

Third, skills: writing down project rules and context once, so the agent doesn't have to re-infer them every time.

Fourth, connectors: hooking the agent into your everyday tools (mostly through MCP, a universal interface that can read your task system, query databases, post to Slack).

Fifth, sub-agents: splitting "the coder" and "the critic" into separate people.

Sixth, external memory: living outside any single conversation, tracking progress — a markdown file works, a Linear board works.

These six are all present in Claude Code and Codex now, with different names, doing the same things. Don't get hung up on which to use; design a loop that runs on either.

Two built-in commands deserve attention: /loop repeats at a fixed rhythm; /goal goes further, running until the condition you wrote is actually met, with a separate small model judging "are we done yet" after each round — not the coding agent grading itself. You write "all tests in test/auth pass, lint clean," and walk away.

With these parts assembled, a single linear conversation becomes a command center. Addy Osmani's morning loop looks roughly like this: every morning, an automation fires off against the codebase; it calls a triage skill to read yesterday's failed CI, open issues, and recent commits, logging findings to a markdown file; anything worth acting on gets its own isolated worktree, where a sub-agent drafts a fix, and a second sub-agent audits the draft against project rules and existing tests; a connector opens the PR and updates the ticket; anything it can't handle gets dropped into an inbox for him. That status file is the backbone — recording what was tried, what passed, what's left — so tomorrow morning's round can resume from where today's stopped.

Once the loop is running, not a single prompt was typed by his own hand. The loop wrote them all for him.

Why Loop Engineering Matters

A technology truly matters when it makes something formerly scarce suddenly nearly free.

Vibe coding has already removed writing code as the bottleneck. Scarcity has shifted from "writing" to "judgment," and loop engineering pushes this progression one big step further.

How far can this approach be taken? The front lines already offer examples. Steve Kaliski, an engineer at Stripe, described on the How I AI podcast their pipeline called Minions: over 1,300 pull requests merged per week, not a single line typed by human hands. But this isn't merely "using agents to write code." With vibe coding, 1,300 PRs would mean someone prompting and reviewing each one in a chat window—impossible at this volume. Minions scales because it's a designed, self-spinning pipeline: kick it off with a Slack emoji, deterministic gates (if rules can decide, never delegate to the model) interlock automatically with LLM steps, over a thousand agents run in parallel without colliding. A human designs the line once; every PR after that triggers and validates itself. The human does one thing at the end: review.

Loops don't just bring speed. Sometimes they make the difference between "works" and "doesn't work." The Information reported on an Anthropic engineer's side-by-side demo at a conference: the same "make a retro mini-game" task took twenty minutes and nine dollars with a minimal prompt, versus six hours and two hundred dollars with a loop. But the minimal version produced a game that wouldn't run; the looped version included color-swapping, debug capabilities—actually useful features. One detail from that demo: the generation agent and the verification agent would openly clash over whether something was "done" or not. The model itself hadn't grown smarter, but the independently verified conclusion from the previous round fed into the next round's input, making each iteration stronger.

This logic extends beyond code. Airbnb published a paper (Cen Zhao et al., arXiv:2510.06674) applying similar thinking to customer service: agent decisions on which answers to use, adopt, or reject, and which knowledge gaps to flag—all fed directly back into the model, compressing retraining cycles from months to weeks. In a US pilot, retrieval recall improved 11.7%, answer usefulness 8.4%, and agent adoption rate 4.5% (all relative gains). Different domain, same move: accumulate judgments, feed them back continuously.

But automating generation doesn't mean fully replacing humans. The work left for humans actually gets harder, and the smoother the loop runs, the harder certain costs become to avoid. Addy Osmani's Loop Engineering flags several issues, some already present in vibe coding that loops amplify.

First is intent debt. Agents cold-start every round, unaware of a project's unwritten rules and taboos; left unsupervised, they "confidently guess" their way forward. The fix: encode rules as Skills, write once, automatically read every round.

Second is verification debt. A loop that can run unsupervised can also err unsupervised. Even with a separate review agent, "it's done" is ultimately just a claim; whether it can ship still requires human judgment.

Third is comprehension debt. The faster a loop spits out code, the higher the pile of code you didn't write and don't truly understand. This exists in vibe coding too; Osmani notes that "a smooth loop just makes it grow faster"—the smoother the loop, the faster this gap widens.

Fourth, and most insidious: what Osmani calls cognitive surrender. Once the loop flows, people stop pushing back, accepting whatever it returns, judgment quietly ceded. So Osmani says: design loops with discernment, they're the antidote; design loops to escape thinking, they're accelerants.

Fifth is orchestration tax. Loops can spin up many threads in parallel, but your review bandwidth is finite. The ceiling on parallel count isn't set by tools—it's set by your attention.

Sixth, most concretely: runaway token costs. Costs between different usage patterns can differ by an order of magnitude; without careful accounting, it's easy to blow the budget.

Peter Steinberger now runs five or six Codex loops daily (nearly ten with earlier, slower models), checking on B's results while A runs—an expedient, he admits, until models get faster still.

But even working at this intensity, when asked whether he believes in "fully automated dark factories" where no incoming code gets reviewed, he finds it increasingly plausible, yet still insists that good software emerges through step-by-step iteration: the project you initially set out to build is almost never the one you end up shipping. The bottleneck was never writing code itself. It's figuring out what you actually want. It's taste.

His most important advice to engineers is taste: making output that "doesn't smell like AI." Loops make the act of writing even cheaper, which makes what to write, and to what standard, even more important.

5Y Signal Station Best Insight: The Overrated "Loop," The Underrated "Topology"

The above covers Silicon Valley's public discourse on loop engineering. At our closed-door session in late June, the room's tone differed from the outside conversation. No one was rushing to sing loop engineering's praises; what people wanted to discuss were the problems it hasn't solved, or even clearly framed. The insights below are excerpted from guest comments at that private seminar:

Highlights

• A sharp judgment on long-horizon capabilities: "The loop is overrated; topology is underrated." Truly valuable tasks are a combination of spiral self-iteration × deeply coupled topological structure.
• Long-horizon ≠ hard: many loop-style tasks run long without being difficult; real human work is parallel, asynchronous, interruptible—hard to mirror as a single agent's task. Long runs are more a vendor posture: model releases love showing 40-hour marathon curves, but real users mostly interact for nine, ten minutes. Auto-research that runs for hours, and collaborating with humans to solve a coding task, are not the same thing.
• The essence of multi-agent systems is blood transfusions for context: dynamic replacement during behavioral mutation, context refresh, QA/reviewer roles keeping the system from diverging—like an engineered "strange loop."
• Feedback is the loop's lifeline: signal density > communication density. Moving agent-to-agent communication into latent space is a direction people are seriously exploring, but the bottleneck is always how dense and accurate the signal is, not how frequent the communication.
• Scaling's next stop, from "training models" to "building environments": self-generated problems are too narrow; long-term, environments and verifiers must be reverse-engineered from real, high-user-volume products.
• Self-improvement remains an unproven article of faith: no theoretical guarantee that models will necessarily improve themselves; good rewards usually must be exogenous, internal signals (like KL) can only sharpen distributions, not raise capability ceilings.
• Still far from practical deployment: high-complexity, non-simple-loop tasks like consultant-grade PowerPoints (slides worth tens of thousands of RMB each) cannot yet be effectively decomposed by current models; the conclusion is don't FOMO, better to get hands-on and talk to real users.

Discussion guests | 5Y Community

Compiled by | Yiming Liu

Insight 01

The Overrated "Loop," The Underrated "Topology"

1. Before serious discussion, a taxonomy. One category: loop-style tasks—dense feedback, singular goal, a simple agent loop can viscerally resolve ~80% of problems; with good harnessing, letting it run continuously can theoretically yield steady improvement. The other category: truly large, systematized tasks composed of multiple subtasks with deeply coupled topological structure, requiring step-by-step deep advancement. Models easily get lost here, often diverging by the third or fourth layer. How to keep the model convergent, not divergent—state assessment and goal management—is the real difficulty in the latter category.

2. Hence the session's sharpest judgment: on current long-horizon capabilities and benchmarks, the loop is overweighted, and topology is underweighted. Future real tasks will likely be a combination of both: we'll spirally iterate performance on certain parts (this is recursive self-improvement, where all focus currently lies) while simultaneously advancing overall structure. The "long-horizon" state that can truly replace a person's normal workflow is the fusion of "spiral iteration × topological advancement," not merely lengthening the loop.

3. Why is topology undervalued? Because it's hard to label, and hard to label in ways that both prevent reward hacking and are sufficiently solid. Loop-style tasks, by contrast, have dense feedback, singular signals, easy labeling—so attention naturally concentrates on the RSI side.

Insight 02

Long-Horizon Is the Surface; Difficulty Is the Essence

4. METR's long-horizon task leaderboard shows that tasks with a 50% success rate now require 17 hours of runtime (up from 14 just weeks ago), expanding at a blistering pace. But "long-horizon" is a relative and easily misleading concept: long ≠ hard. Loop-style tasks can run for ages without being difficult; meanwhile, some more complex playground or enterprise tasks might only run for two hours yet solve numerous hierarchical subtasks, making them substantially harder. One framework offered by a guest at the event: the difficulty of a long-horizon task depends on two things—the complexity of its coupling graph, and the sparsity of intermediate signals.

5. A telling observation: the long run is mostly a posture vendors want to project. When releasing models, everyone loves to showcase cases like "ran continuously on a codebase for 30+ hours and improved X%," and everyone cheers at that upward-sloping curve. But most real users would never set a model loose on a 10- or 20-hour task; setting aside cost, the dominant interaction pattern remains a single exchange with Codex or Claude Code—nine or ten minutes to get a sufficiently good patch. Auto-research with long-running loops is not the same thing as actually collaborating with a human to solve a coding task.

6. The real gap lies in the structural difference between human work and single-agent tasks. Human work is parallel, multithreaded, interrupt-driven, asynchronous—your boss drops an urgent task in the morning, you do research in the afternoon, get pulled into revising a PowerPoint at night. A project that ostensibly spans three to five months looks long-horizon, yet resists being cleanly mirrored as a well-defined agent task. Conversely, what genuinely suits long-horizon execution and improves with model and compute scaling is an extremely pure environment: coding, where the interaction surface is bash and command line, the medium is natural language and code (what agents do best), and rewards are crystal clear.

7. Enterprise scenarios push difficulty to the extreme: signals are extraordinarily weak, topology extraordinarily complex. When a boss drives an AI transformation initiative, they often give you just a sentence or two, or a complex document that's vague and subject to endless mid-flight revisions, with real scenarios they cannot possibly reproduce for you. Whether you can "grind" through a domain depends heavily on its in-distribution nature. Code has the most collectible signals, so it fell first; then finance, then office tools. Uncommon tasks demand a different capability: reading and comprehending instructions from complex documents, constructing one's own world model, defining one's own verifier and objectives. One new agentic benchmark discussed at the event clearly bifurcates into two task categories: gimme questions in the teens (office / finance / cyber, already covered one by one by major labs), and roughly 80% of tasks that no one has seen before. This raises a more fundamental question: what kind of human work is AGI actually meant to replace? Large-scale systems engineering like "building nukes" that demands extremely high-level global vision (rare, but enormous economic value)? Or the loop-style daily work where "today looks like tomorrow" for most people (gradually being covered, but limited unit value, prone to getting stuck on ROI)? This yields a clear product divergence: one end pursues extreme long-running ceilings to solve the hardest systems tasks; the other offers high cost-performance adaptation to various human loop-style workflows.

Insight 03

The Essence of Multi-Agent Is Blood Transfusion for Context

8. Single-agent systems have a hidden degradation curve: the user's first prompt tends to be超长, hyper-precise, and extremely high-quality; but subsequent utterances are "continue," "take a look," "give me an update"—input quality keeps dropping, and output quality degrades accordingly (garbage in, garbage out applies to context too). Multi-agent systems improve on this because agent-to-agent prompts can stably maintain high quality (unconstrained by the human attention bottleneck of "2000 characters takes 5–10 minutes"), pushing the whole system into "high-quality resonance" rather than the monotonically declining curve of single-agent setups.

9. But agents are Markovian: initial errors compound, and having an agent review itself only amplifies those accumulated errors. The proposed solution is a three-piece toolkit: first, when anomalous behavior is observed in an agent, the system layer spawns a new agent inheriting previously沉淀ed context / goal / experience; second, continuous context refresh to keep all context as "fresh and healthy" as possible; third, introducing QA and reviewer roles—with QA self-checking alone improving system performance by roughly 22 points, and QA + reviewer together extending system continuity by another 2–4 hours. These experiments run on GLM 5.1 / 5.2, consuming roughly 2–3B tokens per team per day. The output of these multi-day runs feeds back into model iteration itself: model training provides the clearest feedback signal, making research and training the most suitable scenarios for long-running systems currently. Solving within the loop for large systems tasks is, at its core, context scaling—parallel segmentation, serial segmentation, compression within segments; do this cleanly enough, and the ceiling rises.

10. The deeper design philosophy is an engineered "strange loop." The discussion borrowed Hofstadter's notion of self-reference from Gödel, Escher, Bach: make the system self-mirroring, so each agent can see who its collaborators are, whether they're healthy, reliable, and what difficulty of task can be delegated to them, enabling adaptive task allocation within the system. Of course, self-reference and adaptation carry costs: one person running long-horizon tasks on a 16GB Mac mini had the system grind to a halt from spawning too many self-created agents, making resource management an unavoidable concern for multi-agent systems.

11. Following this direction, making "orchestration" itself learnable and searchable is another major trend. ChatDev-style 1:1 mimicry of human software companies (CEO / CTO / coder / code reviewer / tester, pipeline-style) already looks dated—it leans heavily on human experience and poorly fits how agents actually work. Replacing it: using linear search or MCTS to search for better multi-agent architectures in a constrained space (works like AFlow); training a dynamic scheduling "orchestrator" model (how many layers to move, how many to train) that learns to decide "who handles what next" based on current task state; and, like Moonshot AI's agent swarm, learning "when to spin up multiple subagents for broader exploration, and when not to." By contrast, Claude Code's parallel subagent search at the time, as discussed on-site, remained largely at the level of "parallelization," not yet touching complex task dispatch.

Insight 04

Feedback Is the Lifeline of Loops: Signal Density > Communication Density

12. Why do loop-style tasks work well now? Because their feedback is dense and singular. Systems tasks are hard because their feedback essentially requires a process reward / process call, and such process signals are extraordinarily difficult to provide. A crude but precise analogy: managing an agent is no different from managing an employee—let them work for three days with zero feedback, and what they produce probably won't match what you wanted. So whether feedback comes from environment, from other agents, or from review, it boils down to the same thing: models need denser feedback.

13. In multi-agent collaboration, roughly 40% of information is spent on communication, easily devolving into echo-chamber inefficiency of "roger, roger, roger." A direction repeatedly pondered: why must agents communicate through human-discrete tokens at all? Just as thinking can be pushed into latent space for inference, can agents communicate in latent space (shared KV cache, even shared partial activation layers)? A consensus from the on-site discussion: communication density itself doesn't solve the ceiling problem. Chopping segments finer makes individual agents more robust to information, but erroneous information still accumulates across the system; truly clearing errors ultimately depends on when you provide sufficiently good feedback and perform a system-level update.

Insight 05

Scaling's Next Stop: From "Training Models" to "Building Environments"

14. The center of gravity for scaling is shifting from pre-training and post-training toward scaling environment and scaling verifier. A core pain point: hand-crafting problems is too narrow—how many problems can a handful of people create? You end up covering only a few benchmark points and a tiny slice of user experience, landing in a narrow band that doesn't generalize. Hence the long-term imperative to "reverse": derive environments from real, high-user-volume products, especially simulating "a user's computer environment after extended use," rather than conjuring overly simplistic toy environments from thin air. Consequently, systems that can accumulate massive volumes of real tasks and be reverse-engineered at scale are considered to have exceptionally strong potential.

15. This also explains why model companies are visibly accelerating on productization: highly productized ideas like Codex's record and replay (screen recording, workflow logging) and Claude Tag are entering their field of view. As for the question of "what exactly does a company want to cover," the first-principle thinking at Anthropic is straightforward, according to on-site discussion: whichever domain is most profitable, that's where you first apply intelligence to hack. Meanwhile, Anthropic is also reportedly exploring capabilities around Loop / Dreaming / Outcomes — systems for auditing, scoring, augmenting memory and experience, and strengthening self-improvement harnesses.

Insight 06

Self-Improvement: A Faith Yet to Be Proven

16. Since early work like APE in 2022, there has been no theoretical proof that the models we have today will necessarily self-improve. Feed them failure experiences, and they won't necessarily head in the right direction. Much of what passes for self-improvement today is really just accumulating experience, trying repeatedly, brute-forcing through possibilities. The gap lies here: a sufficiently intelligent model (like Anthropic's) might know what to do the second time after failing once; most current models might need five to ten tries before figuring out the next trajectory, yielding very high failure rates on tasks within a local region. Thus, "how to evaluate a model's self-improvement capability" remains an open question.

17. A necessary condition for self-improvement is a good reward, and this typically cannot be derived from within the model itself. Rewards constructed from internal model states (like KL divergence) mostly just sharpen distributions (making them more peaked, thereby performing better on certain downstream tasks) without actually raising the capability ceiling. Truly effective rewards require exogenous construction: the right environment, the right evaluation, even the right human-in-the-loop. The on-site discussion did indeed split into two tendencies: one side placing more faith in human-in-the-loop human reward, the other betting on multi-agent / LLM-as-judge. But a more practical criterion: if a task is objective with clear right and wrong, humans need not intervene; if "whether the user likes it" is the standard, humans must be in the loop, because human taste and aesthetics currently cannot be well modeled — humans are not fully rational to begin with.

18. A sobering analogy: self-improvement today may be where memory was last year — at the time we thought memory was just storage, just engineering, only to later discover it was far more than that. Memory itself was underestimated: in an evaluation spanning ten years with models undergoing continuous interest-shifting, most models didn't know which new information should overwrite which old information, performing quite poorly. And for products, the kind of self-improvement that genuinely makes users feel "it's getting me more and more" often derives its returns from evolving memory, which is essentially better context engineering. Don't forget, data improvement also has a ceiling — the ceiling of annotators' / human reviewers' aesthetic judgment, which is not infinite.

Insight 07

The Two Ends of Deployment, and the "Garbage Time" Wasted in Between

19. Vertical depth remains a massive gap. Take consulting-grade presentations: tools like Gamma already do decent work, but the standard where a single slide is worth tens of thousands of RMB — current large models cannot achieve this at all. Such tasks carry extreme complexity (not simple looping), and models still cannot effectively decompose them or complete high-information-density single-page drafting. The conclusion is pragmatic: no need for FOMO; better to observe, get hands-on, and talk to different real users — you'll find current models still fall far short.

20. Task value has traditionally been divided into two ends: one end is interaction with extremely high latency requirements demanding instant response; the other is long tasks that "run in the background with no latency concerns." The zone in between — say, "spending 8 minutes to do a 5-minute job for the user" — was seen as pure "garbage time," where users are stuck neither leaving nor waiting. An underestimated application-layer opportunity is predicting task duration and using that waiting period to proactively push information back to the user (the quip about "sending off a task, watching a short drama episode, and coming back just in time" is the folk version of this need). But "predicting duration" is essentially similar to "predicting reward / token count" — hard to get right, inevitably has long tails, and will likely only overfit to specific vertical scenarios.

If this discussion were to leave one final footnote, it might be this: managing an Agent is fundamentally no different from managing an employee — if you have them work for three days with zero feedback, what they deliver probably won't be what you wanted. We remain several orders of magnitude away in environment and data, several orders of magnitude away in denser and more precise feedback signals, and one still-unanswered question about whether "self-improvement" even holds, before Agents can truly take over a person's complete workflow. But at least, the paths worth exploring are already plentiful.

References and Further Reading:

The first part of this article draws primarily from the sources below; all Insights in the second part come from the closed-door discussion referenced.

• Addy Osmani, Loop Engineering, June 7, 2026 — the work that named and defined "loop engineering," the source of the six components and six types of cost.

• The Information, "Why Agent Loops Are Hot," June 2026 — the backstory of agent loops, and Anthropic's retro gaming app experiment contrasting "minimal prompting vs. looping."

• Cen Zhao et al., "Agent-in-the-Loop: A Data Flywheel for Continuous Improvement in LLM-based Customer Support," Airbnb, arXiv:2510.06674 — an arXiv paper on embedding human feedback into live operations and compressing retraining cycles from "months" to "weeks."

• Loop Engineering: The Anthropic Playbook…, The Self-Improving Agentic Loop…, Loop Design: A Field Playbook for Agentic Systems — independent 2026 compilations on loop engineering: breaking one loop into five actions (discovery, delegation, verification, persistence, scheduling) and mapping them to Anthropic's public agent patterns (orchestrator–workers, evaluator–optimizer); the Stripe Minions case of 1,300 PRs per week is also documented here.

• Peter Steinberger (founder of OpenClaw, now at OpenAI) in conversation at AI Engineer Europe, and Anatoli Kopadze's long-form writing on loops — first-hand perspectives from the front lines of workflow and methodology.