Loop Engineering Clearly Explained  🔗 **Source:** [Loop Engineering Clearly Explained](https://twitter.com/akshay_pachaar/status/2069118430582866051/?rw_tt_thread=True) > [!note]+ Document Notes > --- > tags: [loop-engineering, ai-agents, agentic-workflows, context-engineering, tool-calling] > author: Akshay Pachaar > source: Twitter/X > reference: https://twitter.com/akshay_pachaar/status/2069118430582866051/?rw_tt_thread=True > date created: 2026-06-26 09:00 > --- > # 🏷️ Title: Loop Engineering Clearly Explained > ## 🧭 Table of Contents > - [📝 Summary](#-summary) > - [📖 Main Content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action Items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future Research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning Styles Assessment](#-learning-styles-assessment) > - [📊 Accessibility Assessment](#-accessibility-assessment) > - [🌍 DEIB Assessment](#-deib-assessment) > - [✅ Logical Validity](#-logical-validity) > - [🛡️ DARVO Analysis](#-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > ### 🔗 References > - Boris Cherny (creator of Claude Code) — quoted on writing loops instead of prompts. > - LangChain — "Agent = Model + Harness" framing. > - Anthropic — tool-design rule of thumb (if a human can't pick the tool, neither can the agent). > - Andrej Karpathy — "give it success criteria and watch it go" overnight research loops. > ## 📝 Summary > - What happened: Akshay Pachaar explains "loop engineering" — the framing that agent builders have stopped prompting move-by-move and now design the autonomous loop the model runs inside. > - Why it matters: The agent loop itself (model → tool → context → repeat) is trivial and solved; the real engineering moved to the harness around it — stopping conditions, context hygiene, tool design, and a critic. > - Key stakeholders: Agent framework authors, AI engineers, DevRel and OSPO teams building agentic tooling, anyone running autonomous coding agents. > - Risks and tradeoffs: Hype framing ("half your feed"), survivorship in the benchmark anecdote, and the temptation to treat "loop engineering" as a brand rather than a discipline. > - Bottom line: The model is becoming a commodity; the loop around it is where the engineering now lives. Design the goal, the loop's brakes, and the verifier — then step back. > ## 📖 Main Content > - The core agent loop is a plain while-loop: the model reads context, asks to call a tool, you run the tool and feed the result back, and it repeats until the model stops asking for tools. Every serious framework lands on roughly the same six lines, so nobody competes on the loop primitive itself. > - The "center of gravity" keeps drifting outward through nested layers: prompt engineering (the words sent) → context engineering (everything the model sees) → harness engineering (the code running tools, state, errors) → loop engineering (the autonomous cycle driving toward a goal). Each wraps the previous. > - LangChain's framing: Agent = Model + Harness. If you're not building the model, you're building the harness — and the claim is that the harness now matters more than the model (teams held the model fixed, changed only surrounding code, and climbed benchmark rankings). > - Four hard parts: > - Knowing when to stop — a terminal message ends the turn, not the task. Layer brakes: max iterations, budget/time limits, no-progress detection, and a real automated completion check. > - Keeping context clean — long loops accumulate junk ("context rot") and spiral into a "doom loop." Treat context as a budget: compaction, offloading to files, sub-agents. > - Tools the agent can actually use — few, focused, non-overlapping tools; idempotent writes; error messages written for the agent to act on. > - Something that can say no — separate the maker from the checker; a test, type check, or real error grades the work so the agent doesn't grade its own homework. > - The shift: prompting is steering move-by-move; loop engineering is building the system that steers, then stepping back. Your job becomes designing the goal (as checkable success criteria), the loop (with brakes), and the verifier (so "done" is proven). > - Contested/uncertain: the benchmark jump ("middle to top five") is an unsourced anecdote; "half your feed" is rhetorical, not evidence. > ### 🗒️ Notes > - Boris Cherny anchor quote reframes the whole piece: he writes loops, not prompts. > - "Model → tools → context → repeat" is the canonical loop; presented as already solved. > - Context rot + doom loop: rotted context produces worse decisions that add more noise, compounding over turns. > - Anthropic's tool heuristic: if a human engineer can't say which tool fits, the agent has no chance. > - Idempotency warning is concrete: a retried "create customer" call can double-bill — state changes must be safe to call twice. > - Errors are "the next instruction" inside a loop — write them for an LLM reader. > - Maker/checker is the load-bearing idea: "the other half is putting something in the loop that can say no." > - Karpathy's overnight research loops (tweak → test → keep what works → discard) with himself "nowhere in the loop" is the aspirational end state. > - Onboarding path: basic loop + caps first, define "done" up front, protect context, audit tools, add a critic, go hands-off only once you trust the thing that says no. > ## 📚 References > - [Boris Cherny on Claude Code](https://www.anthropic.com/claude-code) — creator quoted on writing loops. > - [LangChain](https://www.langchain.com/) — "Agent = Model + Harness" framing. > - [Anthropic — building effective agents](https://www.anthropic.com/research/building-effective-agents) — tool design and harness guidance. > - [Andrej Karpathy](https://karpathy.ai/) — success-criteria-driven autonomous loops. > ## 🗣️ Paraphrase > - Your feed suddenly agrees: stop prompting agents, start engineering loops. The person who built Claude Code says he writes loops, not prompts — so the interesting work isn't the instruction, it's the system around it. > - The agent is just a loop: read context, call a tool, feed the result back, repeat. That part's solved. What everyone actually engineers is the harness — and the harness now outweighs the model. > - It breaks in four predictable places: stopping at the right time, keeping context from rotting, giving the agent tools it can actually pick and safely retry, and putting a critic in the loop that can say no. > - The real move is becoming the person who designs the machine: write the goal as checkable criteria, build a loop with brakes, and add a verifier so "done" is proven, not claimed. > ## 📰 Newsletter > - Not directly WordPress-focused, but there's a clean OSS/DevRel bridge: loop engineering maps onto how maintainers should design any automated contributor or CI workflow. The "put something in the loop that can say no" rule is just a passing test gate or a required review — the same maker/checker discipline that keeps a release pipeline honest. If you run agentic tooling against a WordPress codebase, the takeaways port directly: cap iterations, define "done" as a green test run (not a vibe), and write tool/error output an agent can act on. > ## ✅ Action Items > #### DevRel > - Developer advocacy: produce a short talk or demo that walks the four hard parts of loop engineering with a live coding-agent example. > - Education: build an office-hours module on maker/checker loops — "define done before you start." > - Developer experience: ship a starter template for a basic agent loop with iteration caps, timeouts, and a completion check baked in. > - Developer marketing: a content series mapping prompt → context → harness → loop layers. > - Community management: open a discussion thread collecting community "doom loop" war stories and fixes. > - Internal/external/cross-project: align on a shared definition of "done = verifier passes" across teams shipping agents. > #### OSPO > - Policy & Governance: set a policy that any merged automation includes an independent check, not self-grading. > - License Compliance: not applicable to this source. > - Security Management: require idempotent writes for any agent tool that mutates state (prevents duplicate/double-billing failures). > - Software Inventory: inventory which internal agent tools have agent-readable e  Half your feed is suddenly saying the same thing. Stop prompting your agents, start engineering loops. Boris Cherny, the person who built Claude Code, said it plainly: "I don't prompt Claude anymore. I have loops that are running. My job is to write loops." The person who builds one of the most popular coding agents on earth doesn't prompt it. So what is he doing instead? That's the whole idea behind loop engineering. Now let's break down why it's harder than it looks. ### First, the loop itself An agent isn't a magic box. At its core, it's a plain loop: Some content could not be imported from the original document. [View content ↗](https://twitter.com/akshay_pachaar/status/2069118430582866051/?rw_tt_thread=True) The model reads the context. It asks to call a tool. You run the tool and feed the result back. The model reads again, and this repeats until it stops asking for tools. **Model → tools → context → repeat.** Here's the part that surprises people. **This loop is already solved.** Every serious agent framework lands on roughly these six lines. Nobody is competing on the while statement. So if the loop is trivial, what is everyone actually engineering? ### The work moved outside the model The center of gravity in AI keeps drifting away from the model itself. * **Prompt engineering.** The words you send. * **Context engineering.** Everything the model sees, not just your instructions. * **Harness engineering.** The code around the model that runs tools, tracks state, and handles errors. * **Loop engineering.** The autonomous cycle that drives the whole thing toward a goal. Each layer wraps the one before it. You didn't stop caring about prompts. You just realized the prompt is one small piece of a much bigger system. LangChain puts it cleanly. **Agent = Model + Harness. If you're not the model, you're the harness.** And here's the finding that should reorder your priorities. **The harness now matters more than the model.** Teams have kept the model fixed, changed only the code around it, and jumped from the middle of a benchmark into the top five. Same brain, different loop. Loop engineering is the discipline of building everything that brain runs inside. Let me show you the parts that actually break. ### Hard part 1: knowing when to stop This is the problem nobody warns you about. When an agent stops asking for tools, it has ended its turn. That is not the same as finishing the job. Picture a coding agent. It writes some code, glances around, sees that progress was made, and announces it's done. The tests still fail. It declared victory anyway. **A terminal message ends the turn, not the task.** Confusing those two is the most common way loops go wrong. Good loops stop for the right reasons, so you layer several brakes: * **Max iterations.** A hard cap so a stuck agent can't run forever. * **Budget and time limits.** A ceiling on tokens, money, and seconds. * **No-progress detection.** If it repeats the same call with the same arguments, it's spinning. * **A real completion check.** An automated condition proving the job is done. That last one carries the weight. "Done" should mean the tests pass, not the agent feeling good about its work. ### Hard part 2: keeping the context clean Long loops rot from the inside. The more turns an agent takes, the more junk piles into its context, like old tool outputs, dead ends, and stale reasoning. Model performance drops as that pile grows. The field calls it **context rot.** A loop makes it spiral. A rotted context produces a worse decision, which adds more noise, which rots the context further. People call this the doom loop, and you've felt it. The agent gets dumber the longer it runs. You fight it by treating context as a budget, not a bucket: * **Compaction.** Summarize the conversation when it gets long, then continue from the summary. * **Offloading.** Push huge outputs to a file and keep only the slice you need. * **Sub-agents.** Hand a messy subtask to a separate agent and let only its clean result return. The instinct is to keep everything, just in case. The skill is knowing what to throw away. ### Hard part 3: tools the agent can actually use A loop is only as good as the tools inside it. Pile on a hundred tools and the agent loses track of which one to reach for. A tight set of focused, non-overlapping tools wins. Anthropic's rule of thumb is sharp. If a human engineer can't say for certain which tool fits, the agent has no chance. Two things matter more than people expect: * **Make writes safe to repeat.** Loops retry, and if a retried "create customer" call makes a second customer, you'll wake up to duplicate records and double billing. Anything that changes state has to be safe to call twice. * **Write error messages for the agent, not the human.** A good error tells the agent what to do next. Before a tool ships, ask whether an LLM reading its error would know the next move. In a loop, an error isn't a dead end. It's the next instruction. ### Hard part 4: something that can say no Autonomous loops have a quiet failure mode. An agent left alone tends to agree with itself. The sharpest comment in the whole debate nailed it. Designing the loop is half the job, and the other half is putting something in the loop that can say no, like a test, a type check, or a real error. **A loop with no critic is just an agent nodding along to its own work.** The fix is to separate the maker from the checker. One model does the work. A different check, often a separate model or a hard test, grades it. The worker doesn't grade its own homework. ### The actual shift Now Cherny's quote makes sense. Prompting is you steering the agent move by move. Loop engineering is you building the system that steers it, then stepping back. Your job changes from giving instructions to designing three things: 1. **The goal,** written as success criteria the agent can check itself against. 2. **The loop,** with sane brakes so it stops well. 3. **The verifier,** so "done" is proven, not claimed. Andrej Karpathy captures the mindset. Don't tell the model what to do, give it success criteria and watch it go. He runs research loops overnight that tweak a script, test it, keep what works, and discard what doesn't, with himself nowhere in the loop. He arranges it once and hits go. That's the whole move. You stop being the hands and become the person who designs the machine. ### Where to start You don't need an overnight autonomous agent on day one. Build up to it: 1. **Start with the basic loop,** and add a max-iteration cap, a timeout, and a cost ceiling right away. 2. **Define "done" as an automated check** before you begin, not a vibe afterward. 3. **Protect the context.** Compact long runs, offload big outputs, isolate messy subtasks. 4. **Audit your tools.** Keep them few and focused, make writes safe to repeat, and rewrite errors so an agent can act on them. 5. **Put a critic in the loop.** Only go fully hands-off once you trust the thing that says no. ### The takeaway Loop engineering isn't a framework or a tool you install. It's a shift in where you aim your effort. The model is becoming a commodity. The loop around it is where the real engineering lives now. The best builders stopped asking "what should I tell the agent to do?" They started asking "what system would do this without me?" Answer that one well, and you'll stop prompting too. Here's a summary of  --- Thanks for reading! Cheers :) Akshay., Loop Engineering Clearly Explained, Akshay 🚀, 01kw33y9ybk2x8aj98zssjgr47.