Přestaňte agenty krotit prompty, kroťte je infrastrukturou

Většina týmů, které dnes zkouší nasadit agenty běžící bez dozoru, dělá to samé, a je to špatně. Napíšou obří system prompt, kde stojí, že agent nikdy nesmí sáhnout na produkční config, nikdy nesmí pouštět destruktivní příkazy, vždycky se musí zeptat, než smaže soubory, musí zůstat v těchhle třech adresářích, a pak toho agenta napojí na uzamčenou sadu nástrojů, allowlist shell příkazů, approval gate na cokoliv, co zavání nebezpečím, a prohlásí to za bezpečné. Bezpečné to není. Je to křehké, pomalé a rozpadne se to ve chvíli, kdy model usoudí, že nejrychlejší cesta k zeleným testům vede přes příkaz, který jste nepředvídali. Snažíte se zakódovat bezpečnostní hranici do přirozeného jazyka a pak ji vynucovat pravděpodobnostním prediktorem tokenů, který při dostatečném počtu běhů udělá přesně to, co jste mu zakázali. Tenhle vzorec jsme viděli selhat na klientských projektech, kde se celý workflow zadrhnul, protože každá třetí akce potřebovala člověka, aby klikl na approve, což ruší celý smysl toho, pustit agenta bez dozoru. Chování, které ve skutečnosti chcete, není poslušný model. Je to blast radius tak malý, že na nějakém prohřešku nezáleží. Stripe na to přišel a postavil kolem toho svůj systém Minions, přičemž ta lekce platí daleko za hranicemi Stripu.

Architektura Minions pouští každého agenta uvnitř jednorázového devboxu, v podstatě jedné EC2 instance, kterou nastartuje, předá jí úkol, dá plný přístup k shellu a pak ji zahodí. Plný přístup k shellu. Žádný allowlist, žádné odchytávání příkazů, žádný chytrý prompt, který určuje, které varianty rm jsou zakázané. Agent si uvnitř toho boxu může dělat, co chce, protože ten box je bezcenný. Má v sobě checkout repa, tooling na build a testy a nic jiného podstatného. Když je hotový, jediný artefakt, který box opustí, je git diff, který projde běžnou PR pipeline, a samotný box se vypaří. To jediné rozhodnutí, izolace jako systém oprávnění, je důvod, proč můžou pouštět přes 1 300 PR týdně napsaných výhradně agenty proti codebase pro platby, kterou tečou biliony, aniž by security tým dostal nervový záchvat. Otázka oprávnění přestává znít co agent smí a mění se na co může uniknout ze sandboxu. To jsou úplně jiné otázky a ta druhá má čistou, deterministickou odpověď ve tvaru infrastruktury. Neauditujete chování, auditujete egress. Git diff putující do code review pipeline, která už má lidské reviewery, CI a merge protections, je hranice, které už teď věříte, protože jí věříte u svých lidských inženýrů. Agent se prostě stane dalším autorem, jehož výstup teče přes úplně stejný gate.

Zajímavé na Minions není to, že LLM píše kód. Je to tvar smyčky kolem LLM. Máte deterministický krok, pak fuzzy LLM krok, pak zase deterministický krok, střídají se. Deterministické kroky jsou věci jako spusť linter, spusť type checker, spusť testy, aplikuj codemod, ověř, že diff sahá jen na povolené cesty. LLM kroky jsou části, kde skutečně potřebujete úsudek, třeba tyhle testy padají, jaká změna je opraví. Pointa je, že skutečné omezení dělají ty deterministické brány. Když type checker selže, smyčka se neposune, a žádná míra sebejistoty modelu o jeho špatné odpovědi se přes compiler nedostane. LLM používáte na fuzzy prostředek a odmítáte mu věřit cokoliv, co dokáže ověřit stroj. To je přesně opak toho, jak se staví většina agentových frameworků, kde má velení model a volá nástroje, jak uzná za vhodné, přičemž nástroje jsou jen schopnosti, po kterých může sáhnout. Tady velí pipeline, model je subrutina a pipeline rozhoduje, kdy je práce přijatelná. Ve steezru stavíme vlastní pipeline na zpracování dokumentů a automatizaci stejně, deterministická validace obklopuje každé volání modelu, protože model, který produkuje strukturovaný výstup, jenž nevalidujete, je bug čekající na produkční provoz. LLM je silné přesně tam, kde je determinismus nemožný, a k ničemu tam, kde je determinismus levný, takže svůj rozpočet na determinismus utrácíte agresivně a k modelu se vracíte, jen když nemáte jinou možnost.

