AI agenti jsou systémy, které se snaží autonomně řešit zadané úlohy - nejde o “chat nad PDFkem”. Agent bude součástí nějakého obchodního procesu, možná ne celého, ale nějakého kousku určitě. Pročti tohle, vyhodnoť si to, podle toho co zjistíš si sežeň další vstupy a tak dále. Ve finále jde o nějaký rozhodovací strom kde AI agent v rozbočeních rozhoduje nebo pomáhá rozhodovat kterou částí stromu se půjde dál. Zásadní otázka ale je - je tento strom, obchodní proces, a všechny jeho myslitelné větve navržen člověkem v nějakém orchestračním nástroji (LangGraph, n8n, Temporal, Logic Apps) nebo vzniká dynamicky v průběhu řešení úlohy (pochopení, naplánování, exekuce plánu, korekce směru apod.) tak jak se to dělá v Semantic Kernel, Agent Service nebo dnes dokonce i přímo průběhu reasoningu (tool use while thinking)? Odpověď je samozřejmě “záleží” a nejčastěji to vidím na kombinaci, ale zdá se mi, že lidé často podceňují trend - a tím je tak jak se AI zlepšuje je vhodné odstraňovat “lidský design”, strukturu a prostě nechat AI pracovat. Je to vidět posledních 70 let pořád znova a znova. Pojďme projít aspekty obou přístupů, proč bych dneska volil kombinaci a jak a taky proč trend vidím jako neustálý posun k self-orchestraci a autonomii. Chystám na to i konkrétní příklady s kódem, ale to až po dovolené.

Workflow, orchestrace a automatizace procesů (RPA)

Následující příklady platforem a frameworků jsou zaměřeny na nějakou formu orchestrace:

• LangChain nebo LangGraph vnímám jako statické orchestrace buď lineární (LangChain) nebo stromové (LangGraph - acyklický graf) specializované na AI systémy.
• Temporal, Azure Durable Functions nebo DAPR Workflows jsou typickými představiteli aplikační code-first orchestrace postavené na event-sourcingu. Vytvořit nad nimi můžete cokoli.
• Logic Apps nebo n8n jako příklad low-code orchestrace IT i obchodních procesů s hromadou hotových konektorů a integrací. Dnes často s AI kroky po cestě.
• UiPath zastupuje klasické robustní automatizace procesů (RPA).
• Data Factory, Apache Airflow, Apache NiFi nebo Delta Live Tables v Databricks představují datové orchestrace, tedy nějaké pravidelné či proudové přeskládávání a transformace dat.

V AI aplikaci budete chtít třeba strom, kde nejdřív LLM zjistí co uživatel vlastně chce (klasifikace dotazu), podle toho si načte politiky, prohledá databázi, podle toho co zjistí formuluje dotazy do podnikových systémů a tak podobně včetně toho, že třeba kontaktuje kolegu specializovaného AI agenta. Podstatné je, že tento strom je navržen člověkem a role jednotlivých LLM dotazů je v tom něco vyhodnotit, připravit a do jisté míry tím rozhodnout, jestli se v dalším kroku půjde doleva nebo doprava. Co je podstatné je, že v některý moment můžeme do procesu vtáhnout uživatele a třeba několik hodit čekat na jeho odpověď - například posláním aktivní karty s tlačítky do Teams. Tohle dnes můžete díky nové agentic loop krasně celé dělat v Logic App či n8n a to včetně integrací do toho okolí (Teams, Service Now, Jira, Slack, email, SharePoint, …). Code-first alternativou specializovanou vyloženě na AI workflow je právě LangGraph. No ale pokud je 90% celého procesu hodně o softwarové integraci (zakládání účtů v různých systémech, notifikace, schvalovačky) a chci code-first, tak dává smysl spíš Temporal nebo Azure Durable Functions.

Ale teď to zásadní - AI sice v těchto systémech může rozhodovat na kterou kolej se najede, ale ty koleje nestaví. Pokud se tedy objeví nové zadání, změna procesu, rozšířené možnosti nebo se ukáže, že navržený graf není pro některé situace optimální, znamená to systém upravit. Sebedokonalejší příprava nemusí v dnešním rychlém světě lidí stačit - schopnost ad-hoc plánovat a přemýšlet jak problémy vyřešit a současně mít schopnost uprostřed toho všeho plány i změnit je důležitá. A to nás vede na jiný přístup - self-orchestraci.

