# Loop Engineering Clearly Explained. Akshay (2026-06-30) > **Cikk:** *Loop Engineering Clearly Explained* • **Szerző:** Akshay (Agent Cookbook) • **Forrás:** • **Publikálva:** 2026-06-30 • **Platform:** Agent Cookbook (Beginner szint) • **Hossz:** 1327 szó > **Sorozat:** Ez a cikk a „Previous” linkje a 14-step roadmap-nak (Lev Deviatkin, 2026-07-06). A „Next” cikk: „A harness for every task: dynamic workflows in Claude Code.” > **Forrásanyagok:** Boris Cherny (Claude Code alkotója), Andrej Karpathy, LangChain (Agent = Model + Harness), Anthropic --- ## A lényeg Az Agent Cookbook 2026-06-30-i cikke (Akshay) a loop engineering „miért nehéz” oldalát mutatja be — a 14-step roadmap (Lev Deviatkin, 2026-07-06) előzményeként. A kiindulópont: **Boris Cherny, a Claude Code alkotója** szerint „I don't prompt Claude anymore. I have loops that are running. My job is to write loops.” A cikk központi tézise: a loop maga triviális (minden agent framework ugyanarra a hat sorra landol: `while True: response = model(context); if response.has_tool_calls(): ...; else: break`). A nehézség **nem a loopban van**, hanem abban, amit köré építesz. A cikk négy „hard part”-ban szervezi a kihívásokat: (1) **knowing when to stop**, (2) **keeping the context clean**, (3) **tools the agent can actually use**, (4) **something that can say no**. A kurrens mérési eredmény: **a harness többet számít, mint a model** — csapatok modell-fixen tartásával, csak a körülötte lévő kódot cserélve a benchmark közepéről a top 5-be ugrottak. --- ## 1. A loop maga triviális, hat sor Egy agent a magjánál nem egy varázsdoboz, hanem egy egyszerű loop: ```python while True: response = model(context) if response.has_tool_calls(): results = run_tools(response.tool_calls) context += results else: break ``` A modell olvassa a contextet, kéri egy tool hívását, te futtatod a tool-t és az eredményt visszafordítod a contextbe. A modell újraolvassa, és ez ismétlődik, amíg a modell be nem fejezi a tool-hívásokat. A meglepő rész: **ez a loop már meg van oldva.** Minden komoly agent framework nagyjából erre a hat sorra landol. Senki nem a `while` statement-en versenyez. Ha a loop triviális, min dolgozik mindenki? ## 2. A munka a modell mellé költözött, az engineering rétegek A center of gravity az AI-ban folyamatosan a modell mellé sodródik. Négy egymásra épülő réteg: 1. **Prompt engineering.** A szavak, amiket küldesz. 2. **Context engineering.** Minden, amit a modell lát, nem csak az utasításaid. 3. **Harness engineering.** A modell körüli kód, ami tool-okat futtat, state-et kezel, hibákat dolgoz fel. 4. **Loop engineering.** Az autonóm ciklus, ami az egészet a cél felé hajtja. Minden réteg az előzőre épül. Nem szűnt meg a promptolás, csak rájöttél, hogy a prompt a rendszer egy kis része. A LangChain megfogalmazása tiszta: **Agent = Model + Harness.** Ha nem te vagy a modell, te vagy a harness. A legfontosabb finding, aminek átrendezi a prioritásaidat: **a harness most többet számít, mint a model.** Csapatok a modellt fixen tartva, csak a körülötte lévő kódot cserélve a benchmark közepéről a top 5-be ugrottak. Ugyanaz az agy, más loop. Loop engineering = a fegyelem, hogy mindent megépítesz, amiben az agy fut. ## 3. Hard part 1: knowing when to stop Ezt a problémát senki nem warning-olja. Amikor az agent befejezi a tool-hívásokat, **befejezte a turn-jét.** Ez nem ugyanaz, mint a feladat befejezése. Képzelj el egy coding agent-et. Ír egy kis kódot, körbenéz, látja, hogy volt haladás, és kijelenti, hogy kész. A tesztek még mindig elbuknak. A győzelmet önmagának deklarálta. **A terminálüzenet a turn-t zárja, nem a feladatot.** Ez a két dolog összekeverése a loopok elromlásának leggyakoribb oka. Jó loopok a jó okoknál állnak meg, ezért több féket rétegsz egymásra: - **Max iterations**, hard cap, hogy egy beragadt agent ne fusson a végtelenségig. - **Budget és time limit**, plafond a tokenekre, pénzre és másodpercekre. - **No-progress detection**, ha ugyanazt a hívást ugyanazokkal az argumentumokkal ismétli, spinning-ol. - **Real completion check**, automatizált condition, ami bizonyítja, hogy a munka kész. Az utolsó hordozza a terhet. A „done” jelentése: a tesztek átmennek, nem az agent jó érzése a saját munkájáról. ## 4. Hard part 2: keeping the context clean A hosszú loopok belülről rothadnak. Minél több turn-t vesz egy agent, annál több szemét halmozódik a contextjében, régi tool outputok, zsákutcák, lejárt reasoning. A modell teljesítménye esik, ahogy a halom nő. Az ipar „context rot”-nak hívja. A loop ezt spirálissá teszi. A rothadt context rosszabb döntést produkál, ami újabb zajt ad hozzá, ami a contextet tovább rothasztja. Ezt „doom loop”-nak hívják — és érezted már. Az agent butul, minél tovább fut. A harcot úgy vívod, hogy a contextet **költségvetésnek** kezeled, nem vödörnek: - **Compaction**, összegzi a beszélgetést, amikor hosszú lesz, aztán a summaryról folytatja. - **Offloading**, a nagy output-ot fájlba pusholja, és csak a szeletét tartja meg, amire szüksége van. - **Sub-agents**, egy rendetlen részfeladatot átad egy külön agentnek, és csak a tiszta eredményt hagyja visszatérni. Az instinct az, hogy mindent megtartsz „hátha kell”. A skill az, hogy **tudd, mit dobsz el.** ## 5. Hard part 3: tools the agent can use A loop csak annyira jó, mint a tool-ok, amik benne vannak. Halmozz fel száz tool-t, és az agent elveszti a fonalat, melyikhez nyúljon. **Egy szűk, fókuszált, nem-átfedő tool-set nyer.** Az Anthropic szabálya éles: ha egy emberi mérnök nem tudja biztosan megmondani, melyik tool passzol, az agent-nek esélye sincs. Két dolog számít többet, mint az emberek gondolnák: - **A write-okat safe-to-repeat-té tenni.** A loopok retry-znak, és ha egy újrapróbált „create customer” hívás egy második customer-t hoz létre, duplicate rekordokra és dupla számlázásra ébredsz. Bármi, ami state-et változtat, safe-to-call-twice kell legyen. - **Az error message-eket az agent-nek írni, nem az embernek.** A jó error megmondja az agentnek, mit tegyen legközelebb. Mielőtt egy tool kimegy, kérdezd meg: ha egy LLM olvassa az error-t, tudná-e a következő lépést? Egy loop-ban az error nem zsákutca. A következő utasítás. ## 6. Hard part 4: something that can say no Az autonóm loopoknak van egy csendes failure mode-ja. **Az agent egyedül hagyva hajlamos egyetérteni önmagával.** A vita legélesebb kommentje megragadta: a loop megtervezése a munka fele, a másik fele, hogy **tegyél valamit a loopba, ami tud nemet mondani**, mint egy teszt, type check, vagy valódi error. Egy kritikus nélküli loop csak egy agent, aki bólogat a saját munkájára. A javítás: **szétválasztani a maker-t a checker-től.** Egy modell csinálja a munkát. Egy másik check (gyakran külön modell vagy hard teszt) osztályozza. A worker nem javítja a saját házi feladatát. ## 7. A tényleges shift Most Cherny idézete érthető. A prompting = te kormányozod az agent-et lépésről lépésre. A loop engineering = te megépíted a rendszert, ami kormányozza, aztán hátralépsz. A munkád megváltozik: ahelyett, hogy utasításokat adsz, három dolgot tervezel: 1. **A goal**, siker-kritériumok formájában, amiket az agent maga ellenőrizhet. 2. **A loop**, sane brakes-ekkel, hogy jól álljon meg. 3. **A verifier**, hogy a „done” bizonyított legyen, ne állított. Andrej Karpathy megfogalmazza a mindsetet: **„Don't tell the model what to do, give it success criteria and watch it go.”** Éjjel futó research loopokat üzemeltet, amelyek tweak-elnek egy scriptet, tesztelik, megtartják ami működik, eldobják ami nem — ő maga nincs a loopban. Egyszer elrendezi, és megnyomja a go-t. Ez az egész move. Ahelyett, hogy a kéz vagy, a gépet tervező ember leszel. ## 8. Hol kezdj Nem kell első nap egy overnight autonóm agent. Építsd fel odáig: 1. **Kezdd az alap looppal, és adj hozzá azonnal** max iteration cap-et, timeout-ot és cost ceiling-et. 2. **Definiáld a „done”-t** automatizált check-ként, mielőtt elkezded, ne vibe-ként utána. 3. **Védd a contextet.** Compact-old a hosszú futásokat, offload-old a nagy outputokat, izoláld a rendetlen részfeladatokat. 4. **Auditáld a tool-jaidat.** Tartsd őket kevesen és fókuszáltan, safe-to-repeat write-okat, és írj újra error-okat, amikre az agent tud cselekedni. 5. **Tegyél egy kritikust a loopba.** Csak akkor menj teljesen hands-off-ba, ha megbízol abban, ami nemet tud mondani. ## 9. A cikk Henky-szempontú jelentősége Ez a cikk a **frontier AI engineering** kategóriájában az egyik legrövidebb, legsűrűbb 2026-os bevezető. Az Akshay-féle „Clearly Explained” a 14-step roadmap (Lev Deviatkin, 2026-07-06) előzménye, és a két cikk együtt ad teljes képet: az előbbi a „miért fáj” négy hard part-ját adja, az utóbbi a „hogyan építsd meg” 14 lépését. Az ai-automation topic szempontjából hat szál a fontos: 1. **A „loop maga triviális” insight.** Minden serious agent framework ugyanarra a hat sorra landol. A munka a modell mellé költözött — harness engineering + loop engineering. Ez a „Harness > Model” finding a podcast-processing pipeline-ra is érvényes: a sub-agent-ek, az auto-review, a golden dataset, a state file-k mind a harness részei, és ezek együttesen adják a rendszer értékét, nem a modell önmagában. 2. **Knowing when to stop, a terminálüzenet vs. feladat megkülönböztetése.** Ez a Ralph Wiggum loop (Geoffrey Huntley) és a Deviatkin-cikk 12. lépésének alapja. A podcast-processing sub-agent-ek esetén ez a `/goal` Claude Code primitív megfelelője. 3. **Context rot és doom loop, a context budget, nem bucket.** A compaction + offloading + sub-agents triád a Henky-ágens `memory-relevance-filter` és `recite-before-answer` mintáinak felel meg. A Deviatkin-cikk 7. lépésének (skills) és az Akshay-cikk 4. hard part-jának összekapcsolása: a skill = offloading, a recite-before-answer = compaction. 4. **Safe-to-repeat writes.** A tool-ok tervezésénél a Henky-loop-okban is érvényes: a transcript sync, a wiki raw copy, a topic file patch mind idempotens kell legyen. A 30 napos re-audit ciklus a permission scope creep ellen. 5. **Error messages for the agent, not the human.** A Henky-loop-okban a sub-agent prompt-ok és a failure_modes feedback közvetlenül ezt a mintát alkalmazzák: a sub-agent-ek LÁTJÁK a közelmúltbeli hibákat (lásd a failure_modes feedback pipeline-t a `references/auto_review.py` `render_subagent_prompt.py --with-failures`). 6. **Andrej Karpathy „success criteria” elmélete.** A Verifier = a loop szíve. A podcast-processing pipeline-ban ez az `auto_review.py` golden dataset alapú pontozás. A Deviatkin-cikk 11. lépése (minimum viable loop: one automation + one skill + one state file + one gate) és az Akshay-cikk „The verifier, so done is proven, not claimed” összhangban vannak. A cikk értéke: egy 1327 szavas, 4 hard part-os, Karpathy-idézettel és Cherny-idézettel keretezett sűrű tutorial, amely a loop engineering „miért nehéz” oldalát adja, és kiegészíti a 14-step „hogyan építsd meg” roadmapet. A két cikk együttesen a 2026 nyár loop engineering kézikönyvének tekinthető. --- ## Forrás - **Eredeti cikk:** - **Szerző:** Akshay (Agent Cookbook) - **Publikálva:** 2026-06-30 • **Platform:** Agent Cookbook (Beginner szint) - **Sorozat:** Previous = (nincs), Next = *Loop engineering: the 14-step roadmap from prompter to loop designer* (Lev Deviatkin, 2026-07-06). Következő utána: *A harness for every task: dynamic workflows in Claude Code* - **Forrásanyagok:** Boris Cherny (Claude Code alkotója, „I don't prompt Claude anymore”), Andrej Karpathy („Don't tell the model what to do, give it success criteria”), LangChain (Agent = Model + Harness), Anthropic - **Cikk kulcsszavak:** loop engineering, harness engineering, Boris Cherny, Andrej Karpathy, knowing when to stop, context rot, doom loop, compaction, offloading, sub-agents, safe-to-repeat writes, error messages for the agent, maker vs. checker, real completion check, success criteria, verified not claimed - **Feldolgozás:** Henky-pipeline (`article_from_blog`, 2026-08-13, fő agent self-write, 1327 szó < 5000 küszöb)