Když jsme začínali stavět AIssistanta, stáli jsme před klasickým rozhodnutím: postavit orchestraci AI agenta na hotovém frameworku typu LangGraph, nebo si napsat vlastní? Vybrali jsme si vlastní state machine. Tady je proč a co jsme se u toho naučili.

Co orchestrace u AI agenta vlastně řeší

AI agent není „jeden LLM call“. Každá příchozí zpráva u nás prochází pipeline: sanitizace vstupu → klasifikace → agent → validace výstupu → deterministická exekuce akce → audit log. Orchestrace řeší, jak tyhle kroky poskládat: co se stane, když krok selže, kdy retry, kdy timeout, kdy eskalace na člověka a jak se celý průchod zaznamená.

K tomu přidejte reálný provoz: souběžné zprávy od stejného kontaktu, idempotenci (webhook od telefonie může přijít dvakrát), a požadavek, že rozpracovaná konverzace musí přežít restart aplikace. To je orchestrační problém, ne AI problém.

Co nabízí LangGraph

LangGraph modeluje agenta jako graf uzlů se sdíleným stavem. Dostanete checkpointing (uložení stavu mezi kroky), streaming, human-in-the-loop přerušení a vizualizaci grafu. Pro rychlé prototypování multi-agentních flow je to skvělá věc a ekosystém kolem LangChainu je obrovský.

Nic z toho nezpochybňujeme. Náš problém byl jinde.

Proč jsme zvolili vlastní orchestraci

  • Bezpečnostní vrstvy musí být mimo dosah frameworku. Naše architektura stojí na tom, že LLM generuje jen intent a deterministický kód validuje a vykonává. Nechtěli jsme, aby hranice mezi „LLM světem“ a „deterministickým světem“ vedla skrz abstrakce třetí strany, které se mění s každou major verzí.
  • Náš graf je malý a stabilní. Pipeline má jednotky dobře definovaných stavů a přechodů. Na to stačí explicitní enum + switch. Framework se vyplatí, když je graf velký, dynamický nebo se často mění. Ten náš není.
  • Upgrade churn. Ekosystém kolem LLM frameworků se v době vývoje měnil po týdnech. Každý upgrade znamená re-audit bezpečnostně kritické cesty. U vlastního kódu auditujeme jen vlastní změny.
  • Debugging a observabilita. Stack trace z vlastního state machine vede přímo do našeho kódu. Ladit produkční incident přes několik vrstev framework abstrakcí je výrazně dražší.
  • Testovatelnost. Přechodová funkce je čistá funkce: (stav, událost) → nový stav + akce. Unit testy bez mocků frameworku, včetně chybových cest, tedy přesně to, co po nás chce security review.

Jak náš state machine vypadá

Nic exotického, a to je záměr:

  • Explicitní výčet stavů konverzace a povolených přechodů; nevalidní přechod je chyba, která se loguje a alertuje.
  • Každý krok je idempotentní: opakované doručení téže události nezpůsobí druhou akci.
  • Stav se persistuje po každém přechodu; proces může kdykoli spadnout a pokračovat.
  • Timeouty a retry limity jsou data (konfigurace per krok), ne rozeseté konstanty.
  • Každý přechod zapisuje do audit logu: vstupní hash, stav před/po, latence, výsledek.

Kdy bychom LangGraph doporučili

Poctivě: naše volba není univerzální pravidlo. LangGraph (nebo podobný framework) dává smysl, když prototypujete a potřebujete výsledek do týdne, když váš flow je skutečně dynamický multi-agentní graf, nebo když nemáte kapacitu vlastní orchestraci dlouhodobě udržovat. Framework vám také dá zadarmo věci, které se vlastním kódem píší otravně, hlavně streaming a checkpointing.

Lessons learned

  • Rozhodujte podle bezpečnostních hranic, ne podle hype. Otázka nezněla „je LangGraph dobrý?“, ale „kudy povede hranice mezi pravděpodobnostním a deterministickým kódem?“.
  • Malý počet stavů je feature. Pokud váš agent potřebuje desítky stavů, zjednodušte produkt, ne orchestraci.
  • Vlastní kód není zadarmo. Platíme údržbou. Vyplatí se to jen proto, že je té logiky málo a je kritická.

Za rok může být odpověď jiná, frameworky dozrávají. Ale principy zůstávají: bezpečnostní invarianty patří do kódu, který plně kontrolujete.