Vývoj AI agentů se posouvá od jednoduchého opakování příkazů k systémům, které dokážou samostatně pokračovat v práci, kontrolovat výsledky a rozdělovat úkoly mezi další agenty. Za nejdůležitější změnu ale nepovažuji samotný počet zapojených modelů. Podstatné je, jak dobře celý systém rozumí cíli, uchovává potřebný kontext a pozná, že je skutečně hotovo.
Prezentace na DevDay 2026 tento posun popisuje prostřednictvím architektury Codexu, dlouhodobých úloh a koordinace více agentů. Vedle praktických doporučení přináší také ambiciózní tvrzení o rozsáhlých matematických experimentech. U těch rozlišuji mezi tím, co OpenAI prezentuje, a tím, co lze považovat za nezávisle ověřený vědecký výsledek.
Hlavní zpráva pro každodenní práci je přitom překvapivě střídmá: začít jedním agentem, jasným zadáním a způsobem ověření výsledku. Složitější tým má smysl až tehdy, když pro něj existuje konkrétní důvod. Právě tato jednoduchá zásada propojuje celý příběh od prvního vygenerovaného programu až po koordinaci tisíců spolupracujících procesů.
Obsah
- 🧩 Od vygenerovaného kódu k samostatnému jednání
- 🛠️ Proč agent potřebuje víc než dobrý model
- 🔄 Responses API jako součást pracovního cyklu
- 🧠 Kompakce kontextu otevírá cestu k delším úlohám
- 🎯 Proč nestačí agentovi opakovat, aby pokračoval
- 🚀 Vytrvalost se přesouvá přímo do modelu
- 👤 Jeden agent je často nejlepší výchozí bod
- ⚖️ Škálování úsilí a výběr vhodného modelu
- 🤝 Dvojice agentů pro vzájemně propojené úkoly
- 🗂️ Správce konverzací a dlouhodobé pracovní proudy
- 🚧 Daň za příliš mnoho řízení
- 📝 Stručný pracovní záznam pomáhá udržet směr
- 🌐 Co se mění při koordinaci deseti tisíc agentů
- 🔬 Stabilní cíl, proměnlivé rozdělení práce
- ✅ Co si odnáším pro návrh vlastních AI agentů
🧩 Od vygenerovaného kódu k samostatnému jednání
Rozdíl mezi chatbotem a agentem dobře vystihuje obyčejný programátorský úkol FizzBuzz. V raném způsobu práce s ChatGPT model napsal kód, ale člověk jej musel přenést do vývojového prostředí, spustit a posoudit výsledek. Inteligentní část systému poskytovala odpověď. Všechny praktické kroky kolem ní zůstávaly na uživateli.
Raj Bhatek tento příklad používá jako výchozí bod pro vysvětlení zásadní změny. Jakmile model získá nástroje, nemusí pouze doporučovat další postup. Může jej také provést, prozkoumat výsledek a rozhodnout, zda pokračovat stejným směrem, nebo zkusit něco jiného.
Podobný princip ukazuje práce modelu o3 s obrazem. Model může vybranou část přiblížit, prozkoumat detaily a na základě získaných informací zvolit další krok. Důležité není samotné přiblížení obrázku, ale propojení uvažování s konkrétní akcí.
Agentní smyčku si proto vykládám jako opakování čtyř navazujících činností:
- Vyhodnotit aktuální stav a požadovaný výsledek.
- Vybrat vhodný nástroj a provést akci.
- Zpracovat výsledek této akce.
- Rozhodnout, co má následovat.
U programování se tak odpovědnost posouvá od napsání návrhu ke splnění celého úkolu. Agent kód vytvoří, spustí, zkontroluje výstup a případnou chybu opraví. Právě uzavření tohoto cyklu považuji za skutečný začátek agentní architektury.
🛠️ Proč agent potřebuje víc než dobrý model
Codex je v prezentaci popsaný jako spojení modelu a jeho řídicího prostředí, označovaného anglickým slovem harness. Nejde jen o obal kolem jazykového modelu. Toto prostředí určuje, jaké instrukce model dostane, jaké nástroje může používat, co právě vidí a kde se jeho akce skutečně vykonají.
Součástí jeho práce je také správa kontextu. Musí rozhodovat, které informace přenést do dalšího kroku, jak zacházet s výsledky nástrojů a kdy umožnit agentovi pokračovat. Samotná schopnost modelu rozumně odpovědět tedy ještě nezaručuje spolehlivé dokončení úlohy.
Zaujala mě zejména obousměrná vazba mezi návrhem prostředí a tréninkem. Zkušenosti z provozu ukazují, co je potřeba model naučit. Nové schopnosti modelu zase umožňují prostředí zjednodušit nebo změnit. Architektura a trénink se nevyvíjejí odděleně.
Codex podle tohoto přístupu dostává poměrně obecné nástroje, například přístup k příkazové řádce a souborovému systému. Ambicí není připravit zvláštní funkci pro každý možný úkol. Model má umět obecné prostředky kombinovat podle situace.
Praktická otázka proto nezní jen „jaký model použiji“, ale také „v jakém prostředí mu dovolím pracovat“. Rozhoduje dostupnost nástrojů, kvalita zpětné vazby i způsob předávání výsledků. Otevřený vývojový projekt lze prozkoumat v repozitáři Codexu.
🔄 Responses API jako součást pracovního cyklu
V popsané architektuře stojí uprostřed pracovního cyklu Responses API. Model obdrží definice dostupných nástrojů a může požádat o jejich použití. Řídicí prostředí následně zajistí vykonání požadavku v izolovaném prostředí, převezme výsledek a přidá jej do konverzačního kontextu.
Tady považuji za důležité oddělit rozhodování od vykonání. Model navrhuje nebo vyžaduje akci, ale okolní systém zajišťuje její provedení. Výsledek pak vytváří další podklad pro rozhodování. Agent tedy nepracuje v abstraktním prostoru odpovědí, nýbrž v prostředí, které mu průběžně vrací konkrétní důkazy o tom, co se stalo.
Řídicí vrstva současně posuzuje, zda má následovat další krok, nebo zda lze tah ukončit. To může působit jako technický detail, ale při delších úlohách právě toto rozhodnutí určuje, jestli systém úkol dokončí, nebo pouze vytvoří přesvědčivě působící průběžnou zprávu.
Pro návrh vlastních agentů si z toho odnáším jednoduché rozdělení odpovědností:
- Model: volí postup a interpretuje získané informace.
- Nástroje: umožňují zasáhnout do pracovního prostředí.
- Řídicí vrstva: spravuje vykonání, kontext a pokračování práce.
- Zpětná vazba: poskytuje podklady pro kontrolu a opravy.
Čím delší a méně předvídatelný úkol je, tím méně dává smysl hodnotit tyto části izolovaně. Spolehlivost vzniká až jejich souhrou.
🧠 Kompakce kontextu otevírá cestu k delším úlohám
Každý agent během práce vytváří historii. Čte soubory, spouští nástroje, získává chybová hlášení a upravuje plán. Kontextové okno však není neomezené. Dříve nebo později přestane být možné držet celou pracovní historii před modelem najednou.
Řešením popsaným v prezentaci je kompakce kontextu. Když se prostor zaplní, systém prostřednictvím Responses API požádá o zhuštění dosavadní historie do podoby, ze které lze pokračovat. Nejde tedy jen o prodloužení konverzace, ale o udržení pracovního stavu při omezené kapacitě.
Podstatnou součástí přístupu je podle Bhateka také trénink modelu. Model má rozumět tomu, že pracuje s kompaktním stavem, a umět na něj navázat. Kompakce není pouze dodatečně připojená technická pomůcka. Je součástí způsobu, jakým se agent učí dlouhodobě fungovat.
Tento princip mi připadá důležitější než prosté porovnávání velikostí kontextových oken. Větší okno poskytne více prostoru, ale samo o sobě neřeší, jak oddělit zásadní rozhodnutí od přechodných podrobností.
Kvalitní pokračování potřebuje zachovat především cíl, relevantní zjištění, rozpracované části a důvody dosavadních rozhodnutí. Naopak není nutné stále nést každý výpis nástroje. Kompakce tak umožňuje práci přes více kontextových oken, aniž by agent musel pokaždé začínat od nuly.
🎯 Proč nestačí agentovi opakovat, aby pokračoval
Možnost pracovat déle ještě automaticky neznamená ochotu úkol dokončit. Starší modely podle prezentace často udělaly významný pokrok, ale svůj tah ukončily příliš brzy. Uživatel pak musel znovu a znovu zadávat pokyn k pokračování.
Právě z této zkušenosti vyrostlo navrhování vnějších smyček. Bhatek připomíná opakované pobízení, které používal Peter Steinberger, i přístup známý jako Ralphova smyčka, popularizovaný Geoffreym Huntleym. Agent opakovaně pracuje podle zadání, přičemž nový běh může začít s čerstvým kontextem a navázat na soubory z předchozího pokusu.
Takový mechanismus má jasnou výhodu: udržuje práci v chodu. Současně ale přesouvá důležitá rozhodnutí do vnějšího systému. Někdo musí určit, zda nastal pokrok, zda má další pokus smysl a kdy už je potřeba skončit.
Codex tento princip podle prezentace převzal prostřednictvím funkce goal, spojované s GPT 5.5. Cíl se ukládá mimo běžné kontextové okno, aby se při kompakci neztratil. Řídicí prostředí sleduje jeho stav a kontroluje, zda agent opravdu dokončil práci.
Za klíčové považuji, že takto uložený cíl může přežít nejen zhuštění kontextu, ale i konec jednotlivého tahu. Agent zároveň může oznámit skutečnou překážku. Vytrvalost nemá znamenat nekonečné opakování, ale pokračování až do dokončení nebo do rozpoznání reálného blokujícího problému.
🚀 Vytrvalost se přesouvá přímo do modelu
Další krok prezentace popisuje jako přesun vytrvalosti z vnějšího mechanismu do samotného modelu. U GPT 5.6 má být pokračování v užitečné práci, kontrola výsledků a zvládání neúspěšných pokusů součástí naučeného chování. Neustálé pobízení zvenčí pak ztrácí část svého významu.
Jako ilustrace zaznívají zkušenosti Tobiho Lütkeho ze Shopify a Ethana Mollicka z Whartonu. Mollickův příklad se týká několika hodin hraní Slay the Spire 2 prostřednictvím počítače. Beru jej jako ukázku dlouhodobého jednání v proměnlivém prostředí, nikoli jako samostatný důkaz spolehlivosti ve všech typech úloh.
U řady GPT 6 prezentace zdůrazňuje další posun: modely mají zvládat nejen dlouhou individuální práci, ale také koordinaci a spolupráci. Tím se otevírá otázka, kdy úkol rozdělit a jak spojit dílčí výsledky.
Z tohoto vývoje si neodnáším závěr, že všechny vnější mechanismy přestávají být užitečné. Spíše se mění jejich role. Část podpůrné logiky může nahradit schopnější model, zatímco jasné cíle, kontrola výsledků a správa pracovního stavu zůstávají důležité.
To má bezprostřední důsledek pro vývojáře: postup, který byl nutný u jedné generace modelu, může být u další zbytečnou komplikací. Starou architekturu je proto vhodné znovu posoudit, ne ji automaticky přenášet dál.
👤 Jeden agent je často nejlepší výchozí bod
Eric v praktické části doporučuje odolat pokušení sestavit tým hned na začátku. Pro mnoho úloh stačí jeden agent, který dostane srozumitelné zadání a způsob, jak svou práci ověřit. Schopnost samostatně pokračovat a pracovat s kompakcí výrazně rozšiřuje rozsah toho, co takový agent zvládne.
Tohle doporučení považuji za nejpoužitelnější pravidlo celé prezentace. Více agentů totiž automaticky neznamená vyšší rychlost ani lepší výsledek. Každý další agent spotřebovává tokeny a přináší nároky na komunikaci a integraci.
Rozdělení práce dává smysl zejména tehdy, když jsou části skutečně oddělitelné. Kontrola pěti žádostí o začlenění změn do kódu nabízí přirozených pět pracovních jednotek. Každou lze přidělit samostatnému podagentovi.
Jiný případ představuje obtížná chyba způsobená souběhem operací. Tam může být užitečné rozdělit vyšetřování mezi několik agentů, kteří prozkoumají odlišné hypotézy. Přínosem není prosté násobení úsilí, ale více nezávislých směrů pátrání.
Před přidáním dalšího agenta si proto kladu tři otázky:
- Existuje pro něj jasně vymezená část práce?
- Může postupovat bez neustálého čekání na ostatní?
- Je zřejmé, kdo převezme a propojí jeho výsledek?
Pokud odpovědi chybějí, složitější uspořádání pravděpodobně řeší spíše organizační představu než skutečnou potřebu úkolu.
⚖️ Škálování úsilí a výběr vhodného modelu
V režimu označeném jako Ultra má Codex podle prezentace vytvářet další spolupracující instance podle potřeby. Vedle samotného počtu agentů se však otevírá také otázka, jak náročný model a jakou míru uvažování přidělit jednotlivým částem práce.
Eric tento princip představuje jako škálování úsilí. Místo ručního rozhodování při každém kroku lze agentovi dát pravidla, kdy přizvat silnější model a kdy jednodušší podpůrnou práci delegovat jinam.
Ukázková dovednost Coordinate pracuje s následujícím rozdělením:
- Sol Medium zajišťuje hlavní práci a drží odpovědnost za integraci.
- Astra High poskytuje pomoc při obtížném problému, například při opakovaném selhávání testu.
- Luna High přebírá jednodušší podpůrné úkoly.
Smyslem není vytvořit pevnou hierarchii prestiže jednotlivých modelů. Jde o přidělení odpovídajícího úsilí problému. Hlavní agent nemusí sám spotřebovávat nejvyšší dostupnou kapacitu na každou drobnost, zároveň ale může požádat o pomoc tam, kde jeho vlastní postup nestačí.
Za důležité upozornění považuji absenci záruky úspory. Ani silnější model nemusí správně odhadnout, která varianta úkol vyřeší nejlevněji. Škálování úsilí tedy může zjednodušit rozhodování a někdy snížit náklady, ale samo o sobě nepředstavuje univerzální cenovou optimalizaci.
🤝 Dvojice agentů pro vzájemně propojené úkoly
Ne každou práci lze rozdělit na nezávislé balíčky. Někdy se dvě části potřebují průběžně ovlivňovat. Pro takovou situaci Eric popisuje uspořádání dvojice agentů, které vyzkoušel při převodu starší hry do novějšího pracovního prostředí.
K dispozici měl projektové soubory a spustitelnou hru, ale původní herní engine už nemohl dohledat. Cílem bylo zachytit běžící scénu a znovu ji sestavit v Blenderu, aby mohl pokračovat v jiném enginu.
Jeden agent řešil technologii získávání dat z původní hry. Druhý rozbalování a vizualizaci scény ve formátu použitelném v Blenderu. Právě formát však mohl ovlivnit způsob zachytávání dat, takže izolovaná práce bez průběžné komunikace by nebyla vhodná.
Na tomto příkladu oceňuji rozdíl mezi paralelním vykonáváním a skutečnou spoluprací. Dva agenti nejsou užiteční jen proto, že pracují současně. Přínos vzniká tím, že jeden může své řešení upravit podle zjištění druhého.
Současně je potřeba přesně vymezit komunikační hranice a odpovědnosti. Prezentace neposkytuje univerzální recept pro každý projekt, ale ukazuje konkrétní důvod pro použití dvojice: dvě odborné části mají vlastní práci a zároveň sdílené rozhraní, které se během řešení vyvíjí. Kontext k možnostem cílového prostředí nabízí oficiální příručka Blenderu.
🗂️ Správce konverzací a dlouhodobé pracovní proudy
Vedle podagentů prezentace rozlišuje samostatné konverzace. Codex má v popsaném prostředí aplikace ChatGPT umět zakládat nová vlákna, posílat jim zprávy a usměrňovat jejich práci. Každé takové vlákno přitom může používat vlastní podagenty.
Rozdíl považuji za zásadní. Podagent pomáhá s částí konkrétního úkolu, zatímco samostatná konverzace může představovat déle žijící pracovní proud. Nad nimi pak může fungovat správce, který přijímá celkový cíl a koordinuje jednotlivé aktivity.
Praktickým příkladem je fronta žádostí o kontrolu změn v kódu. Správce založí pro každou samostatnou konverzaci. Člověk může do některé vstoupit a upravit zadání, aniž by musel osobně řídit veškerou souběžnou práci.
U dlouhodobého herního projektu lze podobně oddělit výtvarnou stránku, návrh hry, programování a testování. Jednotlivá vlákna se postupně specializují. Koordinující producent přebírá celkové pokyny, zatímco další agenti řeší své oblasti.
Tento způsob práce mi připadá užitečný zejména tam, kde projekt trvá měsíce a člověk se potřebuje podle situace ponořit do konkrétního tématu. Není však prezentovaný jako nejúspornější varianta z hlediska tokenů. Jeho výhodou je spíše přehlednost a možnost spojit dlouhodobou specializaci s průběžným lidským vedením.
🚧 Daň za příliš mnoho řízení
S rostoucím počtem agentů se objevuje problém, který dobře znají i lidské organizace: více pravidel může znamenat méně skutečné práce. Eric pro tento jev používá označení daň středního managementu.
Každá nová schvalovací úroveň nebo komunikační povinnost vytváří další příležitost k čekání. Agenti mohou začít vyhledávat souhlas v hierarchii, kterou návrhář systému vytvořil, přestože by samotný úkol nevyžadoval tak složité řízení.
Za varovný signál považuji situaci, kdy je obtížnější vysvětlit organizaci týmu než jeho očekávaný výsledek. Pokud velká část instrukcí popisuje, kdo musí komu napsat a kdo smí co schválit, stojí za to ověřit, zda tato struktura opravdu odstraňuje konkrétní problém.
Praktické poučení zní střídmě:
- Přidávat role kvůli potřebám práce, nikoli kvůli elegantnímu organizačnímu schématu.
- Udržovat srozumitelnou odpovědnost za konečný výsledek.
- Omezovat schvalovací kroky, které nepřinášejí užitečnou kontrolu.
- Průběžně posuzovat, zda koordinace nepohlcuje přínos souběžné práce.
Nejlepší víceagentní architektura nemusí být ta nejpropracovanější. Často jde o nejjednodušší uspořádání, které ještě umožňuje potřebnou nezávislost, komunikaci a ověření výsledků. Složitost by měla být odpovědí na pozorovaný problém, nikoli výchozím předpokladem.
📝 Stručný pracovní záznam pomáhá udržet směr
Dlouhodobá práce má ještě jednu slabinu: zadání se během ní mění. Uživatel doplňuje podrobnosti, zpřesňuje požadavky a upozorňuje na věci, které v úvodním pokynu chyběly. Po několika kompakcích pak může agent ztratit vztah mezi novými připomínkami a původním cílem.
Eric doporučuje vést stručný pracovní záznam. Ten nemá fungovat jako nekonečný deník všech příkazů a neúspěšných testů. Má zachytit to, co je potřebné pro správné pokračování.
Za užitečné jádro takového záznamu považuji:
- Celkový cíl: jaký výsledek má práce přinést.
- Aktivní práci: co právě probíhá a co zůstává otevřené.
- Poslední upřesnění: jak nový pokyn mění nebo doplňuje dosavadní postup.
- Důležitá omezení: podmínky, které nesmějí zmizet při dalším zhuštění kontextu.
Hodnota spočívá právě ve stručnosti. Příliš rozsáhlý záznam by znovu vytvořil problém, který měl řešit. Agent potřebuje přehled pracovního stavu, nikoli archiv každé jednotlivosti.
Tento postup zároveň nevyžaduje, aby člověk předem dokonale formuloval celé zadání. Umožňuje přirozeně přidávat nové informace, ale dává jim trvalejší místo v pracovním procesu. Kompakce a pracovní záznam se tak doplňují: první uvolňuje prostor, druhý pomáhá udržovat směr.
🌐 Co se mění při koordinaci deseti tisíc agentů
Závěrečná část prezentace přechází od běžných projektů k rozsáhlému výzkumu. OpenAI v ní uvádí experiment spojený s Navierovými a Stokesovými rovnicemi, při němž mělo spolupracovat přibližně 10 000 agentů. Celkové úsilí mělo zahrnovat 2,7 milionu zpráv a přibližně 130 miliard výstupních tokenů.
Tato čísla uvádím jako tvrzení prezentace. Stejnou opatrnost zachovávám u prohlášení o nalezení řešení a o více než stovce vyřešených dlouhodobých matematických problémů. Samotné vystoupení nenahrazuje zveřejněné důkazy ani nezávislé odborné posouzení. Vymezení miléniového problému nabízí Clay Mathematics Institute; tento odkaz nepotvrzuje prezentovaný výsledek.
Z architektonického hlediska je zajímavé především uspořádání týmů. Několik skupin dostává odlišné formulace problému a podněty k různým přístupům. Každá má vlastní podagenty, ale zároveň může sdílet poznatky s ostatními.
Cílem je spojit dvě potřeby, které se snadno dostanou do konfliktu: hluboké soustředění na jednu hypotézu a dostatečně široké hledání alternativ. Pokud by všichni agenti opakovali stejný postup, rozsah systému by pouze násobil náklady.
Komunikace proto slouží také k omezení duplicitní práce. Týmy mají vědět, co zkoumají ostatní, předávat si důležitá zjištění a klást otázky. Současně si mají udržovat vlastní výzkumný směr, aby spolupráce nesmazala užitečnou rozmanitost.
🔬 Stabilní cíl, proměnlivé rozdělení práce
Rozsáhlý výzkumný tým podle popsaného přístupu nemá zůstat organizačně zamrzlý. Nová zjištění mohou vytvořit nové otázky, a tím i důvod založit další skupinu nebo přesunout pozornost jinam.
Některé týmy mohou rozvíjet hypotézu, jiné zpochybňovat předpoklady a další provádět experimenty. Rozdělení práce se mění podle toho, co se podaří zjistit. Společný cíl však zůstává stabilní.
Bhatek v této souvislosti zmiňuje výsledek týkající se Eulerových rovnic bez vnějšího buzení, po němž měly být týmy přesměrovány k nadějnému směru. Bez podrobné publikace z toho nevyvozuji matematické závěry. Architektonické poučení je ale srozumitelné: koordinace musí umět reagovat na důkazy, ne pouze vykonávat původní plán.
Právě zde vidím rozdíl mezi velkým počtem agentů a fungujícím výzkumným systémem. Nestačí rozeslat stejný úkol mnoha kopiím modelu. Je potřeba udržovat přehled o rozpracovaných směrech, podporovat jejich odlišnost a rozpoznat okamžik, kdy má smysl úsilí soustředit.
V menším měřítku se tento princip vrací i do běžného vývoje softwaru. Původní rozdělení úkolů nemusí zůstat správné po objevení zásadní chyby nebo omezení. Plán může být proměnlivý, aniž by se měnil požadovaný výsledek.
✅ Co si odnáším pro návrh vlastních AI agentů
Nejpraktičtější závěr není výzva k budování co největších týmů. Je to doporučení znovu prozkoumat problémy, které dřívější modely nezvládaly, a použít nejjednodušší architekturu odpovídající jejich náročnosti.
Pro vlastní postup si z prezentace skládám následující pořadí:
- Vymezit výsledek. Agent musí vědět, co má vzniknout a jak lze poznat dokončení.
- Připravit ověření. Testy, kontrola výstupu nebo jiná zpětná vazba mají být součástí práce.
- Začít jedním agentem. Nejprve ověřit, zda úkol vůbec potřebuje složitější koordinaci.
- Udržovat pracovní stav. Využít kompakci a stručný záznam cíle, otevřené práce a upřesnění.
- Delegovat konkrétní části. Další agent má dostat jasný důvod existence a srozumitelnou odpovědnost.
- Hlídát režii. Porovnávat přínos spolupráce s náklady na tokeny, komunikaci a integraci.
- Pravidelně postup přehodnocovat. Novější model může odstranit potřebu části dosavadních mechanismů.
Celá cesta od ručního přenášení FizzBuzzu k týmům agentů ukazuje, že pokrok nespočívá jen v lepších odpovědích. Spočívá ve schopnosti převzít souvislou práci, ověřovat ji a udržet směr i během změn.
Za nejcennější doporučení proto považuji otevřenost vůči změně vlastních pracovních postupů. Osvědčená metoda má svou dobu použitelnosti. Dobrý návrh agentní architektury by měl využívat současné schopnosti modelů, nikoli navždy konzervovat jejich někdejší omezení.
Zdroj prezentovaných informací: Co přichází po smyčkách: hlubší pohled na agentní architekturu, DevDay 2026.
