AI agenti v produkci mají dnes jeden společný problém, a není to výkon modelu. V úterý 30. září 2026 nepřišla žádná nová vlna modelů, ale zato tři texty a jedna diskuse, které přesně vystihují, co řeší týmy, které agenty už provozují: jak agentovi dát proces, hranice a kontrolu.
Přišel ti další model? To už dneska nikoho v praxi nerozhodí. Rozhoduje, jestli tvůj agent zvládne noční běh, který spadne v polovině, jestli víš, kolik tě stál, kdo ho spustil a co už stihl provést, než se pokazilo. Tady je přehled toho, co se o tom v jeden jediný den — 30. září 2026 — objevilo, a co z toho má smysl udělat zítra.
Od výběru modelu k provozu: co se posunulo
Fáze „který model je nejlepší“ je pro spoustu týmů u konce. Modelů je víc dobrých a vyměnitelných; to, co drží projekt pohromadě, je orchestrace a způsob, jak agenty propojuješ s procesy. Pokud agent dělá jen to, co po něm jednou napíšeš do chatu, tak ho nemáš v produkci — máš konverzaci.
Praxe se posouvá k tomu, co už roky známe z klasického provozu software: logy, limity, schvalování, verzování a dokument, který říká, kam práce směřuje. Jen se to teď musejí naučit i lidé, kteří si mysleli, že stačí dobrý prompt. Podobně to popisuje i koncept AI harnessu — agenta vyladíš procesem kolem něj, ne výměnou modelu.
Čtyři zdroje z 30. září to kupodivu říkají každý z jiného konce — a dohromady dávají celkem konzistentní obrázek.
Kontrola běhu: co musíš vědět o AI agentovi v produkci
Luca Rossi na Refactoringu 30. září 2026 vydal text How to Run Good Agents in Production — třetí díl série o orchestraci a governance agentů. Postavil ho na rozhovorech s týmy, které agenty skutečně provozují na serverech, ne jen zkouší v chatu. Jádro je seznam toho, co bys o každém běhu agenta měl umět zjistit, ideálně z jednoho systému:
- Mezivýstupy každého kroku. Ne jen konečný výsledek. Každý smysluplný krok by měl po sobě zanechat něco zkoumatelného: stažený záznam, klasifikaci, koncept, který se měl odeslat.
- Tokeny a cena podle kroků. Celkové náklady na běh jsou základ, ale rozdělené podle kroku, modelu a nástroje ti až řeknou, kde peníze reálně tečou.
- Logy tool callů. Které servery a nástroje agent volal, s jakými vstupy a výstupy. U MCP nástrojů dvojnásob.
- Kdo běh spustil. Člověk, scheduler, webhook nebo jiná agentní relace. Až budeš dělat audit, bude tě to zajímat.
- Stav při selhání. Který krok spadl, co už se stihlo zapsat (commitnout) a co je bezpečné zkusit znovu.
Rossi přitom poznamenává zajímavou paralelu: stejně jako kolem roku 2022 si polovina týmů míchala metriky in-house, dnes si spousta týmů loguje základ sama — typicky tokeny a konečnou odpověď. To funguje, dokud jsou běhy krátké. Jakmile se dlouhý opakovaný job pokazí v polovině, bez rozpadu na kroky nezjistíš nic.
Dvě věci k tomu patří ještě: brána na nevratné akce (mazání, odeslání zákazníkovi, platba — to schvaluje člověk) a navázání bez přehrání. Když agent padne po hodině práce, musíš umět pokračovat od rozbitého kroku, ne začínat znovu od nuly a platit druhou hodinu. Jak monitoring postavit technicky, jsme rozebírali v návodu jak monitorovat AI agenty v produkci.
Deterministická logika patří do kódu, ne do promptu
Druhý text z téhož dne — The AI Agent Bottleneck od Tamize Uddina (30. září 2026) — pojmenovává anti-pattern, který v agentních workflow vidí čím dál častěji: „if-statements s účtem za GPU“. Doslova: platíš za inferenci to, aby transformer dělal práci state machine.
Typický příklad: prompt, ve kterém stojí „když zákazník žádá o vrácení peněz, zkontroluj databázi; když se ptá na počasí, zavolej weather tool“. Nebo planner LLM, který se rozhoduje, který obyčejný API endpoint zavolat — na místě, kde není co řešit, protože cesta je jednoznačná. Za tu volbu neplatí jen tokeny, ale i latenci, komplexitu a pravděpodobnost halucinace.
Recept je prostý, jen se hubeně dodržuje:
- Routování a validaci dej do kódu. Pokud je rozhodnutí deterministické (podle typu požadavku, podle stavu objednávky), patří do obyčejného programu.
- Model nech na skutečné nejednoznačnosti. Interpretace textu zákazníka, navrhování odpovědi, hodnocení, jestli výsledek dává smysl — to jsou místa, kde LLM něco vrací.
- Audituj graf agenta jako kód. Každé volání modelu, které dělá jen rozhodování typu if-else, je kandidát na refaktor.
Představ si e-commerce support agenta. „Rozumí dotazu zákazníka a navrhne odpověď“ — na to model patří. Ale „pokud má objednávka status delayed, vlož do odpovědi nové ETA“ je čirá logika nad databází; udělá ji tři řádky kódu zdarma, okamžitě a bez rizika, že si model stav vymyslí. Rozhodnutí schované v promptu se pak při ladění špatně hledá: graf agenta se chová pokaždé jinak, kód nikdy.
Pozor není to volání „méně AI“. Je to volání „AI tam, kde se vyplatí“. Deterministické kostry s modelem na konci jsou levnější, rychlejší a lépe laditelné.
AI workflow kolem kódu: testy dřív a strop na počet kol
Třetí text: Hieu Le z týmu Relipa na DEV.to (30. září 2026) popisuje, co se stane, když AI agent projde skutečným vývojovým workflow. Pipeline je šestifázová: Requirement → Spec → Plan → Test → Code → Review. Neobvyklé je pořadí — testy se definují před implementací, ne po ní.
Důvod: když testy napíšeš (nebo necháš napsat) dřív, slouží jako nezávislá reference pro vyhodnocení kódu. Nehodnotíš, jestli se ti kód líbí, ale jestli splňuje kritéria, která byla stanovená předtím, než agent napsal první řádek. Review pak má s čím porovnávat a agentovi se dá říct konkrétně, co selhalo, místo obecného „přepiž to lépe“.
Druhý detail, který stojí za pozornost: strop na počet kol. Jejich workflow má limit 5 kol, s maximálně 2 nedokončenými subtasky na kolo. Když úkol po limitu stále potřebuje opravy, systém to bere jako signál pro zásah člověka — ne jako důvod k automatickému spuštění dalšího kola. To je přesně opak spinningu, kdy agent krouží a pálí tokeny do nekonečna.
A třetí: auto-commit po každém tahu agenta. Relace agenta se tím stane řetězem restore pointů — když se změna z několika tahů zpátky ukáže jako chybná, vrátíš se na konkrétní bod, ne na začátek. Stejnou filozofii error handlingu a retry doporučujeme i v automatizačních nástrojích: scénář, který nespadne, musí mít retry, dead letter queue a monitoring.
Psaný směr práce místo delšího promptu
Poslední signál je nejslabší, ale zajímavý. Na Hacker News se 30. září 2026 večer objevilo Show HN: Kyno — projekt, který nazývají „coherence control plane“. Myšlenka: směr práce (mise a principy) je verzovaný dokument, který si agent načte v každém kroku workflow, aby se jeho rozhodování drželo směru, i když nad ním nikdo nestojí.
Zajímavé je, že Kyno není další LLM — je to systém, který drží na jednom místě verzovanou „ústavu“ agenta (mise a principy) a doplňuje guardraily. Guardrail říká „tohle nesmíš“; směr práce říká „tímhle směrem rozhoduj, když nic nezakazují“.
Ber to jako signál, ne standard: diskuse měla večer čtyři body a nula komentářů. Ale směřuje to stejně jako zbylé tři texty — od delších promptů k explicitním, verzovaným artefaktům, které agent čte za běhu.
Co z toho udělat zítra
Nemusíš zavádět nic nového najednou. Stačí jedno úzké procesní rozhodnutí denně:
- Vyber jeden proces, který agentem zautomatizuješ celý — ne pět experimentů. Úzký proces se dá změřit, ohraničit a u něj poznat, že se rozbil.
- Přesuň pravidla do kódu. Projdi svůj agentní workflow a každé if-else rozhodnutí v promptu převeď na kód. Model nech jen na místech s reálnou nejednoznačností.
- Schvalování jen u nevratných kroků. Neřeš gate u všeho — jen u akcí, které nejde vzít zpět (odeslání, mazání, platby). Zbytek nech běžet a loguj.
- Zapiš si směr práce. Místo prodlžování promptu si napiš krátký dokument „mise + principy + co je out of scope“, dej ho do verzování a nech ho agent číst. Příště ti bude rozumět líp než z promptu na dvě stránky.
Časté otázky
Je Kyno další agent framework?
Ne. Kyno neobsahuje žádný model — je to „control plane“ pro směr práce: verzovaný dokument s misí a principy, který si agent načítá během workflow. Není to standard ani hotová věc (Show HN s minimální odezvou), ale ukazuje směr: pravidla a smysl práce patří do verzovaných artefaktů, ne do stále delších promptů.
Proč definovat testy dřív, než agent píše kód?
Protože jinak review nemá nezávislou referenci. Testy napsané před implementací definují, co znamená „správně“, a pak se dají použít jako objektivní kritérium — člověk i agent ví, na čem selhalo, a oprava nemizí v dojmech z kódu.
Co je „nevratná akce“ u AI agenta?
Akce, kterou po provedení nemůžeš (levně) vzít zpět: odeslání e-mailu zákazníkovi, smazání dat, platba, změna ve veřejném repozitáři. U těchto kroků dává smysl brána s lidským schválením; u ostatních stačí logování a případný retry.
Stačí si logovat tokeny a konečnou odpověď agenta?
Dokud jsou běhy krátké, víceméně ano. Jakmile ale provozuješ dlouhé opakované joby, potřebuješ rozpad na kroky: mezivýstupy, cenu podle kroku, logy tool callů, spouštěče a stav při selhání. Bez toho nezjistíš, proč noční běh spadl, a zaplatíš ho dvakrát.
Musím na to všechno pořizovat speciální nástroje?
Ne nutně. Spousta týmů si základní logy postaví sama a je to dobrý způsob, jak zjistit, co reálně potřebuješ. Až ti přestane stačit drill-down do kroků, sáhneš po nástrojích pro observability agentů — postupně, ne předem.
