8. 8. 2026↻ Aktualizováno 6. 10. 2026

Loop engineering: když AI agent nepotřebuje další prompt, ale bezpečnou smyčku

Vývojář pracující s AI agentem vedle tabule se smyčkou objevování, provedení, ověření a review

Aktualizace 6. října 2026: testujte i agenta, který staví další agenty

Nová případová studie Anthropicu z 5. října popisuje Cresta Conductor nad Claude Agent SDK. Cresta hodnotí nejen výsledný artefakt, ale také cestu k němu, kvalitu a spotřebu. Produkt byl oznámen již 11. června; nové je zveřejnění této případové studie, nikoli říjnový start produktu.

Pro firemní tým bych z toho převzal následující postup. Když agent upraví klasifikátor supportu, musí vedle změny dodat i důkaz, že nezhoršil fungující případy. Jedna zelená ukázka nestačí.

Připravil bych čtyři úlohy pro samotného stavitele: vytvořit klasifikátor, doplnit test, změnit eskalační pravidlo a dohledat příčinu chybného zařazení. Každá má mít předem popsaný výsledek, povolené zdroje a kontrolu. Změnu modelu nebo skillu pak porovnejte na stejné sadě.

U n8n bych oddělil návrh úpravy od nasazení workflow. Agent může připravit změnu a testovací případy; testy musí zahrnovat i sadu schválenou člověkem, kterou si agent nesmí přepsat jen proto, aby prošel. Člověk zkontroluje diff a výsledky před aktivací.

Sledujte také cenu opravy a počet zásahů reviewera. Pokud agent vygeneruje funkční řešení, ale překročí oprávnění nebo odstraní nepohodlný test, není to úspěšný běh. Jde o navržený pilot inspirovaný případovou studií, nikoli o moje měření Conductor ani ověřenou integraci s n8n.

AI agent nezačne být užitečný ve chvíli, kdy mu přidáte další prompt. Začne být užitečný ve chvíli, kdy mu postavíte smyčku: odkud bere práci, co přesně smí udělat, jak se výsledek ověří, co se uloží pro další běh a kdy musí počkat na člověka.

Tomu se začíná říkat loop engineering. Není to nový model ani magické tlačítko pro autonomii. Je to praktická disciplína kolem agentů. IBM ji popisuje jako návrh agentních workflow, která opakovaně vedou agenta k cíli; pro vývojáře se těžiště přesouvá od jednotlivého promptu k systému, jenž agenta spouští, kontroluje a koriguje.

Prompt vyřeší jeden krok. Smyčka řeší provoz

Prompt může říct: „Projdi nové support tickety a navrhni odpovědi.“ Smyčka doplní všechno, co rozhoduje o tom, zda to lze provozovat každý den:

  • nový ticket přijde z Help Scoutu nebo CRM,
  • levný klasifikátor ho roztřídí a odstraní citlivé údaje,
  • hlavní agent připraví návrh jen z povolené knowledge base,
  • jiný krok ověří citace, tón a pravidla pro eskalaci,
  • návrh se odešle jen po schválení člověkem nebo v přesně vymezených případech,
  • log uloží vstupy, použité zdroje, výsledek, cenu a důvod rozhodnutí.

Tohle je rozdíl mezi demo automatizací a pracovním procesem. Agenta nespouštíte proto, že „umí přemýšlet“. Spouštíte ho proto, že jste mu dali omezenou práci, ověřitelný výstup a jasný stop stav.

Pět částí, které by měla mít první smyčka

1. Jasný zdroj práce

Smyčka potřebuje konkrétní trigger: nový e-mail ve frontě, nevyřešený ticket, pull request s červeným CI, změnu v tabulce nebo dávku faktur. Nezačínejte volným zadáním typu „najdi, co je potřeba udělat“. U interních agentů bývá lepší jeden úzký backlog s vlastní prioritou a ownerem.

2. Omezené provedení

