
Všichni dnes experimentují s AI agenty. Je to vzrušující doba, ale také období, které často končí frustrací, když se skripty z notebooku nepodaří zkrotit pro firemní nasazení. David Bečvařík, CTO Etnetera Core, se rozhodl tento problém vyřešit po svém. Místo hledání existujících hotových nástrojů postavil vlastní platformu pro běh agentů.
Za nás to byl hlavně praktický problém. Nezačalo to tím, že bychom si řekli, že si postavíme agentní platformu, protože je to zrovna trend. Začalo to tím, že jsme měli agenty, kteří uměli zajímavé věci, ale reálně žili někde v notebooku, v lokálním skriptu nebo v prototypu. A to je přesně moment, kdy se ukáže rozdíl mezi experimentem a produkcí.
Experiment na notebooku je skvělý pro ověření myšlenky. Ale ve firmě potřebujeme vědět, kdo agenta spustil, k jakým datům měl přístup, kolik utratil, co přesně udělal, proč to udělal a jak to celé doložíme zpětně. Zároveň potřebujeme, aby se agent neztratil ve chvíli, kdy čeká na schválení člověka, spadne služba nebo se restartuje infrastruktura.
Hlavní spouštěč byl tedy jednoduchý. Agenti potřebovali domov. Prostředí, kde mají jasné mantinely, bezpečnost, auditní stopu a provozní spolehlivost. Bez toho je agent jen zajímavé demo. A těch je dnes plný internet. My jsme chtěli něco, co se dá použít u klienta, kde existuje regulace, bezpečnostní pravidla, rozpočty a odpovědnost.
Tohle je podle nás jedna z největších změn v uvažování. Hodně lidí si pod AI pořád představuje chatovací okno, do kterého něco napíší a ono jim něco odpoví. Jenže to není produkční model práce. To je interakce. Často užitečná, ale pořád jen interakce.
My nechceme, aby si firma pouze povídala s modelem. Chceme, aby agent vykonával konkrétní práci. Aby měl jasný úkol, vstupy, pravidla, schvalovací kroky, limity, napojení na systémy a výstup, který se dá ověřit. V tom je obrovský rozdíl.
Chat je neopakovatelný zážitek. Agentní workflow musí být opakovatelné, dohledatelné a testovatelné. Proto agenta definujeme jako řízený proces, ne jako volnou konverzaci. Model je jen jedna součást. Důležité je všechno okolo: orchestrace, stav, bezpečnost, validace, testy, monitoring a audit.
Je to podobné jako u klasického softwaru. Nikdo rozumný by neposlal do produkce kus kódu jen proto, že jednou fungoval na vývojářově stroji. U agentů to musí platit úplně stejně. Pokud mají dělat seriózní práci, musíme se k nim chovat jako k softwaru, ne jako k chytrému chatbotu.
Temporal je pro nás základní stavební kámen, protože řeší věc, která se u agentů hodně podceňuje. Agent v reálném světě neběží pět sekund. Často čeká. Na člověka, na CRM, na schválení, na externí systém nebo na další krok v procesu. A v tu chvíli potřebujeme, aby neztratil kontext.
Když máme jednoduchý skript, tak dokud běží, je všechno hezké. Jakmile spadne, máme problém. Nevíme přesně, kde skončil, co už udělal, co se má zopakovat a co by se naopak opakovat nemělo. U běžného interního nástroje je to nepříjemné. U agenta, který může pracovat s daty, volat API nebo něco měnit v systémech, je to průšvih.
Temporal nám dává odolnost. Každý krok workflow je stavově řízený a obnovitelný. Když něco spadne, agent nenastupuje znovu od nuly. Pokračuje tam, kde má. To je rozdíl mezi „snad to doběhne“ a „víme, jak se to zachová“.
A to je přesně rozdíl mezi prototypem a produkčním systémem. Agent nemůže být kouzelná krabička. Musí být součást architektury, která počítá s chybami, výpadky, retry logikou, timeouty a lidským schvalováním.
Je to docela dobrý dogfooding. Stavíme platformu pro agenty pomocí agentů. Díky tomu velmi rychle poznáme, co funguje jen v prezentaci a co obstojí v reálné práci.
Máme agenty s jasně definovanými rolemi. Jeden se chová jako produktový člověk, další jako architekt, další píše kód, další dělá review. Není to ale tak, že řekneme modelu „nějak to napiš“. To by byla cesta do chaosu. Máme pravidla, workflow, testy a jasné hranice odpovědnosti.
Každá smysluplná změna musí mít oporu v architektuře, testech a přijatelném návrhu. Hodně tlačíme na E2E testy, integrační testy a validaci proti očekávanému chování. Agenti jsou výborní v rychlosti, ale přesnost nevznikne sama od sebe. Přesnost vznikne z dobrého zadání, dobrých mantinelů a rychlé zpětné vazby.
Tohle je důležité i obecně pro firmy. AI nezachrání špatný engineering. Naopak ho často velmi rychle odhalí. Pokud nemáme architekturu, testy a jasné procesy, agenti jen zrychlí chaos. Pokud je máme, dokážou dramaticky zrychlit vývoj i provoz.
První pravidlo je jednoduché. Nepouštějte agenty napřímo k datům, systémům a klíčům. To je podle nás nejčastější chyba. Vezme se API klíč, dá se agentovi, připojí se mu pár nástrojů a vznikne pocit, že máme hotovo. Ve skutečnosti jsme si tím často otevřeli bezpečnostní díru.
My to řešíme přes LLM Gateway a MCP proxy. Agent nepracuje přímo se skutečným klíčem k OpenAI, Anthropicu nebo jinému modelu. Dostane virtuální klíč a každá komunikace jde přes kontrolovanou vrstvu. Tam umíme řešit rozpočty, limity, logování, guardrails, detekci citlivých dat, pravidla pro konkrétního klienta a případně i validaci toho, co z organizace odchází ven.
Druhá věc je auditovatelnost. V produkci nestačí říct „model to nějak rozhodl“. Potřebujeme doložit, jaký byl vstup, jaký nástroj agent použil, jaké rozhodnutí udělal, kde čekal na člověka a co byl finální výstup. Bez toho se s agenty v regulovaném prostředí nedá seriózně pracovat.
A třetí věc je princip nejmenších oprávnění. Agent nemá mít přístup ke všemu jen proto, že by se mu to mohlo hodit. Má mít přístup jen k tomu, co potřebuje pro konkrétní úkol. Stejně jako člověk nebo služba v normální architektuře.
Teď se posouváme od platformního jádra k opakovatelnému použití. To je klíčové. Nechceme pokaždé stavět agenta od nuly. Chceme mít knihovnu bezpečných blueprintů a komponent, ze kterých půjde rychle poskládat konkrétní řešení pro interní proces nebo klientský projekt.
Důležité je, aby vývojář nebo tým nemusel znovu řešit základní hygienu. Tedy jak agenta spustit, jak ho omezit rozpočtem, jak auditovat kroky, jak připojit nástroje, jak řešit schválení člověkem, jak validovat data a jak to celé provozovat. To má být součást platformy.
Zároveň nechceme být závislí na jednom modelu nebo jednom cloudu. Platforma musí umět pracovat s velkými modely typu OpenAI nebo Anthropic, ale také s menšími lokálními modely tam, kde to dává smysl kvůli ceně, latenci nebo citlivosti dat.
Prakticky řečeno, cíl je jednoduchý. Přijde tým, vezme bezpečný blueprint, upraví doménovou logiku, nasadí agenta a má jistotu, že se pohybuje v mantinelech. Bezpečně, auditovatelně a škálovatelně.
Myslíme si, že za rok se budeme trochu smát tomu, co dnes považujeme za pokročilé. Ne proto, že by to bylo špatně, ale protože vývoj je extrémně rychlý. Spousta věcí, které dnes ručně lepíme dohromady, bude standardní součást vývojářských a provozních platforem.
Zároveň si nemyslíme, že budoucnost je v tom, že budeme mít víc chatovacích oken. To je podle nás slepá ulička. Agenti budou víc v pozadí. Budou napojení na procesy, systémy a data. Člověk bude nastavovat cíl, kontrolovat kritické kroky a řešit výjimky. Rutinní práci budou dělat agenti.
Ale jedna věc se nezmění. Pořád to bude inženýřina. AI není magie. Je to software, data, procesy, bezpečnost, observabilita a odpovědnost. Kdo tohle podcení, skončí u drahých experimentů. Kdo to postaví dobře, získá obrovskou páku pro vývoj, provoz i byznys.
Tohle je za nás nejzajímavější část celé vlny AI. Ne to, že model umí hezky odpovědět. Ale to, že dokážeme stavět systémy, které reálně přebírají části práce, jsou kontrolovatelné a dají se pustit do prostředí, kde na výsledku záleží.
_____