Event-driven agenti: architektura AutoGen v0.4 / AG2 vysvetlena

Event-driven agenti su autonomni softverovi aktori, ktori komunikuju asynchronne prostrednictvom sprav a eventov - nie v pevnej, sekvencnej slucke. Kazdy agent reaguje na prichadzajuce eventy, spracuva ich nezavisle a publikuje svoje vysledky ako nove eventy. Tato architektura, ako ju implementuju AutoGen v0.4 a komunitou riadeny fork AG2, oddeluje agentov od seba a umoznuje paralelizmus, volnu vazbu a dlhe behy.

• Jadro: Agenti = aktori s vlastnym stavom, ktori komunikuju vylucne prostrednictvom asynchronnych sprav namiesto centralnej riadiacej slucky.
• Vyhoda: Volna vazba, skutocny paralelizmus a vhodnost pre dlho beziace procesy (minuty az hodiny) s cakanim na externe systemy alebo ludi.
• Trade-off: Vyssia komplexnost pri debuggingu, tracingu a preukazatelnosti - tok riadenia uz nie je linearne citatelny.

Od orchestrovanej slucky k Event-Busu

Vacsina klasickych agentnych vzorov je prisne sekvencna. Pri vzore ReAct napriklad jediny agent na baze velkeho jazykoveho modelu (LLM) opakovane prechadza cyklus Thought -> Action -> Observation, az kym neemituje finalnu odpoved. Latencia je pritom svojou povahou seriova: zodpoveda priblizne poctu krokov vynasobenemu suctom casu odpovede LLM a casu odpovede toolu. Aj Plan-and-Execute alebo ReWOO sice planuju vopred, no kroky v jadre vykonavaju jeden za druhym.

Event-driven architektury sa s tymto modelom rozchadzaju. Namiesto centralnej slucky, ktora diktuje dalsi krok, existuje vrstva sprav alebo topicov (Event-Bus). Agenti si predplatia urcite topicy, reaguju na publikovane eventy a sami spustaju nasledne eventy. Stav vyskumu 2026 konstatuje, ze frameworky vseobecne konverguju k spolocnemu primitivu - kombinacii State-Graph a Tool-Calling, ako ju zdielaju LangGraph, Microsoft Agent Framework Workflow a AutoGen Core. Ciste rozdiely v prompt-vzoroch pritom ustupuju do pozadia; rozhodujucou sa stava kvalita middleware, observability a context engineeringu.

Actor-Model ako teoreticky zaklad

Event-driven agenti implementuju Actor-Model znamy z konkurencneho programovania. Aktor je izolovana vypoctova jednotka s tromi vlastnostami:

• Vlastny, zapuzdreny stav - ziadna zdielana pamat medzi aktormi, teda ziadne klasicke race conditions cez spolocne premenne.
• Komunikacia len prostrednictvom sprav - aktor spracuva prichadzajuce spravy typicky jednu po druhej zo svojej mailboxky.
• Dynamika za behu - aktor moze zmenit svoj stav, vytvorit novych aktorov a posielat dalsie spravy.

V AutoGen v0.4 sa to odraza v abstrakcii RoutedAgent a v Pub/Sub-Topic vrstve. Oficialna dokumentacia AutoGen popisuje napriklad vzor Reflection ako dvoch RoutedAgents, ktori komunikuju cez Pub/Sub-topicy - CoderAgent a ReviewerAgent, ktori iteruju az do konvergencie alebo sa zastavia pri limite max_iterations. Prave tato logika topic-routingu je prechodom od pevne zadratovanej slucky k udalostami riadenej vazbe: o tom, ktory agent bude aktivny ako dalsi, nerozhoduje centralny controller, ale publikovany event a predplatne topicov.

AutoGen v0.4, AG2 a kontext Microsoftu

Dolezite pre DACH rozhodovatelov, ktori hodnotia Microsoft-stack: AutoGen je podla stavu research 2026 oficialne v maintenance rezime. Microsoft skonsolidoval AutoGen a Semantic Kernel do Microsoft Agent Framework a smeruje nove projekty tam - migration guide (from-autogen) je smerodajnou referenciou pre existujucich pouzivatelov AutoGen. Agent Framework navyse zavadza SPAR-cyklus (Sense -> Plan -> Act -> Reflect) ako produktizovanu variantu kombinovaneho vzoru ReAct plus reflexia.

Paralelne existuje AG2 ako komunitou riadene pokracovanie linie AutoGen. Kto dnes stavia event-driven architekturu na baze tejto myslienky, vybera teda prakticky medzi tromi moznostami: existujuci AutoGen v0.4 (funkcny, ale uz len udrziavany), komunitou nesene AG2 alebo Microsoftom odporucany Agent Framework pre nove projekty v podnikovom prostredi.

Kedy udalostami riadeny pristup skaluje lepsie