Agent musí mít konkrétní nástroje, oprávnění a rozpočet. U coding agenta to znamená izolovaný Git worktree, branch, povolené příkazy a limit času či tokenů. U CRM enrichmentu to znamená read-only dotazy, schéma očekávaného JSONu a zákaz zapisovat do produkce bez následné akce workflow.

3. Nezávislé ověření

Nejčastější chyba je nechat agenta hodnotit vlastní práci. U změny kódu má ověřovat CI, test nebo druhý agent s jiným promptem a bez motivace „dokončit úkol“. U dokumentové extrakce porovnejte povinná pole, součty a zdrojovou stránku PDF. U odpovědi zákazníkovi ověřte zdroj, politiku a případně citlivé kategorie.

Nezávislé neznamená nutně drahé. Často stačí deterministická kontrola: validace JSON Schema, účetní součet, test, diff, whitelist zdrojů nebo pravidlo, že bez evidence nelze pokračovat.

4. Stav a důkaz

Každý běh musí zanechat stopu. Minimálně ID vstupu, verzi promptu či skillu, použité nástroje, výstup, cenu, výsledek validace a odkaz na artefakt. Bez toho nepoznáte, zda agent práci vyřešil, pouze ji deklaroval, nebo ji má zkusit později jinak.

Pro malý n8n nebo Make workflow je tím stavem tabulka či databázový záznam. U vývoje to může být issue, PR, test run a krátký memory.md pro další běh. Stav není vedlejší administrativa; je to paměť smyčky.

5. Stop podmínka a lidská brána

Autonomie má mít hranici. Smyčka se zastaví po úspěšném testu, po třech neúspěšných pokusech, při překročení rozpočtu, při nedostatečné jistotě nebo před nevratnou akcí. Člověk pak neschvaluje každý token, ale konkrétní přechod: merge do mainu, odeslání faktury, změnu CRM záznamu nebo odpověď v citlivém případu.

Kde to nasadit jako první

Nejlepší první použití není „autonomní firma“. Vyberte opakující se práci s jasným vstupem a levným ověřením:

  • Lead triage: agent obohatí firmu, navrhne segment a důvod; workflow zapíše návrh do CRM až po kontrole povinných dat.
  • Faktury a dokumenty: OCR a LLM vytáhnou strukturu, pravidla zkontrolují DIČ, částky a duplicity; výjimky jdou účetní.
  • Support: klasifikace a návrhy odpovědí běží automaticky, ale refundace, bezpečnost a právní dotazy mají lidskou bránu.
  • CI a údržba: agent si vezme malý failing test, pracuje v worktree, spustí testy a otevře PR; nemerguje sám.
  • Content pipeline: agent připraví rešerši, osnovu a varianty, ale faktická tvrzení a publikace se zastaví na review.

V n8n nebo Make se taková smyčka často skládá z triggeru, fronty, agentního kroku, validátoru, uloženého stavu a větvení pro eskalaci. Model je jen jedna komponenta. Obvykle ani nemusí být nejsilnější: levné klasifikace a kontroly nechte menším modelem nebo pravidly, dražší reasoning používejte jen tam, kde má přidanou hodnotu.

Oprávnění nejsou brána u každého kroku. Jsou další vrstva smyčky

Ruční potvrzení každého příkazu vypadá bezpečně, ale při delší práci rychle vznikne approval fatigue. Člověk přestane číst a jen kliká na „povolit“. Druhý extrém je pustit agenta v bypass nebo full-access režimu a doufat, že zadání pochopil správně.

Claude Code proto přidal režim Auto, který každou akci před spuštěním posílá přes samostatný bezpečnostní klasifikátor. Ten má blokovat kroky, které překračují zadání, míří na neznámou infrastrukturu, vypadají jako reakce na škodlivý obsah nebo jsou nevratné. Není to totéž jako bypassPermissions: explicitní ask a deny pravidla dál platí, chráněné cesty se automaticky nepovolí a po opakovaných blocích se agent vrací k ručnímu schvalování.

