AI agenti se posouvají od krátkých odpovědí k práci, která může trvat hodiny nebo dny. Vyšetřování výpadku, řešení požadavku zákaznické podpory nebo kontrola finančních podkladů už nejsou jen otázkou schopností modelu. Stejně důležité je prostředí, ve kterém agent pracuje, dostupné nástroje a infrastruktura, která udrží celý úkol v chodu.
OpenAI na DevDay 2026 představuje Agents API jako spravovanou službu postavenou na infrastruktuře Codexu. Vývojář určuje instrukce, nástroje, data i pracovní prostředí. Provozní vrstvu, která řídí práci agenta, zajišťuje OpenAI. Součástí oznámení je také ovládání grafického rozhraní počítače prostřednictvím API v prostředích hostovaných OpenAI.
Za nejpodstatnější na tomto přístupu považuji oddělení dvou rozhodnutí: chtít kontrolovat způsob práce agenta neznamená chtít provozovat veškerou jeho infrastrukturu. Právě na tomto rozdílu stojí nabídka označovaná jako „harness jako služba“. Praktický význam ukazuje aplikace pro přesouvání cestujících ze zrušeného letu, v níž agenti hledají možnosti, ověřují omezení a připravují návrhy ke schválení člověkem.
Obsah
- 🧩 Od volání modelu ke kompletnímu pracovnímu systému
- 🏗️ Jak do sebe zapadají Responses API, Codex a Agents API
- 🤝 Kontrola nad agentem nemusí znamenat vlastní provoz všeho
- 🖥️ První výzva: oddělit agenta od počítače, na kterém pracuje
- 🔎 Druhá výzva: ukázat průběh práce, který nelze předem nakreslit
- ⏳ Třetí výzva: udržet práci přes kontextová okna i výpadky
- 🔄 Proč chybějící odpověď neznamená neprovedenou akci
- ✈️ Zrušený let jako zkouška skutečného pracovního procesu
- 🛠️ Jak je rezervační agent sestavený
- 👥 Dva podagenti a tři soubory pro kontrolovatelný výsledek
- ✅ Co agenti doporučili a co naopak vyřadili
- 🌐 Nasazení v Notionu, dlouhé úkoly a syntetická publika
- 🚀 Co z toho vyplývá pro návrh vlastních agentních aplikací
🧩 Od volání modelu ke kompletnímu pracovnímu systému
Pojem harness označuje softwarovou vrstvu kolem modelu, která mu umožňuje soustavně pracovat. Nejde jen o odeslání zadání a přijetí odpovědi. Tato vrstva zajišťuje používání nástrojů, práci s prostředím, návaznost jednotlivých kroků a pokračování úkolu i ve chvíli, kdy se jeho průběh zkomplikuje.
S rostoucími schopnostmi modelů roste význam právě tohoto zázemí. Pokud agent dokončí úkol za několik sekund, může být jeho obsluha poměrně jednoduchá. Jestliže ale několik hodin prochází soubory, spouští příkazy, čeká na výsledky a mění postup podle nových zjištění, vzniká podstatně náročnější systém.
Charlie z týmu Developer Experience a Steve z týmu API popisují posun od rozhraní nad inferenčním systémem k provozování celého agentního mechanismu jako služby. OpenAI podle jejich prezentace používá agenty napříč firmou, od vývoje přes finance až po marketing. Zkušenosti z těchto nasazení se mají promítat do společné infrastruktury.
Vnímám zde důležitou změnu těžiště vývoje. Samotný model je nadále zásadní, ale výsledný produkt závisí také na tom, zda agent dostane správné nástroje, zda jeho činnost zůstane srozumitelná a zda nepřijde o rozpracovanou práci při výpadku serveru.
Agents API proto není prezentováno pouze jako další způsob komunikace s modelem. Má vývojářům nabídnout provozní základ pro agenty, kteří skutečně vykonávají delší a složitější práci. Tým se pak může více věnovat konkrétnímu obchodnímu procesu místo opakovaného budování stejného technického zázemí.
🏗️ Jak do sebe zapadají Responses API, Codex a Agents API
Nová služba navazuje na několik předchozích kroků. Assistants API zkoumalo možnost hostovaných pracovních postupů s nástroji, jako jsou vyhledávání v souborech a spouštění kódu. Tehdejší modely však podle Steva zvládaly především kratší pracovní sekvence. GPT-4 Turbo v roce 2023 představovalo jinou úroveň možností než modely popisované na DevDay 2026.
Responses API, uvedené v roce 2025, řešilo základnější potřebu: umožnit posílat modelu různé typy obsahu a získávat různorodé výstupy. Tato flexibilita vytvořila podklad pro další agentní produkty, včetně Codexu a ChatGPT Work.
Jednotlivé vrstvy si vykládám následovně:
- Responses API poskytuje základní rozhraní pro komunikaci s modelem a budování agentních systémů.
- Codex nad tímto základem přidává pracovní schopnosti, například úpravy kódu, prezentací nebo používání prohlížeče.
- Agents API zpřístupňuje spravovanou infrastrukturu pro vlastní agentní produkty, aniž by si tým musel celý mechanismus provozovat sám.
Vedle toho existuje Agents SDK, které OpenAI uvedlo v roce 2025 pro týmy budující vlastní lokální agentní infrastrukturu. Tato cesta dává smysl tam, kde je prioritou přímá kontrola nad jejím provozem.
Nejde tedy o tvrzení, že předchozí rozhraní přestávají být použitelná. I aplikaci podobnou představenému rezervačnímu systému lze sestavit nad Responses API. Rozdíl spočívá v množství podpůrného softwaru, které musí vývojář navrhnout, otestovat a dlouhodobě udržovat. Agents API přesouvá část této odpovědnosti na poskytovatele služby.
🤝 Kontrola nad agentem nemusí znamenat vlastní provoz všeho
Steve popisuje opakující se rozhovory s vývojovými týmy. Ty často přesně věděly, jaký produkt chtějí vytvořit a kde by jim agent pomohl. Méně jasné už bylo, jaké nástroje zvolit, kam umístit běhové prostředí, zda má agent pracovat uvnitř sandboxu a jak spravovat přístupové údaje.
OpenAI původně předpokládalo, že si značná část vývojářů bude chtít infrastrukturu sestavit sama. Zájem ale směřoval také k doporučenému řešení a k možnosti nechat si je rovnou provozovat. Vlastní představa o datech a nástrojích totiž automaticky neznamená chuť spravovat celou agentní platformu.
Právě zde vidím hlavní produktovou myšlenku Agents API. Vývojář si zachovává rozhodování o tom, co je pro jeho aplikaci specifické:
- Jaké zadání a pravidla agent dostane.
- S jakými daty smí pracovat.
- Které nástroje může používat.
- V jakém prostředí se mají provádět jeho příkazy.
- Které kroky vyžadují zásah nebo souhlas člověka.
OpenAI naopak přebírá provoz harnessu a souvisejících služeb. Součástí přínosu mají být i průběžná vylepšení vznikající při vývoji Codexu a dalších agentních produktů. Každý tým tak nemusí samostatně napodobovat všechny změny v řízení dlouhých úloh.
Tento model ale neodstraňuje potřebu pečlivého návrhu aplikace. Pravidla rezervací, oprávnění nástrojů nebo okamžik finálního schválení stále vycházejí z konkrétního produktu. Spravovaná služba má převzít společnou technickou složitost, nikoli rozhodovat místo vývojáře o smyslu a hranicích jeho pracovního procesu.
🖥️ První výzva: oddělit agenta od počítače, na kterém pracuje
Codex původně vycházel z přirozeného předpokladu, že běží lokálně na počítači uživatele. Mohl přečíst soubor, změnit jej a bezprostředně zkontrolovat výsledek. Přesun řídicí vrstvy do cloudu tento jednoduchý vztah narušuje.
Vývojář může chtít používat vlastní sandbox, prostředí jiného poskytovatele nebo prostředí provozované OpenAI. Harness proto musí být oddělený od místa, kde se skutečně vykonávají příkazy. Agent může být řízen cloudovou službou, zatímco jeho pracovní soubory a nástroje se nacházejí jinde.
Na příkazu pro vypsání obsahu adresáře je dobře vidět, co takové rozdělení znamená. Služba musí najít prostředí přiřazené ke správné relaci, doručit mu příkaz a vrátit výsledek modelu. Teprve potom může agent rozhodnout o dalším kroku.
Při větším počtu současných relací je navíc nutné udržet příkazy a výsledky důsledně oddělené. Operace, která byla na lokálním počítači přímočará, se stává součástí distribuovaného systému. Rychlost komunikace i správné směrování ovlivňují celý pracovní postup.
Za důležitou vlastnost proto považuji možnost ponechat si vlastní pracovní prostředí a přesto využívat spravovaný harness. Není nutné chápat službu jako jediný uzavřený balík, do kterého se musí přesunout úplně všechno.
Nově oznámené ovládání počítače přes API tuto nabídku rozšiřuje. Model Astra má v prostředích hostovaných OpenAI používat také grafické uživatelské rozhraní. Vedle práce v terminálu se tak otevírá další způsob, jak může agent vykonávat úkoly. Oznámení se však konkrétně týká prostředí hostovaných OpenAI, nikoli obecného příslibu stejné funkce v libovolném vlastním sandboxu.
🔎 Druhá výzva: ukázat průběh práce, který nelze předem nakreslit
Dlouhá úloha potřebuje srozumitelné uživatelské rozhraní. Agent přitom nepostupuje vždy po stejné trase. Podle zadání a výsledků nástrojů může otevřít jiné soubory, změnit strategii nebo předat dílčí práci dalšímu agentovi.
Uživatel přesto potřebuje vědět, na čem systém právě pracuje, zda se posouvá kupředu a jestli nepotřebuje pomoc. Nestačí mu pouze čekat na závěrečnou odpověď. Zvlášť u úkolů trvajících několik minut či hodin se průběžný přehled stává součástí použitelnosti produktu.
OpenAI původně předpokládalo, že vývojářům postačí surová volání nástrojů a odpovědi modelu. Zkušenost jednoho interního týmu ukázala, že chybí ještě struktura. Jeho aplikace obsahovala několik kol komunikace: uživatel zadal práci, získal odpověď a později přišel s dalším požadavkem.
Tým potřeboval přiřadit nástroje a výstupy ke konkrétním kolům této výměny. Bez odpovídajících informací v API by si musel vztahy rekonstruovat sám. Tím by znovu vytvářel část infrastruktury, kterou chtěl přenechat službě.
Rozhraní proto začalo zpřístupňovat informace o jednotlivých kolech. Vývojář může rozhodnout, jak práci zobrazí, aniž by musel od začátku odvozovat strukturu celé konverzace.
Já v tomto detailu vidím výstižný příklad rozdílu mezi technicky dostupnými daty a skutečně použitelným API. Transparentnost není jen proud událostí, ale také jejich srozumitelné uspořádání. Spravovaná infrastruktura přináší větší hodnotu tehdy, když nevrací složitost zadními dveřmi do uživatelského rozhraní aplikace.
⏳ Třetí výzva: udržet práci přes kontextová okna i výpadky
Dlouhodobá činnost agenta naráží na dva odlišné limity. První souvisí s množstvím informací, které model dokáže současně zpracovat. Druhý s životností serverů a spolehlivostí služeb, na nichž celý proces závisí.
Historie se nevejde do jednoho kontextu
Každý další krok přidává do historie nové instrukce, výsledky nástrojů a zjištění. Nakonec může tato historie přesáhnout kontextové okno modelu, přestože samotná práce ještě neskončila.
Řešením je kompakce, tedy zhušťování kontextu při zachování užitečných informací pro další postup. Harness má přenášet podstatné poznatky do pokračování úlohy, aby agent mohl pracovat i napříč více kontextovými okny. Bez této podpory by si vlastní strategii správy historie musel navrhovat každý vývojář.
Server není stejně dlouhověký jako úkol
Agent může pracovat celé hodiny, ale během této doby se nasazuje nový kód, vyměňují servery nebo dochází k poruchám. Vedle toho přicházejí nové pokyny uživatele a výsledky nástrojů z jiných počítačů. Služba je musí doručit ke správné relaci.
Za zásadní považuji požadavek pokračovat po přerušení bez ztráty dosavadní práce. Pokud agent hodinu vyšetřoval problém, prosté zahájení od začátku není rovnocenná náhrada. A pokud už provedl nějaké změny, opakování může být vyloženě nežádoucí.
Steve zmiňuje také cíl spolehlivosti na úrovni 99,9 %. Nejde o vlastnost jediného serveru. Do výsledku vstupují modelová inference, úložiště, nástroje a další služby. Každá z těchto závislostí musí odpovídat požadované úrovni nebo ji překonávat.
Agents API má tuto koordinaci převzít: přesně evidovat stav, vhodně obměňovat servery a obnovovat rozpracované relace. Právě zde leží velká část práce, která v jednoduché ukázce volání modelu není vidět.
🔄 Proč chybějící odpověď neznamená neprovedenou akci
Nejnázornější technický příklad se týká úpravy souboru. Harness odešle do pracovního prostředí příkaz, ale spojení se přeruší dřív, než dorazí výsledek. V tu chvíli není jasné, zda se soubor změnil.
Pokud služba příkaz bez dalšího zopakuje, může nechtěně provést stejnou operaci podruhé. Pokud naopak bude předpokládat, že změna proběhla, může pokračovat z nesprávného stavu. Samotná absence odpovědi nerozhoduje ani jednu z těchto možností.
Tento případ podle mě nejlépe vysvětluje, proč provoz agentů není pouze smyčka nad modelem a nástroji. Je nutné sladit skutečný stav pracovního prostředí s tím, co má zaznamenáno řídicí infrastruktura. Teprve potom lze bezpečně pokračovat.
V prezentaci nejsou rozebrány konkrétní interní mechanismy tohoto sladění. Není proto namístě domýšlet přesné garance pro každý nástroj nebo typ operace. Podstatné je, že OpenAI problém výslovně zahrnuje do odpovědnosti spravované služby.
Pro návrh produktu z toho vyvozuji praktickou otázku: které akce jsou jen přípravné a které už mají závazný účinek? Rozdíl se následně objevuje i v rezervační ukázce. Vyhledání možností, dočasné podržení míst a konečné potvrzení rezervace nejsou zaměnitelné kroky. Aplikace je musí umět rozlišovat nejen v rozhraní, ale také ve svém pracovním postupu.
✈️ Zrušený let jako zkouška skutečného pracovního procesu
Praktická demonstrace začíná zrušením letu AL204 ze San Franciska do Chicaga. Pro jednotlivého cestujícího jde o hledání náhradního spojení. Pro leteckou společnost to znamená desítky až stovky rezervací, často s různými požadavky a výjimkami.
Charlie vybírá dva obtížnější případy. Erin potřebuje dorazit výhradně na letiště O’Hare a preferuje odlet následující ráno. Druhá rezervace patří Avě a zahrnuje čtyři cestující včetně dětí. Skupina musí být přesunuta společně a splnit požadavek na společné sezení.
Pro každý případ vzniká samostatná relace Agents API. Obě mohou pracovat na pozadí souběžně, zatímco aplikace zobrazuje jejich aktivitu. Nejde tedy o jedinou konverzaci, ve které by jeden agent postupně řešil všechny cestující.
Na tomto příkladu oceňuji, že úspěch není definován pouhým nalezením letu do správného města. Agent musí respektovat konkrétní omezení, porovnat možnosti a dodat podklady pro lidské rozhodnutí.
- U Erin je určující konkrétní cílové letiště.
- U Aviny rezervace musí nabídka vyhovět všem čtyřem cestujícím.
- Dostatečný celkový počet míst ještě neznamená splnění požadavku na sezení pohromadě.
- Konečné přebookování zůstává podmíněné schválením člověka.
Takový pracovní proces dobře ukazuje smysl agentní aplikace. Nejde jen o generování doporučujícího textu. Systém sbírá data nástroji, pracuje s pravidly, provádí dílčí kontroly a vrací výsledek, na který může navázat odpovědná osoba. Každý případ má přitom vlastní průběh i důvody pro doporučení.
🛠️ Jak je rezervační agent sestavený
Základní stavební jednotkou Agents API je relace. V ukázce její vytvoření v JavaScriptu zabírá méně než tucet řádků. Samotný krátký zápis ale nepředstavuje celou aplikaci. Důležité jsou také instrukce, připojené schopnosti, nástroje a pravidla schvalování.
Pracovní prostředí tvoří sandbox hostovaný OpenAI. Přístup k síti je obecně vypnutý a relace průběžně odesílá události, aby aplikace mohla živě aktualizovat rozhraní. Alternativou zůstává vlastní sandbox nebo prostředí třetí strany.
Agent dostává také dovednost pro přebookování letu. Ta popisuje přesný postup, kterým má při řešení rezervace procházet. Je načtena z místního souboru, vložena do pracovního prostoru a zpřístupněna prostřednictvím pole capability_directories.
Tato konfigurace může odkazovat nejen na dovednosti, ale také na pluginy včetně serverů MCP. Kdo potřebuje širší souvislosti tohoto způsobu připojování nástrojů, najde je v dokumentaci protokolu MCP. V konkrétní aplikaci je ovšem stále rozhodující, které schopnosti vývojář skutečně povolí.
Klíčovým nástrojem je vyhledávání dostupných míst na letech. Jeho výsledky mají poradní charakter a pracovní postup může zahrnovat dočasné podržení míst. Závazné potvrzení rezervace však vyžaduje člověka.
Za užitečné považuji propojení několika vrstev: obecná infrastruktura řídí relaci, specializovaná dovednost popisuje postup a konkrétní nástroj dodává informace o letech. Obchodní pravidla tak nejsou ponechána pouze na obecném zadání typu „najdi nejlepší řešení“. Agent dostává vymezený pracovní rámec, podle kterého lze jeho výstup následně kontrolovat.
👥 Dva podagenti a tři soubory pro kontrolovatelný výsledek
Hlavní agent nemá návrh publikovat okamžitě po nalezení slibného spojení. Instrukce mu ukládají předat kontrolu sezení a kontrolu příletu dvěma podagentům. Na oba výsledky musí počkat.
Pro tuto spolupráci je zapnutý režim více agentů. Maximální počet souběžných podagentů je nastavitelný podle toho, kolik nezávislé práce aplikace potřebuje provádět. Vyšší souběžnost ale podle prezentace pravděpodobně znamená také vyšší spotřebu tokenů.
Já bych proto paralelismus neposuzoval jen podle rychlosti. Smysl má tam, kde jednotlivé větve opravdu přispívají k výsledku. V tomto případě mají jasně oddělené úkoly a hlavní agent jejich dokončení vyžaduje před odevzdáním návrhu.
Vedle doporučení má relace vytvořit tři výstupní soubory:
- Soubor JSON s konečným návrhem, který zachycuje doporučené řešení.
- Soubor JSON s porovnávanými možnostmi, který uchovává podklady pro výběr a vyřazení alternativ.
- Pythonový skript pro kontrolu omezení, který umožňuje deterministicky ověřit logiku vůči zadaným podmínkám.
Význam těchto artefaktů přesahuje pohodlné stažení souborů. Návrh lze zpracovat jako strukturovaná data, porovnání pomáhá vysvětlit rozhodnutí a kontrolní skript vytváří další způsob ověření. Obecné informace k používanému datovému formátu nabízí také český přehled formátu JSON.
Generované vysvětlení a programová kontrola zde plní odlišné role. Jedno objasňuje doporučení člověku, druhé má ověřovat konkrétní podmínky. Ani tato kombinace však v ukázce nenahrazuje konečné lidské schválení rezervace.
✅ Co agenti doporučili a co naopak vyřadili
U Erin přehled aktivity ukazuje práci se sandboxem, kontrolu dostupnosti letů a zapojení dvou podagentů. Výsledkem je doporučení konkrétního spojení doplněné vysvětlením a dočasně podrženými místy. Teprve následné schválení dokončuje přebookování.
U Aviny čtyřčlenné skupiny je zvlášť důležité zdůvodnění odmítnutých alternativ. Let AL314 měl pouze jedno dostupné místo, a proto pro celou rezervaci nevyhovoval. Let AL744 sice nabízel čtyři místa, ale nebylo možné zaručit společné sezení. Ani tato možnost tedy nesplnila požadavky.
Právě druhé zamítnutí považuji za důležitý detail. Jednoduchá kontrola počtu míst by mohla skončit kladným výsledkem. Skutečné zadání však obsahovalo další podmínku. Agent měl najít použitelnou náhradu pro konkrétní skupinu, nikoli jen kapacitně dostačující let.
V pracovním prostoru jsou dostupné provedené kontroly a mezi soubory se objevuje konečný návrh, porovnání možností i ověřovací skript. Aplikace tak nespoléhá pouze na krátké závěrečné doporučení.
Rozdělení odpovědnosti zůstává čitelné:
- Agent vyhledá a porovná možnosti.
- Pomocné kontroly prověří důležitá omezení.
- Aplikace ukáže doporučení a jeho podklady.
- Člověk rozhodne o závazném potvrzení.
Ukázka řeší jen dvě rezervace, ale jeden zrušený let může vyvolat mnoho podobných případů současně. Přínos paralelních relací proto nespočívá jen v rychlejší obsluze jedné skupiny. Umožňuje rozpracovat více nezávislých případů a současně ponechat finální rozhodnutí pod lidskou kontrolou.
🌐 Nasazení v Notionu, dlouhé úkoly a syntetická publika
OpenAI uvádí také několik příkladů využití mimo leteckou demonstraci. V Notionu se Agents API propojuje s externími agenty, kterým mohou týmy zadat práci a nechat ji asynchronně dokončit. Uživatel tedy nemusí po celou dobu udržovat nepřerušenou interakci.
Rockton podle prezentace začleňuje Agents API do produktů pro dlouhotrvající úlohy. Důležitá je možnost práci zadat a později se vrátit s dalším směrováním nebo zpětnou vazbou. To odpovídá požadavku, aby relace dokázala přijímat nové pokyny i během delšího běhu.
Bain službu používá při tvorbě syntetických publik pro klienty. Jde o virtuální diskusní skupiny tvořené AI simulacemi zákazníků, které vycházejí ze skutečného zákaznického výzkumu. Mají poskytovat zpětnou vazbu k produktům, reklamám nebo dotazníkům. Výsledky nadále kontrolují lidští odborníci.
Zde bych rozlišoval mezi užitečným podpůrným nástrojem a náhradou reálných zákazníků. Představený příklad zdůrazňuje oporu ve výzkumu a lidskou kontrolu, nikoli neomezenou vypovídací hodnotu simulací.
Pro týmy orientované na AWS zaznívá také nabídka Bedrock Managed Agents poháněných OpenAI. Podle oznámení využívá jádro Agents API upravené a hlouběji integrované do prostředí AWS. Obecný kontext této platformy poskytuje oficiální přehled Amazon Bedrock.
Společným jmenovatelem těchto nasazení je práce, která nekončí jednou okamžitou odpovědí. Agent přijímá úkol, postupně jej zpracovává a zůstává součástí procesu, do něhož se člověk může znovu zapojit.
🚀 Co z toho vyplývá pro návrh vlastních agentních aplikací
Hlavní praktický přínos Agents API vidím v přesunu pozornosti. Místo opakovaného řešení obnovy relací, správy kontextu a směrování vzdálených příkazů může vývojář věnovat více času pravidlům aplikace. V rezervačním systému jde například o podmínky cestujících, význam jednotlivých kontrol a okamžik, kdy musí rozhodnout člověk.
Při posuzování podobného produktu bych si položil několik otázek:
- Je úkol dostatečně dlouhý nebo proměnlivý? Právě zde se projeví hodnota správy stavu a průběžného přehledu.
- Potřebuji vlastní prostředí? Volba sandboxu je oddělená od rozhodnutí provozovat celý harness.
- Co má člověk vidět během práce? Rozhraní potřebuje smysluplně uspořádané události, ne jen závěrečný text.
- Které podmínky lze ověřit programově? Strukturované výstupy a kontrolní skripty mohou doplnit slovní zdůvodnění.
- Které akce nesmějí proběhnout bez souhlasu? Hranice mezi návrhem a závazným krokem musí být zřetelná.
- Kde dává smysl souběžná práce? Více agentů může rozšířit kapacitu, ale přináší i vyšší spotřebu.
Závěrečná ambice oznámení sahá dál než k pohodlnějšímu provozu jednotlivých úloh. Pokud lze práci bezpečně rozdělit, stovky či tisíce agentů mohou současně prověřovat mikroslužby, zpracovávat rozsáhlé softwarové projekty nebo zkoumat různé přístupy k výzkumné otázce. Jde o naznačené možnosti, nikoli o doložený výsledek každého takového nasazení.
Za rozhodující změnu považuji to, že velikost dostupné infrastruktury nemusí tak těsně určovat velikost produktové ambice. Agents API má umožnit stavět nad schopnostmi agentů, aniž by každý tým nejprve musel vybudovat jejich provozní platformu. Kvalita výsledku ale dál stojí na dobře vymezeném úkolu, vhodných nástrojích, kontrolovatelných výstupech a jasné lidské odpovědnosti.