V návrhu Minions je detail, který potichu znamená víc než samotný sandboxing, a je to tvrdý limit na počet kol CI. Agent dostane zhruba dvě kola CI feedbacku, aby dostal svůj PR do zelené, a pokud to v tomhle okně nezvládne, úkol se zahodí, místo aby se opakoval donekonečna. Tohle je jednoznačně nejvíc podceňované rozhodnutí z celé věci. Kdokoliv, kdo někdy pouštěl agentovou smyčku, zná ten failure mode, kdy se model zasekne, zhorší kód snahou opravit symptom, pak ho zhorší znovu snahou spravit to, co právě rozbil, a spaluje tokeny a CI minuty ve smrtící spirále, ze které by člověk vycouval po deseti minutách. Tvrdý limit kol změní neomezené náklady na omezené. Zároveň mění ekonomiku celého systému, protože dokážete uvažovat o maximálních nákladech na úkol, a tím pádem o maximálních nákladech napříč 1 300 úkoly týdně, což je rozdíl mezi položkou, kterou finance odsouhlasí, a otevřeným API účtem, který všechny děsí. Když se úkol nedá vyřešit ve dvou kolech, je to signál, ne selhání. Buď byl úkol špatně zadaný, nebo potřebuje člověka, a obě věci jsou v pořádku. Chyba, kterou týmy dělají, je, že berou agentové retry jako zadarmo, protože ťuká model. Compute není zadarmo, kapacita CI není zadarmo, a špatný PR, který musí rozplétat člověk, stojí víc, než za kolik úkol stál. Ohraničte smyčku. Selhávejte rychle. Těžké případy routujte k lidem.

Poslední kus je nudný, a právě proto funguje. Stripe sdílí stejné soubory s pravidly napříč Minions, Cursorem a Claude Code, takže konvence, které agent dodržuje, když běží bez dozoru, jsou ty samé, které vynucuje editor vývojáře, když píše kód ručně s asistentem. Neexistuje žádný samostatný config pro běh bez dozoru, který by se rozešel s tím interaktivním. Znalost o tom, jak chce být tahle codebase psaná, žije na jednom místě a každý konzument, ať už řízený člověkem nebo plně automatický, z něj čte. Tohle má význam, protože alternativa je to, co všichni reálně mají: kmenové znalosti roztroušené po wiki, kterou nikdo nečte, CONTRIBUTING.md staré dva roky a tři různé sady AI instrukcí, z nichž každá kóduje trochu jinou představu o tom, jak by věci měly fungovat. Když jsou pravidla sjednocená, jejich vylepšení vylepší všechny povrchy naráz. Opravíte konvenci, protože ji Cursor pořád špatně dělal pro člověka, a najednou ji zadarmo správně dělají i Minions běžící bez dozoru. Je to prostě dobrá hygiena konfigurace aplikovaná na nový druh konzumenta. Pokud zvažujete přechod od agentů s dozorem k agentům bez dozoru, začněte tady, protože vaše soubory s pravidly jsou rozhraní mezi vašimi záměry a chováním modelu, a když jsou bordel pro lidi, budou bordel i pro agenty jedoucí na 1 300 PR týdně.

Pokud jste tech lead, který váhá s agenty bez dozoru, praktický závěr zní: přestaňte investovat do guardrailů na úrovni promptu a začněte investovat do hranice. Rozjeďte agenty v jednorázových prostředích, kde jediné, co přežije, je reviewovatelný diff, a najednou je otázka, jestli je model důvěryhodný, skoro irelevantní, protože diff procházející stejným CI a review gate jako u vašich lidských inženýrů je rizikový profil, kterému už rozumíte. Nepotřebujete škálu Stripu, abyste tu architekturu okopírovali. GitHub Actions runner nebo container na jedno použití s checkoutem repa a bez produkčních credentials vám dá devadesát procent hodnoty a zbytek práce je napojit vaše existující deterministické kontroly, linter, testy, type checker, validátor migrací, do smyčky, která obklopuje volání modelu a vynucuje tvrdý limit retry. Přesně tohle jsme stavěli klientům přecházejícím od člověka klikajícího na approve u každé akce agenta k systému, který zakládá PR, zatímco všichni spí, a to, co to rozjelo, nebyl nikdy lepší prompt. Bylo to smíření s tím, že model občas udělá něco pitomého, a návrh infrastruktury tak, aby když se to stane, nemohlo uniknout nic špatného. Kroťte prostředí, ne tokeny. To je celá lekce a je to důvod, proč si platební firma může pustit agenty na svou codebase a klidně spát.