What Is Loop Engineering and How Does It Differ From Harness Engineering?

What Is Loop Engineering?

"Loop engineering is about replacing the role of the person who prompts an agent with a system that does it for you. Design a system that does the prompting for you." – Peter Steinberger

Boris Cherny (Anthropic) echoes the idea, saying he no longer prompts Claude directly but runs loops that decide when and how to prompt. Unlike a static cron job, a loop’s steps are chosen at runtime by a model based on context such as "triage yesterday’s CI failures".

Reasonable Criticisms

Terminology over‑packaging : New buzzwords like "context engineering", "agent harness", and "loop engineering" appear every few months, often driven by conference titles rather than substantive new concepts.

Cost : A continuously running loop that spawns parallel sub‑agents can consume tokens at a high and variable rate. For many teams, a simple Python script that checks deployment status is far cheaper unless the problem truly requires dynamic, model‑driven judgment.

Selective examples : Demonstrations (daily CI triage, commit summaries, bug hunting) showcase scenarios where model‑driven decisions add value, but they do not prove loops are superior in all cases.

Relation to Harness Engineering

Harness engineering focuses on a single agent’s execution environment—context management, tool permissions, retries, logging, and state persistence—to prevent hallucinated tool calls or forgotten goals.

Loop engineering orchestrates multiple agents over time, answering who discovers work, who executes it, who checks it, and how later runs know what earlier runs accomplished. It acts as a control plane above the harness.

In short, harness is the runtime container for an agent; the loop decides when to launch an agent, what prompt to give it, and how to handle its results.

Loop Architecture (Addy’s Five Components)

Automations : Scheduled or event‑triggered prompts that discover work, e.g., /loop, /goal, or scheduled tasks in Claude Code’s Triage inbox.

Worktrees : Isolated environments for parallel agents, preventing conflicts similar to two engineers committing to the same file without coordination.

Skills : Project knowledge captured outside the conversation (e.g., a SKILL.md) so the agent need not re‑derive conventions each run.

Connectors : Model Context Protocol (MCP) integration that lets loops act on real systems—opening PRs, updating tickets, posting notifications.

Sub‑agents : A maker/checker split where one agent writes code and another validates it.

The sixth element is State : a markdown file, Linear board, or any external record that persists what has been tried, succeeded, or remains unresolved across loop iterations.

The /goal Primitive

Most loops use familiar mechanisms, but /goal introduces a new primitive without a clean precedent. It accepts a verifiable stop condition (e.g., "all tests in test/auth pass and lint is clean"). The loop runs until the condition is true, with a smaller model evaluating progress each iteration. This maker/checker split applied to the stop condition is a genuine design contribution, unlike a cron job that stops when the script exits.

Whether the token cost is justified depends on the problem: a simple bash check suffices for "CI passes", whereas a safety‑critical PR merge decision may merit model‑driven judgment.

Conclusion

Loop engineering is not a fundamentally new paradigm; it is an orchestration pattern built on top of the basic components of agent harness, applied to problems that require autonomous multi‑agent work over time.

The truly novel element is the /goal primitive and the maker/checker split applied to the stop condition, which cannot be cleanly mapped to prior reactive workflow models.

The hype that "you should stop prompting agents and design loops" is only appropriate for a subset of problems; applying it universally can be wasteful.

Just as micro‑services are not a blanket replacement for every function call, loops should be introduced only when their added complexity is justified.

From Theory to Production

Loop engineering is still immature and lacks a battle‑tested handbook. Teams experimenting with it should first identify a recurring workflow whose runtime decision logic is ambiguous and cannot be scripted. Run the workflow manually with an agent, observe failure points, judgment needs, and untrusted outputs—these observations become the basis for loop design. Always monitor token consumption and calculate costs.

Rushing to build loops before solid foundational work leads to dead‑end demos or production failures.

References

https://addyosmani.com/blog/loop-engineering/

https://www.reddit.com/r/theprimeagen/comments/1tzrmoz/creator_of_claude_code_i_dont_write_prompts/

https://code.claude.com/docs/en/scheduled-tasks