From In-the-Loop to Out-of-the-Loop: The Next Leap in AI Agent Architecture

Introduction: When Agents Write Code Better Than You

A developer with over 15 years of software engineering experience raised a pointed question: if an agent in the loop is the better programmer, why are you still sitting in the loop? In his video, he stated bluntly that when models like Opus and Astra execute complex tasks continuously, the sophistication of their tool-calling combinations already far exceeds the best state of human engineers. This is not an isolated case but a recurring new normal.

This leads to a core judgment: humans are becoming the bottleneck of agent systems. According to this creator's estimate, at least 80% of current work can run without real-time human participation—provided the system architecture is correct. Based on that video's content, this article outlines the evolutionary path from "human in the loop" to "near the loop" to "out of the loop," as well as the key elements for building proactive agent systems.

Three States: In Loop, Near Loop, Out Loop

The author uses three concise labels to summarize the levels of agent engineering capability:

• In Loop: You are in the terminal, constantly entering prompts and adjusting direction, with your attention fully bound to the agent. This is the current state of most developers.
• Near Loop: You click, approve, and give feedback, but the work has already happened before you sit down and continues after you leave. You have shifted from "trigger" to "reviewer."
• Out Loop: Fully autonomous operation through mechanisms such as cron jobs. You are no longer a necessary condition of the system; you only observe the results.

The author emphasizes that jumping directly from in the loop to out of the loop is too difficult; near loop is a necessary transitional step. The standard for measuring agent engineering level is no longer how complex the prompts you can write, but how many systems are still working for you without your participation.

Core Elements: The Tech Stack for Building Near-Loop Systems

Persistent Agents and Sandboxes

Traditional one-off sessions (which end when you close the terminal) cannot support proactive agents. Persistent agents can withstand crashes, restarts, or even closing the laptop, and continuously track task state. The author points out that persistent agents must rely on memory mechanisms; ordinary in-loop agents are not up to such systems.

Sandboxes are another key. Giving an agent an independent CPU/GPU computing environment means it is always online, isolated and secure, and has the full computer toolset of a human engineer. This is the material foundation for an agent to "work like you."

Prompt injection refers to an attacker hiding malicious instructions in content that the agent will read (such as web page text, documents, emails, or tool return results), inducing the model to deviate from its original task, leak sensitive information, or perform dangerous operations. It is similar to SQL injection in traditional web security, but the attack surface is natural-language instructions rather than code. The difficulty of defense lies in the model's inability to reliably distinguish "data" from "instructions." Common mitigation methods include: marking untrusted content for isolation, restricting tool permissions, introducing an independent judgment model to classify and review inputs and outputs, and running in a sandbox to limit the blast radius. The 40/40 evaluation mentioned in the article is a quantitative test result of such defensive capability.

Triggers and the API Layer

"Why are you still the primary way to start an agent?" the author repeatedly asks. The design principle of near-loop systems is to replace humans as triggers with specific events—webhooks, cron schedules, user actions, event classification in log streams, and so on. A clear API layer allows multiple triggers to connect to the same set of agent capabilities.

A webhook is an event-driven HTTP callback mechanism: when a specific event occurs in an external system (such as a code push, order creation, or monitoring alert), the source system proactively initiates a POST request to a pre-registered URL, pushing the event payload to the receiver. Compared with polling, Webhook is a "push" model with low latency and low overhead. In agent systems, webhooks make changes in the external world directly become startup signals for the agent, without relying on humans to manually enter commands. Cron, on the other hand, is a schedule-based timer trigger suitable for periodic tasks (such as daily news aggregation or scheduled inspections). Combined, the two can cover both "event-driven" and "time-driven" autonomous trigger scenarios, and are key technical means for near-loop systems to escape humans as the sole trigger.

The Formula for Proactive Agents

The author provides a concise architectural formula: Persistent Agent + Triggers + Sandbox = Proactive Agent. Such an agent does not wait for you to start work but works for you first and then waits for your intervention. This is described as a "step change" in engineering output capability.

Real Use Cases: From Incident Response to News Filtering

The video demonstrates several near-loop systems that are already running in practice.

On-call incident response agent: In a simulated system, a disconnected client generates streaming events, and jev is used to classify the events. After the on-call agent locates the problem, humans only need to understand and click deploy. The complete AI developer workflow—detection, investigation, root cause analysis, remediation, and preparing for review—is executed by the agent, with humans relegated to reviewers. According to the author, many engineers are actively implementing such solutions.

Persistent news agent: Running on a sandbox on an M4 Mac mini, it has been continuously online for a week and a half. It continuously pulls information, normalizes and presents it in a way free of biological bias, filters out clickbait, and pushes only actionable signals. The author likes items of interest, providing feedback signals to the agent and reinforcing the data flywheel. He specifically mentions an evaluation result on prompt injection defense—the decision model scored a perfect 40/40 on that item.

