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 > <!-- deep-read:sections start --> ## 🧭 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 error messages. - Developer Support: consultation hours on context-budget strategies (compaction, offloading, sub-agents). - Community Engagement: not applicable to this source. - Strategic Alignment: add "harness quality" as a tracked KPI alongside model choice. #### Community - Maintainers: add a release-hygiene check that automated PRs must pass a real test, not a terminal "done" message. - Contributors: onboarding doc on building one safe loop before going hands-off. - Sponsors: not applicable to this source. - Ecosystem: coordinate a shared catalog of agent tool-design anti-patterns. #### WordPress - Core: not applicable to this source. - Core Performance: watch token/time budgets as a perf analogy for agent loops if Core adopts agentic tooling. - Core AI: adopt the four hard parts as a checklist for any responsible-AI agent pilot; require a verifier in every loop. - **Core Program Team:** add maker/checker to cross-team automation rituals. - Mobile: not applicable to this source. - Playground: build a reproducible "basic agent loop" lab for education. - Community: not applicable to this source. - Training: lesson on success-criteria-driven loops for the learn platform. - Marketing: not applicable to this source. - Support: write agent-readable error patterns into support tooling docs. - Design: not applicable to this source. - Documentation: examples-first doc on "define done before you begin." - Photos: not applicable to this source. - TV: not applicable to this source. - Polyglots: not applicable to this source. - Accessibility: not applicable to this source. - Meta: if .org adds agent tools, enforce idempotent writes against the API. - CLI: scaffold a wp-cli-friendly agent loop example with caps and a completion check. - Hosting: not applicable to this source. - Tide: completion-check + false-positive review loop maps directly to a maker/checker pattern. - Openverse: not applicable to this source. - Themes: not applicable to this source. - Plugins: provenance/idempotency checks for any agent-driven plugin tooling. #### The WPCC - Programs: not applicable to this source. - Projects: governance clinic on "a loop with no critic is an agent nodding along." - Funding experiments: not applicable to this source. ### FAIR - Technical independence: design verification loops with local checks, not vendor-model trust. - Policies and covenants: not applicable to this source. - Productized governance artifacts: a scorecard for "does this automated loop have a real critic?" ## 🧪 Hypotheses - Holding the model fixed and improving only the harness raises task success rates more than swapping to a stronger model. - Adding an automated completion check reduces false "done" declarations by an agent versus turn-termination alone. - Context compaction/offloading slows the performance decay ("context rot") over long loops. - Idempotent tool design reduces duplicate-state defects under retry conditions. - A separate critic (test/type-check/second model) catches more agent errors than self-review. - Few, non-overlapping tools improve tool-selection accuracy versus a large overlapping tool set. ## 📊 Methodology - Controlled A/B: same model, varied harness, measure benchmark/task completion delta. - Ablation on stopping brakes: compare turn-termination vs. completion-check on a fixed coding-agent task suite. - Long-run logging: track decision quality vs. context length with and without compaction. - Fault injection: force retries and count duplicate writes with idempotent vs. non-idempotent tools. - Inter-rater style design: maker-only vs. maker+independent-checker error-catch rates. ### ❓ Questions - What measurable thresholds define a "good" completion check across domains beyond passing tests? - How do you verify goals that lack a cheap automated oracle (design, writing, ambiguous tasks)? - At what loop length does context rot dominate, and is it model-specific? - Does the maker/checker split hold when the checker is itself an LLM with correlated blind spots? ### 🔮 Future Research - Standard benchmarks isolating harness contribution from model contribution. - Reusable libraries of "critics" (verifiers) per task class. - Cost models for context budgeting (compaction vs. sub-agent overhead). - Empirical limits of autonomy: when hands-off loops degrade vs. improve outcomes. ### 💡 Implications - Practice: engineers shift effort from prompt wording to loop/harness architecture and verification. - Policy: governance should require independent checks in any autonomous automation. - Security: idempotency and agent-readable errors become safety requirements, not nice-to-haves. - Education: curricula should teach "define done first" and maker/checker before full autonomy. - Funding models: investment may move from model access to harness/tooling engineering. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch–Kincaid Grade ~8–9 (short sentences, plain vocabulary, occasional jargon like "idempotent," "context rot"). Flesch Reading Ease roughly 60–65. #### 👀 Visual learners - Present: a referenced loop diagram ("some content could not be imported"), layered-engineering metaphor. - Improve: add an architecture diagram of the loop + brakes, and a before/after of a rotted vs. compacted context. #### 🔊 Aural learners - Present: none. - Improve: a 2–3 minute audio summary of the four hard parts. #### 🗣️ Verbal learners - Present: strong definitions and analogies ("budget, not a bucket"; "nodding along to its own work"). - Improve: a short glossary (harness, idempotency, compaction, context rot). #### 🧩 Kinesthetic learners - Present: a "where to start" build-up checklist. - Improve: a runnable sandbox loop with caps and a completion check. #### 🧠 Logical learners - Present: layered causal structure (prompt → context → harness → loop) and the doom-loop feedback chain. - Improve: a decision tree for which brake to add when. #### 🧑‍🤝‍🧑 Social learners - Present: thread format invites replies; cites a community debate. - Improve: discussion prompts and a peer-review rubric for loop design. #### 🧘‍♀️ Solitary learners - Present: self-paced reading with a clear takeaway. - Improve: reflection prompts ("what is your verifier?"). #### 🌿 Naturalistic learners - Present: organic metaphors ("rot," "spiral"). - Improve: lifecycle framing of a loop from seed task to autonomous run. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: linear thread text, readable as a sequence. - Improve: real headings/landmarks if republished; the embedded diagram needs alt text (it "could not be imported"). #### Keyboard navigation - Present: n/a for a text thread. - Improve: if republished as a web article, ensure focus order and skip links. #### Contrast and readability - Present: platform default contrast. - Improve: ensure 4.5:1 if reformatted into slides/graphics. #### Text resizing and reflow - Present: reflows on platform. - Improve: verify at 200% zoom in any republished form. #### Media and captions - Present: none. - Improve: caption/transcribe any audio or video version; add alt text to the loop diagram. #### Forms and interactions - Present: none. - Improve: n/a. #### Standards reference - Maps to WCAG 2.2 AA: 1.1.1 Non-text Content (missing diagram alt text), 1.4.3 Contrast, 1.4.10 Reflow, 2.4.6 Headings and Labels. ### 🌍 DEIB Assessment #### Cultural breadth - Present: none specific; examples are generic engineering scenarios. - Improve: include global/varied team contexts and case studies. #### Inclusive language - Present: gender-neutral, plain language; jargon mostly defined inline. - Improve: expand a glossary for non-native English readers ("idempotent," "harness"). #### Neurodiversity support - Present: chunked content, consistent structure, repeated framing. - Improve: more frequent headings and icon+text labels if republished. #### Representation - Present: cites named figures (Cherny, Karpathy) — a narrow, similar set of voices. - Improve: quote a broader range of practitioners. #### Psychological safety - Present: respectful, non-blaming tone toward learners. - Improve: note that "going hands-off" carries risk; avoid implying readers are behind ("you've felt it"). ### ✅ Logical Validity #### Strong reasoning - Causal: the doom-loop chain (rotted context → worse decision → more noise → further rot) is a clear, plausible positive-feedback argument (paragraph on context rot). Strengthen with measured decay curves. - Analogical: "treat context as a budget, not a bucket" cleanly maps a finite resource to a design rule (context section). Strong because the analogy yields concrete tactics (compaction, offloading, sub-agents). - Deductive-ish: "a terminal message ends the turn, not the task" follows from how the loop is defined — valid given the premise that turn-end ≠ goal-completion. #### Fallacies - Bandwagon / appeal to popularity: "Half your feed is suddenly saying the same thing" (opening). Weakness: popularity isn't evidence the framing is correct. Fix: lead with the mechanism, not the trend. - Appeal to authority: "Boris Cherny, the person who built Claude Code, said it plainly" (paragraph 2). Weakness: a creator's preference isn't proof loop engineering is optimal for all builders. Fix: pair the quote with outcome data. - Hasty generalization / unsourced anecdote: "kept the model fixed... jumped from the middle of a benchmark into the top five" (harness section). Weakness: no citation, no sample, possible cherry-pick. Fix: cite the benchmark and report the distribution, not one jump. - Hype framing / loaded contrast: "The model is becoming a commodity" (takeaway). Weakness: stated as settled fact; models still differ materially. Fix: qualify as a trend with conditions. #### Tone of voice - Confident, punchy, explainer-style with motivational close ("you'll stop prompting too"). Examples: "Nobody is competing on the while statement"; "The skill is knowing what to throw away." Slightly hype-leaning but mostly instructive. ### 🛡️ DARVO Analysis - Not applicable to this source — it's an explainer thread with no accusation, defense, or victim/offender dynamic to analyze. ## 🎯 Conclusion - Bottom line: the agent loop is trivial and solved; the engineering moved to the harness around it — stopping conditions, context hygiene, tool design, and a critic that can say no. The model is trending toward commodity; the loop is where value concentrates. - Practical next steps: start with a basic loop plus iteration/time/cost caps, define "done" as an automated check before you begin, protect context (compact, offload, sub-agents), audit tools (few, focused, idempotent, agent-readable errors), and put an independent critic in the loop before going hands-off. Treat the popularity and benchmark claims as motivation, not proof — verify the harness gains yourself. ## 🔄 Refactor Appendix — Loop Engineering Clearly Explained > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). ### 📚 Literature Atoms (H3) #### [H1] Builders write loops instead of prompting agents > [!quote] ID:rw_h1 > "I don't prompt Claude anymore. I have loops that are running. My job is to write loops." **Context & use**: - Opening of the thread, attributed to Boris Cherny. - Anchors the whole "loop engineering" framing — the shift from steering to system-design. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> #### [H2] The agent loop is a solved, trivial primitive > [!quote] ID:rw_h2 > "This loop is already solved. Every serious agent framework lands on roughly these six lines. Nobody is competing on the while statement." **Context & use**: - "First, the loop itself" section. - Justifies moving effort outward to the harness. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> #### [H3] The harness now matters more than the model > [!quote] ID:rw_h3 > "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." **Context & use**: - "The work moved outside the model" section; unsourced — treat as claim, not proof. - Reorders priorities toward harness engineering. **Tags**: #xref <!-- atomicity: 1 idea ✓ --> #### [H4] A loop needs a critic that can say no > [!quote] ID:rw_h4 > "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." **Context & use**: - "Hard part 4" section. - Direct evidence for maker/checker discipline — the worker doesn't grade its own homework. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> #### [H5] Define done as success criteria, then step back > [!quote] ID:rw_h5 > "Don't tell the model what to do, give it success criteria and watch it go." **Context & use**: - "The actual shift" section, attributed to Karpathy. - The verifier-first mindset: "done" is proven, not claimed. **Tags**: #xref #aphorisms <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] A loop without an independent critic just confirms itself **Claim** (one sentence, Courtney's voice): An autonomous loop only produces trustworthy output when a separate checker — a test, a type check, or a different model — grades the maker's work. **Evidence pointer**: [[#H4]] **Scope & conditions**: Holds when the checker's failure modes are uncorrelated with the maker's; breaks when an LLM critic shares the maker's blind spots. **Links**: - [[Loop engineering OS]] — because applies-in Courtney's maker/checker fleet - [[Verify before done]] — because extends the "re-derive from source" rule <!-- atomicity: 1 idea ✓ --> #### [P2] "Done" must be an automated check, not a terminal message **Claim** (one sentence, Courtney's voice): An agent ending its turn is not the same as finishing the job, so completion must be defined as an automated condition before the loop starts. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds where a cheap oracle exists (tests pass); breaks for ambiguous tasks with no automatable success criteria. **Links**: - [[loop-template skill]] — because applies-in the "when not to loop" gate - [[Goal-driven execution]] — because extends success-criteria-first <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Cross-link this thread to the Loop engineering OS hub and the loop-template skill gate. — vault `2. Areas/Loop Reports/` #fleeting #inbox - [F2] Open question: when the checker is an LLM, how do you guard against correlated blind spots with the maker? #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Add a "real verifier present?" row to the loop registry review — context loop-engineering OS #things - [ ] Draft a short DevRel explainer mapping prompt→context→harness→loop layers — context content #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Tweets/Loop Engineering Clearly Explained.md|Loop Engineering Clearly Explained by Akshay 🚀]] ## Highlights - 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." ([View Highlight](https://read.readwise.io/read/01kw3dqqzadwgjjnad096mm316)) - Note: The thesis quote — Boris Cherny (built Claude Code): "I don't prompt Claude anymore... My job is to write loops." - Tags: atom/literature/h1 - 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. ([View Highlight](https://read.readwise.io/read/01kw3dqz2zt5wgmatzp1eqdykk)) - Note: The inner while-loop is solved; nobody competes on it. The leverage moved to the outer loop. - Tags: atom/zettel/z1 - 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. ([View Highlight](https://read.readwise.io/read/01kw3dqsmr679c1shnrkb8ps6k)) - Note: The harness now matters more than the model — same model, better loop jumps benchmark rank. "Same brain, different loop." - Tags: atom/literature/h1 - 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. ([View Highlight](https://read.readwise.io/read/01kw3dqvt0t24gjgkcg0sqj8pp)) - Note: Other half of the job: put something in the loop that can say no — a test, type check, or real error. - Tags: atom/literature/h2 - 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. ([View Highlight](https://read.readwise.io/read/01kw3dqy5yc8k7qv11ms6b76t0)) - Note: Karpathy: give success criteria, not instructions; run loops with yourself nowhere in them. - Tags: atom/literature/h2