Self-orchestrace a ad-hoc plánování

LLM se dramaticky zlepšují a jsou dnes schopny sestavit a exekuovat plány. Ty největší úspěchy dnešního AI jako jsou deep research v různých produktech, soutěže v kódování a další fascinující průlomy, typicky mají na svědomí systémy, které používají flexibilní plánování a reasoning, ne fixní acyklický graf. Tímto směrem se koncepčně vydal Semantic Kernel a je to jeho hlavní rozdíl oproti LangChain a LangGraph. Stojí na principu naplánování řešení úlohy a následná exekuce s provoláváním jednotlivých nástrojů (skills) a podle jejich výsledku další postup - tedy multi-step se self-orchestrací. Dnes to dokonce můžete mít ve formě služby v Azure AI Foundry Agent Service - dáte jí nástroje (MCP, různá byznysová workflow s Logic App apod.) a agent sám naplánuje jak je použít v několika krocích. Další za mě velmi zajímavou variantou je framework CrewAI, který nabízí určitý mix kdy máte high-level plán, ale systém si sám plánuje kroky nižší úrovně a může i udělat změnu v postupu. Pochopitelně přístup typu Semantic Kernel má i nevýhody - nehodí se pro nějaké čekání v rámci procesu (schválení či názor člověka), je méně předvídatelný, pro jednoduché úlohy může volit zbytečně komplikované (a tím dražší) řešení, je hůře auditovatelný (byť to ještě není neuralese viz dále).

Doporučuji přečíst tento nedávný článek od Anthropicu, kde popisují jak jejich Research systém používá flexibilní plánování a reasoning v multi-agentním systému: How we built our multi-agent research system

No a takovým dnes ultimátním příkladem je podle mě používání nástrojů v průběhu přemýšlení.

Používání nástrojů v průběhu přemýšlení a Neuralese

Semantic Kernel volá LLM několikrát - při vytváření plánu, při exekuci kroků. Mezi jednotlivými kroky tedy přichází ke slovu tento framework, tedy nějaký kód. Nicméně nejnovější reasoning modely typu o3 dokáží používání nástrojů v průběhu reasoningu. 30 kroková orchestrace je tak jediné zavolání do LLM - model generuje reasoning tokeny, přemýšlí a může signalizovat touhu použít nástroj a něco mu předat za vstupní informace. To pro něj uděláte, nastreamujete odpověď zpět a model pokračuje v tomto LLM callu dál - jede si další reasoning tokeny. Fascinující je, že tady nemusíte manipulovat s kontextem a necháte model ať si to řeší podle sebe. Slyšeli jste příběh DeepSeek R1? Pokud se nechal model ať se naučí přemýšlet jak chce, tak používal “divný jazyk” - mix angličtiny a čínštiny. Jenže byl velmi efektivní - když model donutili myslet čistě hezky “lidskými” tokeny jeho výkon v některých oblastech se zhoršil! Jeden z důvodů proč velké komerční modely (OpenAI, Gemini, Anthropic) neukazují čisté přemýšlecí tokeny je kromě obchodního tajemství tipuji i snaha lidi neděsit. Očekávám, že některé myšlenky modelu, které hned zaplaší, se nám třeba nemusí úplně líbit nebo jim nemusíme rozumět. Nicméně - o3 self-orchestrace je úžasná věc a pro složité otevřené problémy je to nesmírně zajímavý přístup, ve kterém vidím největší budoucnost a je základem “odlehčeného deep research”, které je pro mě aktuálně nesmírně užitečné (nechci plytkost běžné odpovědi, ale často nepotřebuji výstup co budu číst deset minut).

