Source: Addy Osmani — "Loop Engineering" — 2026-06-07 Also referenced: LangChain — "The Art of Loop Engineering" by Sydney Runkle — 2026-06-16

Summary

Two independent, well-read sources coined and elaborated the same term nine days apart in June 2026: "loop engineering," the practice of designing autonomous, self-triggering systems around AI agents instead of manually prompting them turn by turn. Addy Osmani frames it as a mindset shift — stop prompting agents, start designing the loop that prompts them for you — built from five reusable components. LangChain's Sydney Runkle (citing Swyx's earlier "loopcraft: the art of stacking loops") gives it a more formal architecture: four nested feedback loops, each one making the loop inside it more reliable. The two pieces don't cite each other, which is itself the notable part — this is convergent naming of a pattern multiple practitioners were independently noticing, the same kind of signal Hermes's own synthesis passes look for across this vault.

Key Takeaways

• Osmani's core claim, in his words: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." The unit of work shifts from a single interactive session to a recurring, mostly-unattended system.
• Osmani's five components any loop is built from: automations (scheduled discovery/triage tasks), worktrees (isolated parallel execution so agents don't collide on the same files), skills (a documented SKILL.md-style knowledge base agents reference automatically), plugins/connectors (MCP-based links to existing tools), and sub-agents (a separate agent verifies the work so the creator never grades its own output) — plus external state (a markdown file or a Linear board) that survives across runs.
• Osmani's concrete example: a daily automation reads CI failures and open issues, generates fixes in isolated worktrees, routes each fix through a verification sub-agent, opens PRs, and updates the tickets — with no human prompting between any of those steps.
• LangChain's four-loop stack, each one operating on the loop below it: Loop 1 (Agent Loop) — an LLM calling tools repeatedly until done, built on primitives like create_agent; Loop 2 (Verification Loop) — automated graders scoring outputs against a rubric and feeding back a retry signal, via RubricMiddleware; Loop 3 (Event-Driven Loop) — external triggers (webhooks, cron, Slack) run the agent inside a production deployment (LangSmith Deployment or Fleet); Loop 4 (Hill Climbing Loop) — production traces feed an analysis agent that tunes prompt/tool config over time, instrumented via LangSmith Engine.
• Where the two frameworks actually line up: Osmani's "automations" + "sub-agents" map almost directly onto LangChain's Loop 1 + Loop 2; his "external state" (markdown/Linear) is the same problem LangChain's Loop 3 solves with a real deployment platform instead of a file. Osmani's piece reads as the practitioner-level how-to; LangChain's reads as the platform-vendor's architecture diagram for the same idea — expected, since LangSmith/LangGraph is the product being sold underneath it.
• Both pieces converge on the same warning, independently: this isn't free automation. Osmani: "verification remains your responsibility... loops make mistakes unattended" and warns explicitly against "cognitive surrender" — building loops to avoid engagement rather than to accelerate it. LangChain frames the same concern positively, as "embed human oversight at natural checkpoints across all loop levels." Neither treats the human-out-of-the-loop framing as the actual goal.

Relevance to My Work

This lands directly on the harness-engineering thread already building in this vault — TechResearch/Harness_Engineering/harness_engineering, the Lilian Weng recursive-self-improvement piece (AIDigest/2026/07/17/2026-07-17-06-lilian-weng-harness-engineering-self-improvement), and Google's modular-prompt-transpilation article (AIDigest/2026/07/17/2026-07-17-06-google-modular-prompt-transpilation) are all describing pieces of the same shift these two posts name explicitly. It's also a near-exact description of what Hermes itself already is: nightly_cron.sh + run_synthesis.sh are Osmani's "automations" component, fix-agent/dispatcher's structural checks are the "sub-agent verification" component, Logs/memory/*.md is the "external state" component, and the cron-driven synthesis_incremental_cron.sh firing on its own schedule is LangChain's Loop 3 (event-driven) triggering Loop 4 (hill-climbing — the monthly full-sweep re-reading everything to catch what daily synthesis misses). Worth an explicit synthesis note connecting "loop engineering" as a named external framework to Hermes's existing architecture, and worth checking whether Hermes is missing a genuine Loop 2-equivalent (a dedicated verification/grading step, not just structural lint) — validator.py currently checks structure, not the correctness of what an agent wrote.

Reel Script

Hook: Two writers who've never cited each other coined the exact same term nine days apart this June — "loop engineering." If your AI workflow is still you typing a prompt, waiting, then typing the next one, this framework says you're already one generation behind it.

Core Concept: Loop engineering means you stop being the thing that re-prompts the agent every step, and instead build a system — a loop — that prompts the agent for you, checks its work, and decides what happens next, on its own. Think of the difference between driving a delivery route yourself, turn by turn, versus programming the route once and letting a robot run it every day. Addy Osmani lists five pieces every loop needs: a trigger that watches for new work, isolated workspaces so parallel tasks don't collide, a knowledge base the agent consults instead of asking you, connectors to existing tools, and — the important one — a second agent that checks the first agent's work, so nobody grades their own homework. LangChain frames the same idea as four stacked loops: one agent calling tools, a grader scoring its output, production events triggering the whole thing, and an outer loop that watches everything and tunes the system over time.

Hands-On: Here's what a real loop looks like end to end, re-derived from Osmani's own example. Every morning, an automation scans for CI failures and open bug reports — no human triggers it. It spins up an isolated copy of the codebase and writes a fix. Instead of shipping that straight out, it hands the fix to a second agent whose only job is to check the first one's work against a rubric: did this actually fix the reported bug, did it break anything else. Only if that grader approves does the system open a pull request and update the ticket. A human still reviews the PR before merge — the loop replaces the busywork of triaging and drafting, not the judgment call at the end.

Takeaway: The real unlock isn't "AI writes code while you sleep" — it's that a loop with a genuine verification step compounds, while a loop without one just automates your mistakes faster. If you're building any recurring agent automation, don't ask "does it run on its own" — ask "does something separate actually check its work before anything ships." Audit your own automations for that step first.

Discussion

(No questions yet — ask follow-ups via a Claude Code chat session on this repo; answers get appended here.)