UI replication agent: This is a new experiment after the release of jev 1.14. The user drags in a screenshot of a design draft, and an original RSI loop starts: fix, build, screenshot, compare with jev, and iterate repeatedly until the similarity target is met. In a cloud sandbox, a UI mirroring task reached a match score of 86.1, with the entire process running unattended for about 30 minutes. The author also notes that results may be unsatisfactory when switching to different models (such as Sonnet 5.5), indicating that model selection remains one of the system variables.

The Four Core Elements and Engineering Leverage

The author breaks down the composition of an agent into four underlying elements: context, model, prompt, and tools/harness. These four elements multiply, and then multiplied by software engineering capability, form the leverage formula of Agentic Engineering.

Among them, harness engineering is regarded by the author as the most worthwhile direction to invest in at the intermediate and advanced stages. By building your own agent harness, you can customize the toolset for a specific product. For example, when it is discovered that the agent may execute dangerous commands, simply remove the bash tool and keep only the tools precisely needed—this is a concrete manifestation of an engineer's product understanding, security awareness, and model selection capability.

The author also reminds readers to pay attention to tokenomics: model selection needs to balance performance, speed, and cost, and deeply subsidized subscription models will not last forever.

The term "harness" is borrowed from mountaineering and horse training, referring to a device that constrains and guides a powerful object. In the agent context, harness refers to the entire execution framework outside the model: tool definition and registration, permission boundaries, loop control, output parsing, error retry, state management, and so on. The same model can perform very differently under different harnesses—the default harness pursues generality, while a customized harness can tailor the toolset, tighten permissions, and optimize context organization for a specific product. Therefore, harness engineering is essentially the engineering of "productizing around the model." It determines whether the model's capabilities can be released safely, stably, and reproducibly, and it is also the layer where engineers can best build differentiated advantages relative to general-purpose tools.

Vibe Coding Is the Floor, Agentic Engineering Is the Ceiling

A recurring contrast in the video is: vibe coding is not understanding what the system is doing and not looking; agentic engineering is understanding the system well enough that you do not need to look. The former relies on the default agent harness, and the advantage of a single agent under the default configuration has already "completely saturated."

The author proposes that an engineer's advantage lies in being able to build "systems that build systems." This requires mastering all four elements at once and adding years of accumulated software engineering judgment—what questions can be asked, what architectures can be designed, and what deep understanding of the domain exists. This combination constitutes a specialization barrier that others find hard to replicate.

The term vibe coding was coined by Andrej Karpathy in early 2025, referring to a programming style in which developers describe intent in natural language, barely read or review the generated code, and rely entirely on model output. Its value lies in its extremely low barrier to entry and rapid prototyping, but the cost is that developers lack understanding of system behavior, making debugging difficult and security and quality hard to guarantee. Agentic engineering is the opposite: developers deeply understand the interaction among the four elements of context, model, prompt, and tools, and can design systems, set boundaries, and evaluate output. The difference between the two is not whether AI is used, but whether the developer retains cognition and control over the system—which also explains why the author says the former is the floor and the latter is the ceiling.

Metrics and Next Steps

The measurement framework the author provides is straightforward: how many agents are doing useful work for you right now. He emphasizes that this does not mean using a while loop to make agents randomly consume tokens, but rather productive work that truly amplifies your capabilities. Human attention is ultimately limited, and watching multiple terminals at the same time inevitably leads to loss of control and blind trust in the model—that is not engineering.

In the author's three-stage framework, technological revolutions follow a cycle of "augment, automate, deprecate." Out-of-loop engineering corresponds to the third stage, namely zero touch engineering. He teases related products for advanced agent users, but this article will not elaborate on them.

It is worth noting that this narrative has obvious product-promotion characteristics, with the video repeatedly directing viewers to subscribe and pre-order. However, its technical framework—persistent agents, event triggers, sandboxes, and the four core elements—has independent reference value and can serve as a checklist for evaluating the maturity of your own agent architecture.

FAQ

What is the difference between near loop and out loop? In a near-loop system, humans still retain approval authority at key nodes, but work happens before and after human intervention; an out-of-loop system operates fully autonomously, with humans only observing the results.

Why is a sandbox needed? A sandbox keeps agents always online and isolated from one another, and gives them a complete computing environment, thereby removing dependence on the developer's local machine.

What is harness engineering? It refers to building customized tools and execution environments around the model so that the agent can outperform the default configuration in a specific product scenario.

One-line Summary

Humans are becoming the bottleneck of agent systems, and engineering focus should shift from in the loop to near loop and out of loop.

Paragraph Summary

Based on the video views of a senior engineer, the article argues that humans are becoming the bottleneck of agent systems and that at least 80% of work can run without real-time human participation. The author uses three states—in loop, near loop, and out loop—to describe the evolution of agent engineering capability, emphasizing that near loop is a necessary transition to full autonomy. The tech stack for building near-loop systems includes persistent agents, sandboxes, event triggers, and a clear API layer, with the architectural formula "Persistent Agent + Triggers + Sandbox = Proactive Agent." The article also presents several real use cases such as on-call incident response, persistent news filtering, and UI replication, and proposes a leverage formula in which context, model, prompt, and tools multiply and are then combined with software engineering capability, pointing out that harness engineering and specialization are the core advantages of engineers.