Předpokládá se ale, že se tohle ještě posune - proč nutíme model myslet v lidštině? Nebo multi-agentní systémy nechat komunikovat anglicky? Proč vnitřní reprezentaci konceptů ve vícedimenzionálním latentním prostoru převádět na lidštinu a zase zpět s tou vší ztrátovostí, která s tím souvisí? Proč nemůže model myslet nebo dva modely spolu komunikovat “telepaticky”, tedy z mozku do mozku bez úst, širokopásmovými maticemi místo tokenů? Tomu se obvykle říká neuralese a děsivé je na tom to, že tomu jazyku nebudeme rozumět (nicméně můžeme sestrojit AI pro jeho vysvětlení), takže pokud jsem mluvil o snížené schopnosti auditovatelnosti, tak tady je to pochopitelně ještě složitější. Dnes máme poměrně špatnou představu co se děje v “mozku” LLM (byť nějaké pokroky v mechanistické interpretovatelnosti LLM jsou), ale rozumíme jejich interakci s okolím (nástroje, lidé, další agenti). S neuralese by to tak už nebylo, ale předpokládám, že zlepšení kvality bude tak zásadní, že bude mít lidstvo tendenci jim tu ne-lidštinu opustit.

70 let odstraňování lidského designu v AI

Kdysi se budovaly tzv. expertní systémy, rule-based AI ve formě masivního grafu pravidel - nepřežilo, později nahrazeno samo-učímimi-se systémy jako jsou neuronové sítě. V počítačovém vidění experti programovali jednotlivé kernely a filtry - nepřežilo, nahrazeno samoúčící CNN. V NLP experti programovali pravidla pro parsování a syntaxi nebo používali strojové učení, kterému ale nařizovali jak to má dělat - nepřežilo, transformer self-attention si to najde podle sebe. DeepBlue porazil člověka v šachu pečlivě designovanou heurestikou a učením z historie lidských tahů - nepřežilo, AlphaZero se neučilo šachy za 4 hodiny hraní samo se sebou jen na základě znalosti pravidel. Skvěle to sepsal v slavném krátkém článku Bitter Lesson Rich Sutton v roce 2019. Jak se AI zlepšuje tak průlomů a pokroků je dosaženo tím, že se nechá AI makat a ono si na to přijde. Je to ostatně vidět i v samotné architektuře modelů - transformery jsou velmi univerzální architektura. Vezměme si třeba, že dříve byla snaha trénovat specializované modely a pak je propojovat a tohle celé určoval a řídit člověk. Dnešní Mixture of Experts modely necháváme ať si uvnitř sebe vytvoří experty a to včetně rozhodování co na kterého poslat - všechno je naučené, ne naprogramované. Je tam expert na logiku, matematiku, básničky? Možná, ale lidé to neurčují, nekecají mu do toho.

Rozhřešení - jak bych dnes o AI agentech přemýšlel

Není to o tom jestli použít LangGraph nebo Semantic Kernel a ve skutečnosti i kombinace může dávat smysl. LangGraph můžu použít pro high-level proces jako je definice přechodů mezi jednotlivými hráči v multi-agentním systému, pokud ji z nějakého třeba compliance důvodu potřebuji definovat. Jednotlivý agenti ale mohou být třeba Agent Service (což je ve finále Semantic Kernel) s 30 nástroji a self-orchestrací uvnitř. Stejně tak se mi líbí varianta použítí Logic Apps nebo n8n pro části řešení, kde jsou integrace na IT systémy - proč psát logiku napojení na Teams a posílání živých karet uživatelům nebo hledání kolegů ze stejného oddělení, tohle přece nechci kódovat v AI frameworku. Ať už je to posunutí Logic App workflow jako nástroje pro Agent Service nebo naopak provolání Agent Service z nějakého byznys workflow v Logic App, tyhle přechody dávají smysl. Nemyslím, že je vhodné soustředit se na jediný nástroj a narvat do něj všechno - jak říkáme my architekti, to přece “záleží”.

Závěr je pro mě jiný. Považuji za zásadní být neustále připraven průběžně vysekávat lidské komponenty z designu vnitřního fungování AI aplikací. Vzhledem k rychlosti vývoje bych každé 3 měsíce přemýšlel kde můžu vyhodit orchestraci, které kroky a uzly v LangGraphu můžu konečně smazat a nechat AI ať si to řídí samo. Jak AI postupuje rychle dopředu bude to dělat lépe a lépe. AI aplikace jsou kandidátem na neustále zjednodušování, ne naopak.