Väčšina firiem, s ktorými sa rozprávame, chce AI agenta. Keď sa pýtame, čo konkrétne agent robí, dostávame odpovede typu "zvládne všetko", "bude komunikovať s dodávateľmi, sledovať faktúry aj plánovať zmeny". V tom je zakopaný pes. Agent, ktorý robí všetko, zvyčajne nespoľahlivo robí nič.
Tento článok je praktický postup — nie teória, ale rozhodovací rámec, ktorý sme overili pri reálnych nasadeniach. Povedieme vás od výberu prvého use-casu cez definíciu nástrojov, guardrails a vyhodnocovanie až po to, ako agenta postupne rozširovať. A tiež vám povieme, čomu sa na začiatku radšej vyhnúť.
Krok 1: Vyberte si úzky, dobre ohraničený use-case
Najčastejší dôvod zlyhania prvého agenta nie je technický. Je to príliš široký scope.
Dobrý prvý use-case spĺňa tieto kritériá:
- Jasný vstup a výstup — agent dostane niečo konkrétne a vracia niečo konkrétne (nie "spracuje email")
- Overiteľnosť výsledku — vy alebo systém viete zistiť, či agent urobil správnu vec
- Ohraničené nástroje — maximálne 3–5 nástrojov, nie "prístup k všetkým systémom"
- Tolerovateľná chybovosť — ak agent urobí chybu, viete to zachytiť pred dopadom
Príklady, ktoré v praxi fungujú ako prvé projekty: agent, ktorý každé ráno stiahne nové reklamácie z helpdesku, kategorizuje ich a zapíše sumarizáciu do Excelu alebo tabuľky; agent, ktorý kontroluje nové objednávky v systéme a zavolá predpísané API kroky, ak objednávka splní definované podmienky; agent, ktorý na požiadanie vytiahne relevantnú dokumentáciu z internej knižnice pomocou RAG nad priemyselnou dokumentáciou a sformuluje odpoveď.
Naopak, neodporúčame ako prvý projekt: agent s prístupom do viacerých oddelení naraz, agent, ktorý posiela e-maily alebo vystavuje faktúry bez dohľadu, alebo agent, kde nie je jasné, ako budete merať úspech.
Krok 2: Definujte nástroje — nie "čo agent môže", ale "čo agent smie"
Nástroje sú srdce agenta. Agent bez nástrojov je len chatbot; agent s príliš voľnými nástrojmi je bezpečnostné riziko.
Pri definícii nástrojov premýšľajte v dvoch krokoch:
Čo agent fyzicky potrebuje? - Čítanie (databáza, API, súbory, vektorová DB) - Zapisovanie (update záznamu, odoslanie správy, zápis do systému) - Výpočet alebo transformácia (konverzia formátu, sumarizácia, klasifikácia)
Čo agent dostane povolenie robiť? Toto je kritický krok, ktorý sa preskakuje. Každý nástroj má mať explicitný scope: agent smie čítať záznamy z tabuľky X, ale nie mazať. Smie volať API endpoint Y s read-only kľúčom. Smie zapisovať do sekcie Z, ale nie meniť historické záznamy.
Dobré pravidlo pre prvého agenta: write operácie iba cez HITL gate — teda so schválením človeka pred vykonaním. Human-in-the-loop pri agentoch nie je komplikovaná architektúra; v LangGraph je to jedno interrupt() volanie. Pridá latenciu na čas ľudskej reakcie, ale zabraňuje nezvratným chybám.
Schéma každého nástroja musí byť strojovo validovateľná. Ak agent vráti malformovaný JSON ako argument nástroja, musíte to zachytiť a opakovať — nie ticho ignorovať. To nie je edge case, v produkcii je toto bežný zdroj problémov.
Krok 3: Zvoľte jednoduchú architektúru
Pre prvého agenta odporúčame ReAct slučku — Reason, Act, Observe v jednoduchom grafe. Dôvod je prostý: je to najlepšie debugovateľná architektúra.
Ak ste si prečítali článok Architektúry AI agentov, viete, že existujú sofistikovanejšie vzory (Plan-and-Execute, Reflexion, multi-agent). Tie sú validné — ale nie pre prvý projekt. Každý krok navyše je ďalší zdroj potenciálnej chyby a ďalšia vrstva, kde neviete, čo sa deje.
Konkrétny odporúčaný stack:
- Framework:
LangGraph— graf-based, explicitný stav, zabudovaný checkpointing; produkčne overený pre enterprise nasadenia - Model: začnite s lacným, rýchlym modelom (Haiku tier, Flash tier alebo lokálny model cez
Ollama); frontier modely (Opus, GPT) zapnite až keď základná logika funguje - Pamäť: krátkodobý kontext v stave grafu; pre dlhší horizont vektorová DB — ale iba ak to prvý use-case skutočne vyžaduje
Veľká chyba na začiatku: vybrať najvýkonnejší a najdrahší model lebo "chceme najlepšie výsledky", a potom sa diviť, prečo sú náklady neúnosné. Model je ľahko vymeniteľný. Architektúra a nástroje sú oveľa ťažšie.
Jeden praktický detail: nastavte maximálny počet krokov slučky. Agent bez limitu môže pri neočakávanom vstupe cykliť a za noc spotrebovať tisícky tokenov. Hodnota 10–15 krokov na jednu úlohu je rozumný štart pre väčšinu use-casov.
Krok 4: Guardrails — nie ako filter, ale ako architektúra
Guardrails pre AI agentov sú téma, ktorá sa podceňuje pri prvom projekte a potom bolestne doháňa neskôr.
Guardrails nie sú len výstupný filter ("skontroluj, či odpoveď neobsahuje niečo zlé"). Guardrails sú viacvrstvová architektúra:
- 1.Vstupná validácia — čo vstupuje do agenta? Je to formát, ktorý agent očakáva? Obsahuje vstup potenciálne nebezpečné inštrukcie?
- 2.Intent classification — ak agent dostáva voľný text od používateľov, treba klasifikovať zámer pred odovzdaním agentskej slučke
- 3.Tool permission scope — ako sme opísali vyššie: každý nástroj má povolenia
- 4.HITL gate pre write operácie — kritické akcie vyžadujú ľudské potvrdenie
- 5.Výstupný filter — sémantická kontrola odpovede pred odoslaním
Pre prvého agenta v internom prostredí (nie vystavenom externým používateľom) stačí začať s bodmi 3 a 4. Vstupná validácia a intent classification sú nevyhnutné, ak agent dostáva vstupy od externých alebo neznámych zdrojov.
Prompt injection — teda útok, kde nebezpečný obsah vo vstupe presviedča agenta robiť niečo iné, ako má — je podľa OWASP LLM Top 10 najčastejšia bezpečnostná hrozba AI aplikácií. Ak váš agent načítava akýkoľvek externý obsah (e-maily, webové stránky, súbory od zákazníkov), musíte s týmto rizikom aktívne rátať.
Krok 5: Observability — bez toho nepustite agenta do produkcie
Toto je pravidlo, od ktorého neustupujeme: agent bez observability nie je produkčný agent. Je to proof-of-concept.
Čo konkrétne potrebujete vedieť o každom behu agenta:
- Aký bol vstup a výstup
- Koľko krokov slučky prebehlo
- Ktoré nástroje boli volané, s akými argumentmi, čo vrátili
- Kde nastala chyba (ak nastala) a prečo agent vybral konkrétnu akciu
Nástroje, ktoré toto poskytujú: Langfuse (framework-agnostický, self-hostable), LangSmith (hlboká integrácia s LangGraph), Arize Phoenix (OpenTelemetry-based, pokročilé eval metriky). Observability AI agentov je dnes zrelá oblasť — nie je dôvod si to budovať od nuly.
Konkrétny prínos v praxi: pri jednom nasadení pre klienta z logistiky sme cez traces objavili, že agent správne kategorizoval 94 % prípadov, ale pri jednej kategórii konzistentne volal nástroj s chybným argumentom. Bez observability by sme to zistili až po desiatkach chybných zápisov v systéme.
Krok 6: Eval — ako viete, že agent funguje správne?
Eval (vyhodnocovanie) je krok, ktorý sa pri prvom projekte najčastejšie preskakuje. Dôsledok: nevieme, či zmena v prompte, modeli alebo nástrojoch veci zlepšila alebo zhoršila.
Pre prvého agenta stačí jednoduchý eval harness:
- Zostavte 20–50 testovacích prípadov s definovaným vstupom a očakávaným výstupom alebo akcíou
- Spustite agenta nad týmito prípadmi po každej väčšej zmene
- Sledujte aspoň dve metriky: task completion rate (dokončil agent úlohu?) a tool call accuracy (volal agent správne nástroje so správnymi argumentmi?)
Nemusíte hneď nasadiť komplexný eval framework. Skript, ktorý spustí agenta nad testovacím setom a vypíše skóre, je lepší ako žiadny eval. Ako systém rastie, vyhodnocovanie RAG a LLM aplikácií sa stáva sofistikovanejším — ale základ ostáva rovnaký: mať referenčný set a merať oproti nemu.
Čomu sa vyhnúť pri prvom agentovi
Zo skúseností z nasadení — tu sú najčastejšie chyby, ktoré predlžujú projekt alebo ho zastavujú:
Príliš veľa nástrojov od začiatku. Každý nástroj je ďalší zdroj zlyhania. Začnite s tromi, rozširujte na základe skutočnej potreby.
Žiadne HITL pre write operácie. Prvý write, ktorý agent urobí nesprávne bez možnosti zachytenia, zvyčajne ukončí projekt. Pridajte schválenie — môžete ho odstrániť neskôr, keď máte dôveru v spoľahlivosť.
Multi-agent systém ako prvý krok. Multi-agent systém v praxi má zmysel, keď jeden agent nestačí. Ale keď ešte nevieme, čo jeden agent robí zle, pridávanie ďalších agentov zmätok zväčší, nie zmenší.
Model ako hlavná premenná. Počuli sme viackrát: "Vyskúšame GPT-5, určite to vyrieši problémy." V praxi väčšina problémov pochádza zo zlej definície nástrojov, chýbajúcej validácie alebo nejasného scopu — nie z kvality modelu. Riešte architektúru, nie model.
Žiadne maximálne limity. Agent bez limitu na počet krokov, bez timeoutu a bez cost alertu môže cez noc vygenerovať tisícky volaní. Nastavte limity od prvého dňa.
Postupné rozširovanie: od prototypu k produkcii
Prvý funkčný agent je prototyp. Cesta do produkcie vyžaduje niekoľko explicitných krokov:
- 1.Eval nad testovacím setom — aspoň 20–50 prípadov, task completion rate > 85 % ako minimálna podmienka
- 2.Shadow mode — agent beží paralelne s existujúcim procesom, ale nezasahuje; porovnávate výstupy
- 3.HITL pre všetky write operácie — v prvej produkčnej fáze schvaľuje človek každú akciu
- 4.Observability live — traces musia byť dostupné od prvého dňa v produkcii
- 5.Postupné znižovanie HITL — po 2–4 týždňoch s dobrými metrikami môžete HITL odstrániť pre nízkorizikové akcie
Rozširovanie scope (nové nástroje, nové use-casy) je vždy iterácia rovnakého cyklu: definuj, otestuj v shadow mode, postupne nasaď, sleduj metriky.
Časté otázky
Aký model zvoliť pre prvého agenta?
Začnite lacným a rýchlym modelom — Haiku alebo Flash tier, prípadne lokálny open-weight model ako Ollama s Qwen alebo Llama. Frontier modely (Opus, GPT) zapnite až keď základná logika funguje a viete, kde presne model nestačí. Výmena modelu je ľahká; oprava architektúry nie.
Koľko nástrojov môže mať prvý agent?
Odporúčame maximum 3–5 nástrojov v prvej verzii. Každý nástroj je ďalší zdroj zlyhania a ďalšia vec, ktorú treba testovať. Lepšie mať troch dobre otestovaných nástrojov ako desiatich s nejasnými hranicami.
Musím používať LangGraph alebo iný framework?
Nie je to povinnosť. Vlastný kód dáva plnú kontrolu a niekedy menej abstrakcie, ako je potrebné. Dôvod, prečo odporúčame LangGraph pre prvé produkčné nasadenia, je zabudovaný checkpointing, HITL interrupt() a dobré traces — tieto veci si inak budujete od nuly.
Kedy má zmysel prejsť na multi-agent architektúru?
Keď jeden agent konzistentne nestíha — typicky kvôli príliš veľkému scopu úlohy alebo potrebe paralelného spracovania. Ak agent robí sekvenčne 15 krokov, kde by mohli niektoré bežať paralelne, je čas na multi-agent prístup. Ale toto je druhý alebo tretí projekt, nie prvý.
Ako odhadnúť náklady agenta v produkcii?
Kľúčová premenná nie je len cena modelu, ale aj počet krokov slučky na úlohu a retry rate. Ak agent priemerne robí 5 krokov a retry rate je 12 %, skutočný počet volaní je o 12 % vyšší — a pri viacstupňových pipelines sa tento overhead ďalej násobí. Podrobnejší rámec na odhad nájdete v článku Náklady AI agenta v produkcii.
*MP Industrial Solutions pomáha firmám definovať, navrhnúť a nasadiť prvého AI agenta — od výberu use-casu cez technickú architektúru až po produkčné nasadenie s observability a guardrails. Ak zvažujete prvý krok, radi posúdime váš konkrétny prípad na úvodnej konzultácii.*