Od 14. srpna 2026 má být Auto výchozí pro nové relace na plánech Pro, Max a Team. Pokud chcete režim nastavit sami, patří do uživatelského ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "auto"
  }
}

Projektové nastavení nemůže Auto samo zapnout. To je důležitá hranice: repozitář si nesmí přidělit širší oprávnění tím, že do sebe schová konfiguraci. Ve firmě navíc dává smysl spravovat výchozí režim centrálně a pomocí disableAutoMode ho vypnout tam, kde klasifikátor neodpovídá vašemu modelu rizika.

Praktické pravidlo pro agentní smyčku: automatizujte běžné kroky, ne rozhodnutí s velkým dopadem. Agent může v izolovaném worktree instalovat závislosti z lockfile, upravovat kód a spouštět testy. Produkční deploy, změna IAM, práce se secrets, hromadné mazání, odeslání citlivých dat nebo merge bez review má zůstat explicitní bránou. Auto režim snižuje počet přerušení; nenahrazuje sandbox, auditní stopu ani odpovědnost za výsledek.

Co měřit místo dojmu, že agent „funguje“

Začněte pěti čísly: podíl úspěšně dokončených běhů, podíl zásahů člověka, počet opakování, cena na dokončený výstup a chybovost po validaci. U coding agentů přidejte čas do zeleného CI a kolik změn reviewer vrací. U provozních workflow sledujte i nejhorší chybu, ne jen průměr.

To je důvod, proč je loop engineering důležitější než nekonečné ladění promptu. Prompt může zlepšit jeden běh. Smyčka rozhoduje, jestli stejný typ práce zvládnete zítra, za měsíc i při změně modelu — a zda máte dost důkazů, abyste jí mohli věřit.

Aktualizace 2. října 2026: agent běží, ale posouvá se práce?

Jirka Herník v novém dílu popisuje pět dní práce agenta na DigiReality, plánovaný dohled v Grafaně a limity předplatného. Beru to jako zkušenost autora, ne nezávisle ověřený důkaz soběstačné firmy. Prakticky to otevírá jinou otázku než počet hotových úloh: jak poznat, že se smyčka tiše zastavila?

Pro malý pilot bych oddělil tři signály. Živost: běží plánovač a worker? Pokrok: kdy naposledy přibyl ověřený výsledek? Blokace: čeká úloha na člověka, obnovu limitu nebo dostupnost nástroje? Zelený proces může celé hodiny opakovat chybu a nic nedokončit.

U faktur v n8n bych do stavové tabulky ukládal ID dokumentu, poslední ověřený krok, počet pokusů, stav čekání a čas příštího pokusu. Dohled by četl tento stav samostatně. Upozornění „fronta obsahuje práci, ale 30 minut nepřibyl ověřený výsledek“ je užitečnější než další zpráva od agenta, že stále pracuje. Třicet minut je ukázkový práh; pro noční dávku bude jiný než pro živý support.

Pozor i na samotný dohled. Grafana rozlišuje chybějící data a zmizelé série. Prázdný dotaz není automaticky nula chyb. Pro známou očekávanou metriku lze v Prometheu použít absent_over_time; zvlášť ale potřebujete kontrolu zastaralého pokroku. Samotná existence metriky nic nedokazuje.

Po vyčerpání limitu bych uložil checkpoint a naplánoval další pokus s prodlevou. Obnova nesmí znovu odeslat stejný e-mail nebo zapsat stejnou fakturu: před opakováním zkontrolujte výsledek podle stabilního ID operace. Při nejistém výsledku externího zápisu nejprve ověřte cílový systém.

Před vícedenním provozem bych simuloval výpadek workeru, nedostupný model i chybějící metriky. Ověřil bych doručení alertu konkrétnímu člověku a obnovu bez duplicity. To je navržený provozní postup, nikoli tvrzení, že uvedené video tyto testy provedlo.

Zdroje