Case study: Smyčka jako pracovní režim — jak nechat agenta iterovat, aniž ztratíte kontrolu

„Nech agenta běžet, dokud to nedodělá.” Láká to — a právem: spousta práce má povahu iterace ke stavu „hotovo”, ne jediného průchodu. Jenže bez governance je smyčka nejrychlejší cesta k nekonečnému běhu, spálenému rozpočtu nebo k agentovi, který si „hotovo” definuje sám.

Tahle case study popisuje, jak jsme smyčky nasadili v praxi, co přesně musí mít smyčka nasmlouváno předem — a jak se z provozní zkušenosti stal formální dodatek metodiky.

Co je smyčka v našem pojetí

Smyčka je výkonný režim, ve kterém agent opakovaně iteruje nad týmž záměrem, dokud nesplní slib dokončení, nevyčerpá rozpočet nebo nezačne stagnovat. Není to „agent běží pořád” — je to jednotka delegované práce se čtyřmi povinnými prvky:

• completion_promise — binární, strojově testovatelný slib. „Všech 17 testů zelených” ano; „výrazně zlepšit kvalitu” ne. Co se nedá otestovat, nedá se smyčce svěřit.
• max_iterations a rozpočet — tvrdé stropy (iterace, tokeny, čas). „Nekonečno” není hodnota; překročení znamená stop a eskalaci, nikdy tiché pokračování.
• Nezávislý hodnotitel — splnění slibu nikdy neposuzuje ten, kdo práci vykonal. Vykonavatel svoji práci systematicky nadhodnocuje; to není vada charakteru, to je statistika.
• Stopa každé iterace — smyčka emituje událost do auditního záznamu. Stagnace (N iterací bez pokroku) automaticky vede k pozastavení a drift signálu.

Lidská kontrola se nepřesouvá do každé iterace — přesouvá se na krystalizaci záměru před startem a na validační bránu po splnění slibu. Uprostřed člověk nepřekáží.

Živý běh

V červenci 2026 jsme režim ověřili end-to-end na živém vývojovém serveru: agent dostal záměr se strojově vyhodnotitelným slibem dokončení, iteroval v kontrolované smyčce, slib splnil v první iteraci a každý krok zapsal do governance záznamu. Brána se rozhodovala nad evidencí — artefakt, log iterací, splněný slib — ne nad vyprávěním.

Stejně cenné bylo, co běh odhalil kolem: infrastrukturní závislosti, které smyčka potřebuje (živé pracovní prostředí se správnou identitou), a nutnost po headless bězích uklízet — i tohle jsou governance poznatky, ne detaily.

Co nefungovalo

• První pokusy ukázaly klasický failure mode: slib formulovaný tak, že se nedal strojově vyhodnotit. Řešením nebylo „lepší snaha”, ale pravidlo: netestovatelný slib = záměr nelze schválit ke spuštění.
• Ukázalo se, že hodnotitel musí být povinný od střední úrovně rizika — u triviálních smyček stačí kalibrace, u všeho vážnějšího je nezávislé posouzení nutnost.

Z praxe do metodiky

Provozní zkušenost se smyčkami se přetavila do formálního dodatku metodiky (v0.95): smyčka jako uznaný výkonný režim s povinným runtime kontraktem, ochrana akceptačních kritérií před úpravou vykonavatelem (nejlevnější cesta k zelenému testu je smazat test — proto je to zakázané a auditované) a strojová před-brána, která lidskému kurátorovi odfiltruje formality, ale rozhodnutí nechá jemu.

To je GALDUR v kostce: metodika se mění dodatky podloženými praxí, ne prohlášeními.

Co si z toho odnést

• Smyčka bez strojově testovatelného slibu není autonomie, je to hazard.
• Rozpočty a stropy nejsou nedůvěra k agentovi — jsou to podmínky, za kterých mu lze důvěru dát.
• Nezávislé hodnocení není byrokracie; je to jediná obrana proti sebehodnocení vykonavatele.
• Lidská kontrola patří na začátek (krystalizace) a konec (brána) — ne do každé otáčky smyčky.

Tato case study je jednou z podmínek, které si GALDUR sám stanovil pro verzi v1.0 („alespoň 3 case studies”). Metodika je otevřená — dokumentace, šablony, komunita.