Poptávka, která mi chodí čím dál častěji: „Chtěli bychom AI agenta.“ Ne „máme problém s objednávkami“, ne „topíme se v e-mailech“. Rovnou AI agenta. Na otázku, co má ten AI agent dělat, přijde odpověď ve stylu „aby to jelo samo“ nebo „co dneska dělá Janička, jenom bez Janičky“. Rozumím tomu. Příspěvky na sociálních sítích se předhánějí v tom, co komu jeho AI agent dneska hlídá, řeší a třídí. Problém je, že takhle chceme auto, aniž bychom věděli, kam a jestli s ním vůbec budeme jezdit.
A zákazník, který to poptává, obvykle netuší, co je pro jeho konkrétní situaci nejvhodnější řešení, a tak si objedná magického AI agenta, který za něj vše udělá, a to ještě mnohem dřív, než sepsal zadání a popsal úlohu. A dodavatel? Ten většinou nemá důvod zákazníkův omyl rozporovat, protože AI agent se fakturuje líp než „obyčejný“ skript.
Vezměme konkrétní zadání, na kterém si to ukážeme. Firmě chodí do sdílené schránky objednávky a Janička je obvykle ručně přepisuje či kopíruje do systému. Přesně ten typ úlohy, který na demech od dodavatelů vypadá jako učebnicová práce pro agenta. Ono se to v demu vždycky povede, protože demo běží na předem umetené cestě: hezký e-mail, existující zákazník, položky, které jsou v katalogu.
Když se v tom zadání ale chvíli hrabete, zjistíte, že nejde o jednu úlohu, ale o tři různé problémy. Většina mailů jsou objednávky od pravidelných odběratelů v ustálené podobě, třeba z formuláře nebo e-shopu. Tam je autonomní rozhodování na škodu, protože jediné, co může přinést, je variabilita tam, kde ji nechcete. A přitom na to stačí pevný postup zapsaný v kódu, který si nic nevymýšlí a v pochybnostech to předá člověku.
Menší část jsou objednávky psané lidsky: pokaždé jinými slovy, jiným pořadím, jiným formátem, ale pořád je to objednávka a pořád s ní chcete udělat totéž. Tam pomůže AI, ale jen jako jeden krok jinak pevného postupu. A zbytek jsou maily, u kterých se teprve cestou ukáže, co je vlastně potřeba udělat: „k té objednávce z minulého týdne poslední položku zrušte a pošlete to, co jsme brali v květnu.“ Tam nastupuje systém, který si další krok volí sám. Jedna poptávka, tři různé architektury.
A pak je tu ještě jedna možnost, která s těmi třemi nesoupeří, protože odpovídá na jinou otázku: AI nemusíte pouštět při každém běhu. Může pomoct jen na začátku – rozebrat formát mailů, napsat parser, vymyslet pravidla – a systém pak jede deterministicky bez ní. K té se vrátím, až pochopíte tři různé architektury.
Skript, workflow a agent
Skript nebo aplikace je deterministický program pro konkrétní operaci: pořadí kroků i podmínky jsou zapsané v kódu. Workflow je předem definovaná posloupnost nebo graf operací, jehož jednotlivé uzly klidně můžou volat AI. Agent je systém, ve kterém model za běhu vybírá další akci podle aktuálního stavu, a k tomu dostává sadu nástrojů.
Představme si to jako továrnu a výrobní linku v ní.
Skript je jako robotická ruka, která třídí kusy na lince. Čidlo na stanici před ní změří rozměr, a když se vejde do tolerance, kus pojede dál; když ne, ruka ho odebere. Pravidla jsou daná předem, ruka žádné rozhodnutí nedělá, jen vykonává to, co jí předal program. Přijde-li na pás něco, s čím se nepočítalo, třeba jiný výrobek, ruka ho odebere nebo si s ním neporadí, protože na něj není nastavena a protože jiná možnost v jejím programu není.
Workflow je celá výrobní linka. Stanice jdou za sebou v pevném pořadí a to pořadí určil technolog. Uprostřed linky je stanice, kde stojí člověk se znalostmi, které nepředáte robotovi – třeba proto, že něco změřit nejde: jestli je lak popraskaný, nebo je výrobek v pořádku a jen otočený na bok. Takový člověk je v našem případě umělá inteligence. Rozhoduje o obsahu jednoho kroku, ne o tom, jaký krok přijde po něm. I kdyby takových stanic bylo deset, pořád je to linka, protože trasu vytyčil technolog, tedy programátor.
A nakonec agent. AI agent je výrobní mistr. Dostane cíl – „tahle zakázka musí být do večera hotová“ – a k němu mantinely: co smí, kam má klíče, kolik smí utratit. Co nedostane, je pevná cesta. Projde halu, podívá se, co chybí, zajde do skladu, ke kterému klíče má, přehodí pořadí operací, zavolá na dílnu, na kterou má telefon. Pokaždé to může udělat a rozhodnout jinak a dopředu nevíte jak. To je jeho hodnota, protože kdybyste ten postup uměli napsat, napíšete ho a mistra nepotřebujete. A je to zároveň jeho nebezpečí: nedá se auditovat stejně jako linka, občas si vybere hloupou cestu a svůj cíl sleduje s klapkami na očích – klidně vezme materiál, který chybí na jiné kritické zakázce, protože ta jeho je pro něj jediná na světě. Takže ho necháte materiál poptat, ale ne podepsat objednávku za čtyři sta milionů.
Nástroje a vlastnosti
Agent totiž není jen „AI s přístupem do firmy“. Většina práce, a taky většina ceny, je v tom, co musí stát kolem něj, aby se dal pustit do provozu. Proto si vyjasníme ještě tři pojmy, bez kterých se o agentech mluvit nedá a se kterými se budete setkávat. A to je nástroj, schopnosti a vlastnosti.
Nástroje (tools) jsou jakékoli funkce, které model může použít: dotaz do databáze, vyhledání v katalogu, založení záznamu, odeslání e-mailu. Model rozhodne, který nástroj chce použít a s jakými parametry; samotné provedení zajišťuje program kolem něj. V naší továrně jsou nástroje klíče od skladu, telefon na sousední dílnu a razítko na výdejku. Mistr nemůže udělat nic, k čemu nedostal nástroj, a to je vůbec nejúčinnější pojistka celého systému: co není v sadě nástrojů, se nestane.
Druhým pojmem jsou schopnosti (skills). Schopnost je zabalený pracovní postup – sada instrukcí, případně i pomocných skriptů, kterou si agent načte, když narazí na určitý typ úlohy. Není to funkce k zavolání ani vlastnost systému, je to znalost „jak se u nás dělá X“. V naší továrně jsou to šanony se směrnicemi na stěně dílny: mistr si vytáhne ten správný, když přijde zakázka daného typu, a postupuje podle něj, místo aby postup pokaždé vymýšlel od nuly.
Kolem nástrojů a schopností pak stojí vlastnosti, které rozhodují, jak se celá věc chová v provozu. Někdy se jim také říká harness nebo scaffolding.
Například taková paměť. To je soubor informací, které si systém nese mezi kroky jednoho běhu a mezi běhy navzájem. Mistr, který v deset dopoledne neví, na čem se dohodl s kolegou v devět, je k ničemu; ale ani mistr, který si pamatuje všechno od loňska, není výhra – plete se, protože si s sebou táhne informace, které už dávno neplatí.
Oprávnění je rozdíl mezi „smí to udělat“ a „smí to navrhnout“. Plánování potom říká, jestli si postup rozvrhne dopředu, nebo jde krok za krokem a improvizuje. Zotavení z chyb rozhoduje, co se stane, když je sklad zavřený: jestli mistr zkusí jinou cestu, nebo se zastaví a zeptá. Observabilita je otázka, jestli po sobě nechá záznam, co udělal a proč, protože bez něj se to nedá ani ladit, ani obhájit před auditem. A paralelní běh znamená, že takových mistrů může po hale chodit pět naráz, což zrychlí práci a zároveň otevře nové způsoby, jak si můžou navzájem přebrat materiál.
A jakmile jich po hale chodí pět, potřebujete orchestraci: někoho, kdo rozdělí práci, počká na výsledky a složí je dohromady. Ve výrobě je to vedoucí provozu, v kódu buď pevný kus programu, který agenty volá a spojuje jejich výstupy, nebo další agent, který si podřízené řídí sám. To první je předvídatelné a levné, to druhé zvládne úlohy, které dopředu neumíte rozřezat, a platíte za to bohužel často tím, že už nikdo v systému nemá celkový přehled.
S více agenty se pojí i slovo, které v téhle souvislosti uslyšíte často: verifikace. Obecně je to jakýkoli kontrolní mechanismus – test, pravidlo, kontrolní výpočet, člověk. Jednou z možností je nechat výstup posoudit dalším modelem a ještě užší variantou je nechat jednoho agenta kontrolovat druhého. Pomáhá to hlavně tam, kde má kontrolor přístup k tvrdým datům: k testům, k databázi, k původnímu dokumentu. Kde takovou oporu nemá, kontroluje výstup modelu jiný model, který se může mýlit stejně a ze stejných důvodů. Dva mistři ze stejné školy si navzájem odkývou stejný nesmysl, protože se to tak naučili. Přidaná vrstva uvažování navíc nemusí chyby tlumit, může je i zesilovat. A dva agenti, kteří si přehazují práci mezi sebou, jsou mimochodem nejrychlejší známý způsob, jak spálit rozpočet na tokeny: v jednom popsaném případě se dva zacyklení agenti přehazovali jedenáct dní a účet se zastavil na 47 tisících dolarů [7].
Zajímavé na tom seznamu je, že se pravidelně vydává za definici agenta. Není to tak. Paměť, oprávnění, plánování, zotavení z chyb, observabilita i paralelní běh jsou architektonicky zásadní věci, ale samy o sobě architekturu neurčují a najdete je i jinde. Robotická ruka má taky oprávnění a taky loguje. Linka má plánování, jen ho udělal technolog, ne ona sama.
A dokonce ani přítomnost jazykového modelu vám o architektuře neřekne nic, protože AI se dneska vyskytuje na více místech procesu. Půlka trhu říká agent chatbotu s jedním vyhledáváním a i klasické automatizační platformy si mezitím přejmenovaly nebo vylepšily produkty na agenty. Všude dnes najdete AI agenta. Terminologický zmatek přitom stojí zákazníky peníze. Podle nálepky si lidé vybírají architekturu a pak se diví, proč jim věc padá, nedělá, co má, anebo proč stojí tolik.
Praktický důsledek toho zmatku je jednoduchý: než si vyberete nálepku, vyberte si nejjednodušší věc, která úlohu vyřeší. Anthropic to ve svém textu Building effective agents [1] formuluje jako doporučení přidávat složitost, až když je potřeba, s tím, že u spousty aplikací stačí dobře optimalizované jedno volání modelu s vyhledáváním a příklady v kontextu. Workflow podle nich dává předvídatelnost u dobře definovaných úloh, agent je lepší volba tam, kde je ve velkém potřeba flexibilita a rozhodování řízené modelem.
Což zní rozumně, dokud nemáte před sebou konkrétní zadání. Tak si to zkusme na tom našem.
Skript vs. workflow s AI vs. AI agent
Vracíme se k Janičce a schránce plné objednávek. Jednu úlohu teď vyřešíme třemi způsoby, vrstvu po vrstvě.
Než ale sáhnete po čemkoli z toho, zamyslete se. Nedá se mail nahradit formulářem, přílohou v CSV nebo přímým napojením na partnerův systém? A pokud ne, nezvládne to hotová integrační platforma (n8n, Make, Zapier) bez jediného řádku? Pokud ne a máte většinu zákazníků rozumných, navrhněte jim aspoň, aby posílali objednávky ne přímo Janičce nebo Péťovi, ale na jasně stanovený mail. Třeba [email protected].
Když objednávky chodí ze systému partnera vždy ve stejné šabloně, je na ně ideální skript.
Skript
Každých pět minut se podívá do schránky [email protected] přes IMAP protokol, vezme si nepřečtené maily a zkusí v každém najít to, co tam partnerův systém vždycky posílá: číslo objednávky a řádky s položkami. Když to najde, založí objednávku v systému. Přes API, nebo třeba přidá řádek do CSV souboru či Google Tabulky. Když ne (přišel dotaz, storno, nebo partner změnil šablonu) mail se označí štítkem nebo přesune do složky, kterou ráno projde obchodník. Po úspěšném zpracování se mail odškrtne, aby se jeden mail nehodnotil stále dokola.
Jestliže těch mailů ve složce obchodníka bude většina, chceme to začít řešit chytřeji. A tak zapojíme AI. Do workflow.
Workflow s AI
Stejná trasa, ale místo hledání pevné šablony dá tělo mailu přečíst modelu. Nenechá ho mail komentovat, jak jste zvyklí z ChatGPT, ani navrhovat odpověď. Předepíšete mu strukturu, co vás zajímá: číslo objednávky, IČO, položky, a povinně i kolonku „tohle není objednávka“ a „tímhle si nejsem jistý“. Bez těch dvou kolonek by model u dotazu na termín dodání objednávku klidně vymyslel, protože jinou odpověď by mu formát nedovolil. Co model vyplní, bere workflow jako podklad k prověření, ne jako hotovou věc: další skript se podívá do vaší databáze a kódy položek porovná s katalogem, IČO ověří kontrolním výpočtem, přes ARES nebo proti seznamu vašich klientů, a podezřelá množství, jejichž hranice mu nastavíte předem, zarazí. Teprve co projde vším, jde do systému samo; zbytek jde obchodníkovi i s důvodem, proč se to zastavilo.
Všimněte si, že model tady nic neřídí. Vrátí strukturovaný výsledek a všechny kroky před ním i po něm jsou určené předem. Proto je to pořád workflow, i když uvnitř sedí AI.
A všimněte si taky, že pořád zbývá pár mailů, které jsou nejasné. Třeba ten mail „zrušte poslední položku a pošlete to, co jsme brali v květnu.“ To je ideální adept pro dražší chod: AI agenta.
AI agent
Agent dostane cíl: „vyřiď tenhle mail.“ A k tomu tři nástroje: umí ve vaší databázi vyhledat objednávky zákazníka, otevřít jejich detail a připravit návrh změny pro zápis do systému. Nic víc v ruce nemá – nemůže fakturovat, odesílat ani mazat, takže nejhorší, co může provést, je napsat špatný návrh.
V jakém pořadí a kolikrát nástroje použije, si rozhodne sám. U mailu „zrušte poslední položku a pošlete to, co jsme brali v květnu“ si nejspíš nejdřív vytáhne květnové objednávky, z detailu zjistí, co se tehdy bralo, dohledá poslední aktuální položku a složí návrh. U jiného mailu, „přidejte mi ještě dva velké plechy v antracitu“, si vyhledá v katalogu položky s názvem nebo kategorií plech, zjistí, že v antracitové barvě je tam jediná varianta, RAL 7016, a tu navrhne.
Přesně tahle volnost je důvod, proč agenta nasazujeme až na zbytky a taky důvod, proč kolem něj postavíme ochrannou smyčku, která dělá tři věci. Za prvé, vrací agentovi výsledek každého volání nástroje, i když volání selže: chybu dostane popsanou jako informaci („objednávka s tímhle číslem neexistuje“), ne jako pád programu, takže může zkusit jiný postup. Za druhé, počítá kroky a útratu – každý běh má předem daný strop na počet volání, spotřebované tokeny a cenu, a při překročení se ukončí, i kdyby agent tvrdil, že už je skoro hotový. A za třetí, loguje každé volání nástroje včetně argumentů a výsledku, takže se dá u každého návrhu zpětně doložit, z jakých dat vznikl.
Výsledkem není změněná objednávka, ale návrh změny na stole operátora. Tlačítko „OK“ je na obchodníkovi – a jeho dvojí stisknutí nesmí založit dvě změny.
AI jako autor
Na začátku jsem slíbil ještě jednu možnost. Není to čtvrtá položka do předchozí trojice, protože řeší něco jiného. Skript, workflow a AI agent řeší, co rozhoduje, když systém běží. Tahle možnost řeší, jestli AI za běhu vůbec potřebujete anebo jestli stačí, když jednou pomůže systém vytvořit.
Funguje to tak, že první mail od nového zákazníka necháme projít modelem se dvěma úkoly najednou: vyřiď tuhle objednávku a když ti potvrdím, že jsi ji vyřešil správně, napiš program, který bude vyřizovat všechny další ve stejné šabloně. Program se hned vyzkouší a poku dá na tom samém mailu musí dát stejný výsledek jako model, jste na dobré cestě. Alespoň pro tento typ objednávek.
Jeden mail ale není důkaz. Parser si důvěru musí získat: dalších několik mailů stejné šablony jde souběžně přes něj i přes model, a teprve když se výsledky opakovaně shodují, převezme parser směnu. Od té chvíle jdou maily toho partnera přes kód: bez tokenů, bez čekání a pokaždé stejně. Kontroly proti katalogu a IČO zůstávají v obou režimech, protože na tom, kdo mail rozebral, nezáleží. Záleží na tom, co jde do systému. A když partner šablonu změní, parser začne padat nebo se rozcházet s kontrolami, práce se vrátí modelu a ten napíše parser nový.
Platíte tedy jednorázově za vytvoření nástroje, ne opakovaně za každou odpověď. Pro úlohy, které se opakují a mění se jen podoba vstupu, je to nejlepší poměr, jaký z AI dostanete.
Proč není agent vždy nejlepší volba
Jak už z předchozího textu tušíte, skript je skvělý na zpracování jednoznačných vstupů: je rychlý, levný a deterministický. Agent se oproti tomu umí přizpůsobit situaci, ale je pomalejší, dražší na provoz a ne vždy předvídatelný.
Jak moc dražší? Anthropic v textu o svém multiagentním research systému [2] uvádí, že agentní běhy spotřebují průměrně zhruba čtyřnásobek tokenů oproti běžné konverzaci a multiagentní architektury přibližně patnáctinásobek. Jsou to čísla z jejich systému, ne univerzální konstanta, mechanismus za nimi je ale obecný: smyčka pokaždé znovu čte celou historii kroků, takže každé kolo nese kontext všech předchozích. Představte si, že si píšete s dítkem na táboře a do každé obálky se vždy přibalí všechny předchozí dopisy. Potomek pošle dopis, vy odpovíte a přiložíte jeho dopis, on odpoví a přiloží oba předchozí. Poslední zásilka už není obálka, ale balíček. A k posílání patří i latence: šest dopisů tam a šest zpět znamená dvanáct cest ke schránce, v případě modelu klidně desítky sekund čekání.
Tím ale naše paralela s dopisy nekončí. Co se s nimi stane, když je budete pořád dokola vytahovat, číst a skládat zpátky do obálky? Papír se poláme na přehybech, doma na ně někdo postaví hrnek s kafem, dítku spadne celý balíček do louže. Čitelnost klesá s každou další manipulací. U agenta k ničemu takovému nedochází, protože informace v kontextu se nepoškozuje jako papír a model si ji přečte i po sté. Kazí se něco jiného: chybný mezivýsledek se stane součástí pracovního stavu a všechna další rozhodnutí s ním počítají jako s faktem. Připomíná to tichou poštu. První řekne „babička peče cukroví“ a pátý v řadě slyší „Hanička vleče do křoví“. Nikdo z hráčů nelže a žádný se nesnaží hru zkazit, každý jen předá dál, co si myslí, že slyšel. Agent hraje tichou poštu sám se sebou: krok tři si vyloží data trochu jinak, krok šest na tom výkladu staví, krok osm nějakou informaci obrátí a krok deset pracuje s negací jako s potvrzením, takže rozhoduje o něčem, co už s původním mailem souvisí jen vzdáleně.
Kolik to stojí na spolehlivosti, ukazuje jednoduchý model. Vezměte řetězec, kde všech deset kroků musí uspět a žádný nezávisí na ostatních. Při 95% úspěšnosti jednoho kroku vyjde celek na 59 %. Při 90 % na 35 %. Při 85 %, což je u složitější úlohy slušný výsledek, na 20 %. A obráceně: chcete-li desetikrokový proces, který se povede v pětadevadesáti procentech případů, potřebujete zhruba 99,5 % na krok – a takovou úroveň u deterministických kroků dosáhnete snáz kódem než opakovaným úsudkem modelu. Skutečné běhy takhle čisté nejsou: kroky nejsou stejně těžké, některé se opakují nebo přeskočí a z chyby nástroje se agent umí zotavit. Berte ta čísla jako ilustraci toho, jak rychle se drobná nespolehlivost kumuluje s délkou řetězce. Že přesně tenhle efekt existuje i v praxi, potvrzují měření dlouhých běhů [3]: spolehlivost s rostoucí délkou úlohy klesá a u některých domén strmě.
A ukazují to i další dvě měření. Benchmark τ-bench [4] zavedl metriku pass^k, tedy kolikrát agent uspěje ve všech k opakováních téže úlohy: nejlepší agenti zvládli méně než polovinu úloh na první pokus a v retailové doméně uspěli ve všech osmi opakováních v méně než čtvrtině případů. Úspěch na demu tedy neříká skoro nic o úspěchu v provozu. A ReliabilityBench [5] doplňuje, že stačí zadání jinak formulovat nebo přidat běžné provozní potíže typu rate limitů a úspěšnost citelně klesá. Obojí jsou zatím omezené benchmarky, ale míří podobným směrem.
Obrana existuje a už jsme ji potkali: verifikace. Jakmile má krok jasně definovanou kontrolu, opakování nebo se dá přeskočit, prosté násobení přestává platit a nároky na přesnost jednoho kroku klesají. Proto workflow ověřuje IČO, katalog i množství a proto agent končí návrhem, ne provedenou změnou.
Nejhorší na tom všem je forma selhání. Agent nespadne. Krok tři vrátí lehce zastaralá data, krok šest je špatně naformátuje, krok devět se rozhodne na základě špatných vstupů a výsledek vypadá naprosto věrohodně. Chyba, která hlásí výjimku, je dárek. Chyba, která vrátí hezky formátovanou nesmyslnou odpověď, je průšvih.
Gartner v tiskové zprávě z června 2025 [6] odhadl, že přes čtyřicet procent agentních projektů bude do konce roku 2027 zrušeno kvůli rostoucím nákladům, nejasné hodnotě a nedostatečným kontrolním mechanismům. Je to predikce analytické firmy, ne měření, a stojí mimo jiné na anketě mezi účastníky jejich webináře. Neberu to jako předpověď konce agentů. Beru to jako předpověď konce agentů nasazených na úlohy, kde měl být napsaný kód.
Proč (a kdy) je agent nejlepší volba
To jsem vám teď titulkem zavařil hlavu, že? Ale agent opravdu může být ta nejlepší volba. Používám na to pět kritérií. Není to definice z učebnice, je to moje rozhodovací heuristika a chci, aby platila pokud možno všechna najednou.
1. Další krok závisí na výsledku předchozího zjištění
U mailu „pošlete to, co jsme brali v květnu“ nevíte, kolik květnových objednávek existuje, dokud se nepodíváte, a podle toho, co najdete, se teprve rozhodne, jestli je potřeba další dotaz do databáze, nebo dotaz na člověka. Rozhodnutí uprostřed úlohy tedy závisejí na datech, která před spuštěním nemáte. Pokud se naopak dá celý postup určit předem a data ho jen naplňují, agenta nepotřebujete.
2. Možných cest je tolik, že je nepraktické je předem zakódovat
Málo variant se dá vyjmenovat a zapsat jako větve v kódu, a tam je to vždycky lepší řešení. Agent se vyplácí, až když by seznam variant byl delší a křehčí než samotný popis cíle. Používám k tomu heuristiku s vývojovým diagramem: když ho nakreslíte na jednu A4 a nezůstane v něm uzel, kde je potřeba úsudek nad otevřeným vstupem, agenta nejspíš nepotřebujete a stačí ten diagram napsat v kódu. Je to vodítko, ne definice. I krátký diagram může obsahovat uzel, který se bez úsudku neobejde, a naopak leckterý agent má na papíře banální schéma model → nástroj → model, přičemž složitost je schovaná v tom, kolikrát a v jakém pořadí tou smyčkou projde.
3. Existuje zpětná vazba na kvalitu výsledku
Nejsilnější podobou je strojová verifikace, a ta zároveň vysvětluje, proč agenti nejlíp fungují v programování: test buď projde, nebo ne, kompilátor buď přeloží, nebo ne, a agent se podle toho umí opravit sám ještě během běhu.
Binární ověření ale není jediná použitelná forma. U rešerše, triáže nebo přípravy podkladů se kvalita strojově změřit nedá, a přesto tam agenti dávají smysl, protože zpětnou vazbu nese dohledatelnost: každé tvrzení má zdroj, který jde otevřít, výstup čte člověk a chyba se pozná dřív, než něco způsobí. Podmínka tedy zní, že musí existovat dostatečně kvalitní kontrola, ať už automatická během běhu, nebo lidská na konci.
Kde to selhává, je práce bez jakékoli kontroly. Agent, který „optimalizuje obsah“ a nikdo jeho výstup nečte ani neměří, nemá jak poznat, že je hotovo, a produkuje jen sebejistotu.
4. Cena chyby je únosná a dá se ohraničit
Ne „model se nesplete“, ale „když se splete, kolik to stojí a kdo si toho všimne“. Prakticky to znamená, že chybu je možné zachytit dřív, než něco způsobí – proto agent v našem příkladu končí návrhem, ne provedenou změnou – a že i ta zachycená stojí jen čas jednoho člověka, ne pokažený vztah se zákazníkem nebo špatně vystavenou fakturu.
5. Úloha unese cenu agenta
Násobně vyšší náklady, u publikovaných agentních systémů řádu čtyř- až patnáctinásobku [2], a desítky sekund latence musí mít z čeho zaplatit. U interní rešerše dvakrát denně jasně ano. U operace, která běží třicet tisíckrát měsíčně? Tady už je třeba vzít do ruky ceník tokenů a kalkulačku.
Jak postupuji v praxi
Postup, který používám, je nudný a funguje. Začnu jedním promptem a ručním během na dvaceti reálných případech. Ne na vymyšlených, na reálných, včetně těch divných a hraničních, pokud je najdu. Z toho vznikne první představa o tom, co model zvládá a kde padá. Pak z těch dvaceti případů udělám evaluační sadu. Bez ní se nedá poznat, jestli je změna promptu zlepšení, nebo zhoršení, a stavět agenta bez evaluace je jako refaktorovat bez testů.
Teprve pak píšu kód. Nejdřív pevné workflow, protože většina případů má jednu cestu. Agenta nasazuji na zbytek, na ten dlouhý ocas výjimek, kde se cesta liší případ od případu a i tam v režimu, kdy jen navrhuje a neprovádí, s člověkem na konci.
Když někdo přijde s tím, že chce agenta, ptám se na dvě věci. Jak poznáte, že úloha dopadla dobře? A co se stane, když dopadne špatně a nikdo si toho nevšimne do rána? Pokud na první otázku neexistuje odpověď – ani test, ani kontrola člověkem – a na druhou je odpověď nepříjemná, agenta nestavíme. Nejdřív postavíme deterministický proces, který nic nerozhoduje bez kontroly, ale všechno zaznamenává.
Možná namítnete: když výsledek nepozná nikdo, k čemu i to? K tomu, že až se to pokazí, pokazí se to předvídatelně. Pevné kroky znamenají, že chyba vznikne na známém místě, najde se v logu konkrétního kroku a opraví se jednou pro všechny další běhy. Agent s nepředvídatelným a neposouditelným výstupem a pokaždé jinou cestou vám to nedá. A z logů chyb časem vznikne zpětná vazba, která bude sloužit jako stavební kameny dražšího a složitějšího řešení. Pak má smysl bavit se o agentovi.
AI agent je nejdražší způsob, jak automatizovat proces. Někdy jediný možný. Většinou ale ne.
Literatura
[1] ANTHROPIC. Building Effective Agents [online]. Anthropic, 2024 [cit. 2026-08-25]. Dostupné z: https://www.anthropic.com/engineering/building-effective-agents
[2] ANTHROPIC. How We Built Our Multi-Agent Research System [online]. Anthropic, červen 2025 [cit. 2026-08-25]. Dostupné z: https://www.anthropic.com/engineering/multi-agent-research-system
[3] KHANAL, Aaditya, TAO, Yangyang a ZHOU, Junxiu. Beyond pass@1: A Reliability Science Framework for Long-Horizon LLM Agents [online]. arXiv, 31. března 2026 [cit. 2026-08-25]. arXiv:2603.29231. Dostupné z: https://arxiv.org/abs/2603.29231
[4] YAO, Shunyu, SHINN, Noah, RAZAVI, Pedram a NARASIMHAN, Karthik. τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains [online]. arXiv, 17. června 2024 [cit. 2026-08-25]. arXiv:2406.12045. Dostupné z: https://doi.org/10.48550/arXiv.2406.12045
[5] GUPTA, Aayush. ReliabilityBench: Evaluating LLM Agent Reliability Under Production-Like Stress Conditions [online]. arXiv, 3. ledna 2026 [cit. 2026-08-25]. arXiv:2601.06112. Dostupné z: https://arxiv.org/abs/2601.06112
[6] GARTNER, Inc. Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 [online]. Gartner, 25. června 2025 [cit. 2026-08-25]. Dostupné z: https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
[7] KUSIREDDY, Teja. We Spent $47,000 Running AI Agents in Production. Here’s What Nobody Tells You About A2A and MCP [online]. Towards AI, 16. října 2025 [cit. 2026-08-25]. Dostupné z: https://pub.towardsai.net/we-spent-47-000-running-ai-agents-in-production-heres-what-nobody-tells-you-about-a2a-and-mcp-5f845848de33
