For some time now, the phrase “XX engineering” has appeared with striking frequency in the AI industry. Until last year, “prompt” and “context” filled the XX; this year it has been “harness” and “loop,” with “graph” recently joining the list. Today I want to share my thoughts and experience with the slightly past-its-peak trend of “loop engineering,” and explain how Corca runs loops across the organization through our AX Sharing Session. My conclusion is simple: designing an effective loop for agents is surprisingly similar to designing an effective weekly recurring event for an organization.
Loops are real, not just another fad
For developers, the word “loop” probably brings to mind control structures such as for and while. Recently, however, it has begun to appear in broader contexts: human-in-the-loop, human-on-the-loop, and loop engineering.
One person who helped bring this broader idea of loops into the mainstream is Boris Cherny, who leads Claude Code. On June 17, 2026, the first question in his audience Q&A at Meta’s @Scale conference was about loops.
“Are loops just the next hype cycle, or are they real?”
Cherny’s answer was unequivocal.
“Loops are real. Two years ago, we wrote source code by hand. Then we shifted to having agents write the code. Now we are moving to a stage where an agent prompts another agent, which then writes the code. Just as the shift from source code to agents was enormous, loops are an equally important and substantial leap.”
Major coding agents now reinforce that point with built-in goal features that let anyone run a loop. Instead of carrying out one prompt and stopping, the agent activates a “goal.” It then plans and repeats its own next actions until the active goal—its completion condition—has been met.
At Corca, we have been using goal very actively for several months. In one repository, we might set an ambitious goal and occasionally steer an agent running autonomously for dozens of hours. In another, we give it work with a short feedback cycle. Both have become ordinary. The way coding looks has changed once again.
But loops are not a cure-all
I strongly agree with Cherny that loops are a major leap, but of course they are not a cure-all. An infinite loop that never ends is one of the problems developers most want to avoid. When I first began using goal, I once gave Codex a poorly framed objective such as “close every open issue.” After watching it burn through tokens for 30 hours, I had to terminate it. The opposite was just as disappointing: I would start a goal before bed expecting a long run, only to wake up to “this requires approval; stopped after three unanswered attempts.”
Perhaps “engineering” was added to “loop” because we want to avoid those disappointments and design and run loops more effectively. Based on my own interpretation, an effective loop requires the following:
- Give the agent the right verification tools and permissions to “close” the loop itself (for example, linters for syntax, benchmarks for speed, browser harnesses for UI verification, mandatory review by an independent agent, and explicit permission for external writes to specified URLs).
- Make implementation completion mechanically decidable (for example, execution time below a threshold, all tests passing, or test coverage above a target).
- Keep implementation and verification as inexpensive and fast as possible (for example, iterate on the design with a smart but slow model, have cheaper and faster models implement in parallel, use deterministic code instead of agents where possible, and define stop and budget conditions).
- When verification fails, make the agent self-improve by fixing the underlying cause rather than the symptom (for example, improve structural patterns and patterns-of-patterns instead of merely retrying, encode rules in AGENTS.md and documentation rather than memory, and treat the verifier’s logic and scope as things that can also be improved).
- Make it easy for people to observe, intervene in, and review whether the agent is doing well and whether it did well (for example, record decisions and results in files, stop and ask when a decision is required, and visualize status in HTML or Mermaid).
I originally compiled this list only from my own experience, but later found that Anthropic’s introductory guide to loops and Google’s Addy Osmani emphasize similar points. Anthropic says agents need tools that let them see, measure, and manipulate results, and that quantitative verification is easier for them to perform themselves; deterministic criteria such as a number of passing tests or a score threshold are effective for precisely that reason. In Loop Engineering, Osmani breaks loops into five elements—automation, worktrees, skills, connectors, and subagents—and places a sixth element beneath them: “external memory” that persists outside the conversation.
At Corca, it is increasingly common for us to share techniques for satisfying these conditions and running better loops. Expressions such as “design the loop” and “close the loop” have also become much more common. Raising the loop concept from code to the agent level now feels completely natural.
Yet after writing down these five requirements, they looked strangely familiar. Corca was already running a similar loop at an even higher level: the organizational level. The mechanism is our recurring Thursday-morning AX Sharing Session.
The organization had a loop too: the AX Sharing Session, then and now
The predecessor of the AX Sharing Session was the “Weekly Agentic Engineering Retrospective,” which began last November. Together with the Moonlight team, we focused on sharing practical ways to pay down product technical debt with AI. But because Moonlight is a product team, immediate fixes and releases naturally took priority. The event therefore felt largely driven by me and a few others whose work centered on AX itself. We gradually built an environment that improved code quality and began some small practices, but change was not especially fast. (Drawing on that experience, I also presented “Building an Environment Where Agents and People Can Both Excel in a Legacy Codebase” at a Claude Code meetup.)
As an organization-wide atmosphere formed, the event was renamed first the “Agentic Engineering Sharing Session” and then the “AX Sharing Session” in February and March of this year, and the snowball began to roll. It was no longer led by one particular person or attended by only one team. Every Thursday morning, the whole company gathered and three people shared their recent AI experiments and the trial and error behind them. Some proudly debuted a new internal tool. Others shared a summary of a recent book or conference, or their experience with a fashionable skill or tool. Before long, the session had become a valuable event that both broadened AX across Corca and helped onboard new colleagues.
Running an organizational loop through the AX Sharing Session
The AX Sharing Session is now well established at Corca, but getting here involved plenty of twists and turns. We thought especially hard about this question: “How can a recurring weekly event become genuinely meaningful for individuals and the organization, rather than a formality?” Early on, we evolved the format through discussion and experiments intended to make the hour more useful.
As of August 2026, the resulting format is as follows. It lasts exactly one hour.
- We freely discuss whether and how we actually carried out the “thing to try over the next week” that we wrote in the previous retrospective, along with anything else we want to share.
- Three presenters share their stories and leave everyone with “one thing to experiment with or try.”
- Each person reflects, writes their impressions of the day, and records a “thing to try over the next week.”
Step two may look like the centerpiece, but it is really the loss leader. Steps one and three around it are what matter. They turn the event into a sharing session that everyone participates in, not a seminar led by someone else, allowing individuals and the organization to keep growing. Over time, the session developed three cultural mechanisms used at three different moments.
- At the end of the session: if your “thing to try” is not small and specific, you will receive some gentle teasing. (“Can you really do this, A?” “B, your retrospective does not include anything to try.” “C, how will we know whether this is complete?”)
- Between sessions: Corca’s agent colleague Ceal sends reminders based on the retrospectives. The next day, Ceal opens a thread summarizing everyone’s commitments, then sends up to two direct messages to people who have neither reacted with :done: nor left a comment, suggesting, “Try doing even this small part.” When Ceal occasionally breaks and cannot send a message, people jokingly excuse themselves by saying, “I couldn’t do it because Ceal didn’t nag me.”
- At the start of the next session: we ask every person directly: “Did you do it? What did you do? Why couldn’t you? You haven’t managed it for several weeks—what will you do this week?” The pressure is real, and some people rush to try at least something on Thursday morning. I feel a little sorry, but I consider this a positive side effect. You could also say that we have developed a small shared habit: Thursday is the day we try something.
The AX Sharing Session’s format and mechanisms closely resemble the requirements for effective loop engineering described above.
| Requirement for an effective loop | In an agent loop | In the AX Sharing Session |
|---|---|---|
| ① Verification tools and permissions that close the loop | Linters, tests, benchmarks, browser harnesses, and independent-agent review | Asking each person “Did you do it?” on Thursday morning; Ceal sending DMs to people who have not responded |
| ② Mechanical completion criteria | All tests pass; coverage is at least N% | Positive and organizational pressure at the beginning and end of each session |
| ③ Low cost and time | Slow models for design, fast models implementing in parallel, stop conditions, and budgets | A fixed one-hour slot, only three presenters, and operation in Slack, which we already use; Ceal and colleagues also keep shrinking the unit of action by saying, “Try doing even this small part” |
| ④ Fix the underlying cause of failure | Improve the pattern instead of retrying, and encode rules in AGENTS.md and documentation | When the same person repeatedly cannot act, improve the format and mechanisms—teasing, Ceal, and opening questions—for the next week instead of applying more pressure to that person |
| ⑤ Observability, intervention, and review | Record decisions and results in files; visualize status | Keep retrospectives and experiments in the session’s Notion page and Slack threads, where people look most often |
While filling in the table, I newly recognized points one and four. Having a colleague ask about my retrospective on Thursday morning instead of grading it myself mirrors the separation of an implementation agent and a review agent. And when someone has been unable to act for several weeks, we do not simply push that person harder. We ask what our format missed and improve the mechanism. That resembles encoding a rule instead of patching each failure individually. Ceal’s reminders and the opening questions were mechanisms created one by one in exactly this way.
The comparison may look forced, but I do not think the similarity is accidental. Both cases involve the same problem: giving a self-directed actor clear completion criteria and feedback. Whether that actor is a person or an agent, without criteria and feedback it may fall into an endless loop or simply fizzle out. Both agents and people running loops therefore need the right support.
Closing thoughts
The essence of a loop is not to run for a long time. What matters is that the agent capably carries out a person’s clear intent and completes the work at the desired quality in less time. Both the actor—the capabilities of people and agents—and the environment—the methodology of loop engineering—must keep improving.
Likewise, the essence of recurring organizational events such as weekly meetings, one-on-ones, and AX Sharing Sessions is not preserving their format. It is faithfully achieving the purpose for which the event exists. The time and energy required should gradually decline, and that requires the actor and environment to improve together. The current AX Sharing Session is only a snapshot from one day in August 2026, so we will continue experimenting and trying interesting ideas.
Do your organization’s recurring events have a “closing condition”? It may be worth considering whether any principles of loop engineering that you apply to agents have yet to be applied to yourself or your organization.