Udalostami riadeny pristup sa neoplati vzdy. Tri podmienky hovoria v jeho prospech:

1. Volna vazba - agenti maju byt nezavisle nasaditelni, zamenitelni a jednotlivo skalovatelni. Prieskumny agent moze byt znovu nasadeny bez toho, aby sa dotkol zapisujuceho agenta.
2. Paralelizmus - viacero ciastkovych uloh bezi sucasne. Zistenia Cognition z „Don't Build Multi-Agents" (jun 2025) a „Multi-Agents: What's Actually Working" (april 2026) su tu centralnym vodidlom: multi-agent setupy funguju pre citajuce, paralelne zhromazdovanie informacii, zatial co zapisujuce zmeny stavu by mali zostat single-threaded. Devin na to vyuziva manager-Devina, ktory cez interny MCP vytvara child-Devinov. Prelozene pre klientov agentury: jeden silny agent s toolmi ako standard, paralelni sub-agenti len na zhromazdovanie informacii, nikdy nie na zapisove operacie alebo zmeny stavu.
3. Dlhe behy - procesy trvajuce minuty alebo hodiny, s cakanim na externe API, batch-systemy alebo ludi (Human-in-the-Loop). Synchronna slucka by tu blokovala; event-driven system jednoducho caka na dalsi event.

Vyhody a nevyhody oproti orchestrovanym sluckam

Najvacsou slabinou je pozorovatelnost. Pri ReAct-slucke je uplny Thought/Action/Observation-trace k dispozicii linearne a je priamo auditovatelny - realna vyhoda pre regulovane DACH odvetvia. V event-driven modeli je tok riadenia rozlozeny cez mnoho aktorov; chyby sa mozu sirit a bez staroslivého tracingu sa analyza pricin stava tazkou. Observability nastroje ako LangSmith, Langfuse alebo Arize Phoenix su preto fakticky povinnostou. Pre DSGVO a EU AI Act musia byt distribuovane event-trace bez medzier, korelovane a zbavene PII perzistované.

Konkretny priklad: paralelny prieskum trhu

Marketingova agentura ma pre B2B klienta vytvorit konkurencnu analyzu: pat konkurentov, kazdy tri zdroje dat (web, tlacove spravy, social media). V ReAct-slucke by to bezalo prisne za sebou: 5 × 3 = 15 sekvencnych tool-krokov. Pri predpokladanych 8 sekundach na krok (cas odpovede LLM plus toolu) by to dalo zhruba 120 sekund celkovej latencie - a kazdy krok navyse opatovne plati cely kontextovy prefix.

Udalostami riadene to vyzera takto (pseudo-priebeh):

```
Event: AnalyzaSpustena(konkurenti=[A,B,C,D,E])
-> Orchestrator publikuje 5 eventov "AnalyzujKonkurenta"
-> 5 ResearchAgentov reaguje PARALELNE, kazdy 3 zdroje
-> kazdy publikuje "CiastkovyVysledokHotovy"
-> AggregatorAgent si predplati "CiastkovyVysledokHotovy"
-> pri 5/5 ciastkovych vysledkoch publikuje "SpravaPripravena"
-> WriterAgent (single-threaded!) vytvori finalnu spravu
```

Pat prieskumnych aktorov bezi sucasne; cas na stene klesa zhruba na trvanie najpomalsej vetvy (≈ 3 × 8 = 24 sekund) plus agregacia - namiesto 120 sekund seriovo. Rozhodujuce podla principu Cognition: citajuce prieskumne kroky su paralelizovane, zapisujuca finalna sprava zostava single-threaded pri jedinom WriterAgentovi. Tak nevznikaju protichodne zapisove rozhodnutia. Dolezite: tu uvedene sekundove hodnoty su ilustrativne orientacne cisla; realne cisla silno zavisia od modelu, latencie toolu a siete a mali by sa merat na vlastnej zatazi.

Pre agentury a B2B rozhodovatelov

Event-driven agenti nie su samoucelom. Zacnite podla v praxi potvrdenej zasady s najjednoduchsim vzorom, ktory funguje - vacsinou ReAct-sluckou - a eskalujte k udalostami riadenym multi-aktorovym architekturam az vtedy, ked to ospravedlnuju namerane poziadavky (paralelizmus, dlhe behy, volna vazba). Pre marketingove agentury je typickym sweet spotom paralelne, citajuce zhromazdovanie informacii s jednym single-threaded zapisovym krokom na konci. Kto hodnoti Microsoft-stack, mal by v roku 2026 zvolit Microsoft Agent Framework namiesto AutoGen nachadzajuceho sa v maintenance rezime; AG2 je komunitou riadenou alternativou. Blck Alpaca podporuje DACH podniky pri vybere vhodneho architektonickeho vzoru, pri nastaveni observability pre sulad s DSGVO a EU AI Act a pri skalovani agentnych workflowov mernym, nie pocitom riadenym sposobom.