Proč agentní AI vyžaduje vlastní runtime infrastrukturu mimo chatboty

Agentní umělá inteligence představuje model, kde software agent autonomně vykonává komplexní úkoly napříč systémy, pracovními procesy a datovými zdroji. Na rozdíl od konverzačních AI jde o software, který se rozhoduje, přistupuje k nástrojům a plní zadání bez průběžného lidského zásahu. Tato změna staví před podniky otázku infrastruktury: běžné chatbot platformy ani API brány nejsou navržené pro scénář, kdy agent sám volá systémy, pamatuje si kontext mezi sezeními a musí respektovat firemní politiky při každém kroku.

Agent vyžaduje vlastní výpočetní kapacitu a přístup k datům

Agentní AI nepracuje jako nástroj s jedním vstupem a výstupem. Typický scénář vypadá takto: dostane zadání („zajisti schválení faktury nad limit a upozorni vedoucího“), načte data z několika zdrojů, zavolá workflow API, počká na odpověď, vyhodnotí výsledek a případně celý proces opakuje. Každý krok spotřebovává výpočetní čas, paměť a datové připojení. Klasický cloudový endpoint pro LLM model tento vzor neřeší – není stavěný pro dlouhé běhy s mezikroky.

Pokud firma provozuje agenty na sdílené infrastruktuře optimalizované pro rychlé odpovědi, narazí na limit latence a zátěže. Agent potřebuje CPU kapacitu, která během čekání na API nebo databázový výsledek neblokuje další požadavky. Potřebuje také přístup k datům s garancí dostupnosti – pokud agent během běhu ztratí připojení k CRM nebo ERP, musí znát způsob, jak proces bezpečně přerušit nebo pokračovat po obnově spojení.

Firemní politiky musí platit na úrovni každého volání nástroje

Agent se sám rozhoduje, jaký nástroj nebo API zavolá podle situace. Pokud dostane právo přistupovat k HR databázi, může během běhu zavolat dotaz na platy zaměstnanců. V klasickém návrhu by to znamenalo, že agent musí respektovat oprávnění definovaná mimo LLM model – ale řada současných agentic frameworků tento krok nepokrývá nativně.

Pro firmu to znamená stavět runtime, kde každé volání nástroje prochází policy checkem: má tento agent právo číst danou databázi v tomto kontextu? Tento mechanismus nelze elegantně naroubovat na chatbot platformu, protože tam kontrola probíhá při vstupu nebo výstupu, ne v průběhu multi-step procesu. Podnik musí zavést policy engine, která rozumí kontextu agenta, jeho roli a aktuálnímu stavu task runbooku.

Observabilita musí zachytit celý běh agenta včetně mezikroků

Agentní proces může trvat minuty nebo hodiny. Pokud selže, potřebujete vědět, v jakém kroku a proč. Klasické logování API hovorů není dostatečné – agent může volat desítky API za běh a změnit strategii podle výsledků. Observabilita proto musí zachytit trace celého běhu: jaký nástroj agent zavolal, s jakým parametrem, co dostal zpět, jak vyhodnotil odpověď a co udělal dál.

Pro firmu to znamená implementovat trace systém pro AI agenty, který funguje podobně jako distribuované tracování mikroslužeb. Rozdíl je v tom, že kroky nejsou pevně dané v kódu – agent si je volí za běhu podle LLM výstupu. Bez tohoto náhledu firma neví, proč agent udělal neočekávané rozhodnutí nebo kde přesně došlo k chybě v procesu schvalování či dotazování.

Memory management určuje, jak dlouho agent drží kontext bez úniku dat

Agent si pamatuje předchozí interakce a výsledky kroků. Tato paměť může obsahovat citlivá data – jména klientů, čísla objednávek, interní poznámky. Pokud agent běží opakovaně pro různé uživatele, musí platforma zajistit, že kontext jednoho běhu neunikne do jiného. Klasické session managery to řeší pro jeden požadavek, ale agentní scénář vyžaduje správu dlouhodobé paměti s explicitním smazáním po ukončení úkolu.

Firma musí rozhodnout, jak dlouho agent drží historii konverzace a akcí, kde je uložená a jak ji izolovat mezi různými běhy. Pokud agent zpracovává osobní údaje, paměť musí respektovat retention pravidla podle GDPR – to znamená automatické mazání kontextu po definované době nebo události. Runtime proto musí nabídnot memory API s kontrolou nad životním cyklem uložených dat.

Nasazení agentů vyžaduje orchestrační vrstvu nad současnými AI platformami

Většina firemních AI platforem dnes nabízí API pro volání modelů a embeddings. Tato vrstva ale neřeší orchestraci multi-step procesů, správu nástrojů, policy engine ani observabilitu běhů. Pokud firma chce agenty nasadit v produkci, musí postavit nebo adoptovat orchestrační platformu, která tyto části integruje.

Prakticky to znamená rozhodnout se mezi stavbou vlastního runtime (náročné na čas a skill) nebo použitím vznikajících agentic platform řešení. Tato rozhodnutí mají dopad na architekturu IT: agentní runtime musí sedět mezi LLM API a firemními systémy a sloužit jako kontrolní bod pro data, oprávnění a audit. Bez této vrstvy firma nemůže nasadit agenty zodpovědně v procesech, kde jde o compliance, citlivá data nebo finanční transakce.