Orchestrácia AI agentov: dokumentácia pre code agenta

Orchestrácia AI agentov znamená, že jedno komplexné workflow koordinuje viac špecializovaných agentov namiesto jedného univerzálneho modelu. Scenár, v ktorom jeden agent generuje štruktúrovanú dokumentáciu repozitára a druhý, code agent, ju používa na navigáciu v kóde, zapadá do bežných návrhových vzorov: prvý agent vyrobí artefakt^?Štruktúrovaný výstup jedného agenta (súbor, JSON, Markdown), ktorý iný agent používa ako vstup v ďalšom kroku. a druhý ho berie ako vstup do ďalšieho kroku. Treba povedať rovno, že ide o ilustratívny use-case postavený na aktuálnych vzoroch, nie o verejne zdokumentovaný nasadený produkt.

Pýtam sa na to z praktického dôvodu. Code agent, ktorý sa má orientovať vo veľkom repozitári, naráža na ten istý problém ako človek v prvý deň v projekte: nevie, kde čo je. A hádzať mu do kontextu celý kód je drahé aj nespoľahlivé.

Čo je orchestrácia AI agentov a prečo dvojica agentov namiesto jedného?

Orchestrácia AI agentov je koordinácia viacerých agentov s úzkymi rolami cez definované rozhrania. OpenAI vo svojej dokumentácii k agentom odporúča začať jedným agentom a pridávať špecialistov len vtedy, keď zlepšia izoláciu schopností, politík, promptov alebo trasovateľnosť. Dvojica má zmysel presne tam, kde sú úlohy rôzne: písanie dokumentácie a hľadanie v nej.

OpenAI rozlišuje dva vzory. Pri handoff^?Vzor, keď špecializovaný agent prevezme zodpovednosť za odpoveď, lebo má vlastniť ďalší krok konverzácie alebo úlohy. špecializovaný agent prevezme odpoveď, keď má vlastniť ďalší krok. Pri agents as tools ostáva hlavný manažérsky agent zodpovedný za finálny výstup a volá špecialistov ako obmedzené schopnosti, napríklad sumarizáciu alebo klasifikáciu.

• Documentation agent: prechádza repozitár, extrahuje štruktúru API, sumarizuje moduly a produkuje artefakt (JSON alebo Markdown).
• Code agent: berie tento artefakt ako mapu a podľa nej sa rozhoduje, ktoré súbory vôbec otvoriť.

Ako presne dokáže code agent ťažiť z generovanej dokumentácie?

Podstatná je deľba práce cez artefakt. Podľa sprievodcu multiagentovými systémami pre rok 2026 jeden agent produkuje Artifact, teda súbor alebo štruktúrované dáta, a druhý agent ho berie ako vstup v ďalšom kroku workflow. Code agent tak nemusí čítať celý repozitár; číta jeho mapu.

V praxi to vyzerá takto. Documentation agent raz za čas prejde kód a vyprodukuje index: aký modul za čo zodpovedá, kde sú vstupné body, aké kontrakty majú funkcie. Code agent pri konkrétnej úlohe najprv siahne do tohto indexu, zúži okruh súborov a až potom otvára samotný kód. Šetrí sa tak kontextové okno^?Maximálny objem textu, ktorý model spracuje naraz; jeho zaplnenie zvyšuje náklady aj chybovosť. aj peniaze za tokeny.

Riziko je zrejmé: ak documentation agent zosumarizuje kód nesprávne, code agent zdedí chybu a hľadá na nesprávnom mieste. Preto by mal byť artefakt verzovaný a viazaný na commit, z ktorého vznikol. Zastaraná mapa je horšia než žiadna.

Kedy má takáto orchestrácia zmysel v produkcii a kedy nie?

Má zmysel pri veľkých repozitároch s desiatkami modulov, kde je samotná orientácia drahá. Nemá zmysel pri malom projekte, kde sa všetko zmestí do kontextu jedného modelu. OpenAI aj Azure sa zhodujú na tom istom princípe: pridaj agenta len vtedy, keď rieši konkrétny problém, nie preto, že sa dá.

Ak zvažujete presun podobnej architektúry z prototypu do reálnej prevádzky, oplatí sa najprv poriadne premyslieť, ako budete artefakty verzovať, logovať handoffy a testovať nedeterministické výstupy. Práve tejto disciplíne, teda RAG, správe kontextu a architektúram agentov pre produkčné projekty, sa venuje dvojdňový workshop o produkčnej AI pre CTO a architektov. Nie je pre tímy, ktoré ešte len skúšajú prvý prompt; je pre tých, čo už majú prototyp a potrebujú z neho spoľahlivú prevádzku.

Podobný odklon medzi prototypom a produkciou opisujem aj v texte o tom, prečo pri AI projektoch sľubovaná úspora času často nepríde. Krásna architektúra na papieri a stabilná architektúra pod záťažou sú dve rôzne veci.

Čo rozhoduje o spoľahlivosti multiagentového nasadenia?

Nie počet agentov, ale prevádzkové základy. Microsoft Azure Architecture Center vo svojich vzoroch pre multiagentovú orchestráciu odporúča logovať všetky handoffy a operácie, sledovať výkon a spotrebu zdrojov každého agenta a písať integračné testy pre celé workflow. Pri nedeterministických výstupoch navrhuje namiesto presnej zhody používať scoring rubrics alebo model ako sudcu.

Sprievodca pre rok 2026 dopĺňa bezpečnostnú vrstvu, ktorú by som z produkcie nikdy nevynechal:

• Sandboxing^?Spúšťanie agenta v izolovanom prostredí, aby jeho kód nemohol zasiahnuť zvyšok systému.: agent, ktorý spúšťa kód, beží v izolovanom prostredí.
• Least privilege^?Princíp minimálnych oprávnení: agent má prístup len k nástrojom a dátam, ktoré nevyhnutne potrebuje.: každý agent má prístup len k nevyhnutným nástrojom a dátam.
• Audit trail^?Kompletné logovanie komunikácie a odovzdávania artefaktov medzi agentmi na spätné dohľadanie chýb.: kompletné logovanie komunikácie a odovzdávania artefaktov medzi agentmi.

K tomu praktický sprievodca od Netwrk pridáva monitoring, health-checky, alerting a retry logiku pri zlyhaní agenta. Ide o princípy klasických distribuovaných systémov. AI na nich nič nemení; len pridáva ďalší zdroj chýb.

Čo si z toho odniesť pri rozhodovaní?

Dvojica documentation agent a code agent je rozumný vzor tam, kde orientácia v kóde stojí veľa tokenov aj času. Postavte to konzervatívne: documentation agent nech vyrába verzovaný artefakt viazaný na commit, code agent nech z neho číta a nech nemá právo nič sám zapisovať bez potvrdenia. Definujte úzke roly a jasný výstupný kontrakt každého agenta, presne ako radí OpenAI.

Odporúčanie je triezve. Pri malom projekte stačí jeden dobrý agent. Ak máte veľký repozitár a tím, ktorý sa v ňom sám ťažko orientuje, orchestrácia dvoch agentov sa oplatí, ale len s audit trailom, monitoringom a retry logikou od prvého dňa. Bez nich si do produkcie púšťate systém, ktorý zlyhá potichu a vy sa to dozviete neskoro.