Nejcennější aktivum vaší firmy ve světě AI je definice toho, co je dobře.

Na začátku to byl jednoznačně prompt. Umění se zeptat. Vznikla kolem toho celá "profese" a existovaly propracované sady pravidel, které jsme si všichni předávali - formulovat pozitivně a ne negacemi, na konec zopakovat to nejdůležitější, dát pár příkladů, přinutit model k postupnému uvažování větou "let's think step by step", oddělovat sekce, strukturovat vstup.

A tehdy to fakt fungovalo. Rozdíl mezi dobrým a špatným promptem byl rozdíl mezi použitelným a nepoužitelným výstupem.

Mediální vrchol byl někdy na jaře 2023, kdy Anthropic inzeroval pozici "Prompt Engineer and Librarian" s kompenzací až 335 000 dolarů ročně. Zajímavé ale je, že to nikdy nebyl skutečný trh - analýza inzerátů na LinkedIn našla pouhých 72 prompt-engineer pozic z 20 662, tedy nějakých 0,35 %. Bublina, která se ve skutečnosti nikdy nenafoukla. Jen se o ní hodně psalo.

Nebylo by ale fér říct, že prompt engineering umřel - jen se rozdělil na dvě části a ta mechanická zmizela v modelu samotném a jeho rozvinutých schopnostech uvažování. OpenAI dnes u reasoning modelů přímo doporučuje "Avoid chain-of-thought prompts" a "Try zero shot first" (reasoning best practices), protože model si uvažování udělá sám a vaše berlička ho spíš rozhodí. Anthropic naopak dodnes tvrdí, že příklady jsou "one of the most reliable ways" jak model řídit. Není to černobílé, záleží na modelové rodině a na úloze.

Ale ta obsahová část - co vlastně chci - je najednou důležitější než forma. A to je celá pointa.

Jakmile přestalo záležet na formulaci, přesunula se pozornost o patro výš. Co dostane model do kontextového okna? Jaká data, jaké texty, jak je připravit, jak chunkovat, jak rerankovat. Postavil jsem na tomhle tématu celou sérii o RAG a byla to opravdu věda.

Termín zviralizoval Tobi Lütke 19. 6. 2025 definicí "the art of providing all the context for the task to be plausibly solvable by the LLM" (zdroj). O šest dní později to Andrej Karpathy rozšířil na "the delicate art and science of filling the context window with just the right information for the next step" (zdroj). Anthropic to pak 29. 9. 2025 zformalizoval jako strategie pro kurátorství a udržování optimální sady tokenů během inference, včetně promptu, nástrojů, MCP, historie, paměti i externích dat.

Všimněte si toho posunu. Přestali jsme ladit otázku a začali ladit to, co je v zorném poli modelu (context window). Pořád jsme ale byli my ti, kdo to zorné pole staví.

V podobné době přišly nástroje a s nimi agentické chování. Agent se může rozhodnout, že si něco dotáhne. Zeptá se ve stávajících systémech, napíše si query do databáze, přečte si soubor, zkusí to znovu jinak. A iteruje.

Tím se ta pečlivá příprava kontextu částečně rozpustila. Nemusíme už tak úzkostlivě řešit, jak vybrat těch správných pět odstavců, protože si je agent najde sám.

RAG sice už není pupek světa, ale je stále zásadním prostředkem optimalizace nákladů, rychlosti a kvality odpovědí. Anthropic sice ukázal, že jejich multi-agent Research systém překonal single-agent Claude Opus 4 v interním evalu o 90,2 %, ale spotřeboval při tom zhruba patnáctkrát víc tokenů než běžný chat. Microsoft svůj Agentic Retrieval popisuje explicitně jako věc určenou pro RAG patterny, ne jako jejich náhradu. Dobře připravený kontext pořád zvyšuje spolehlivost a snižuje náklady. Jen už není podmínkou, aby to vůbec fungovalo.

A pak přišlo to, co mě baví nejvíc - agent si začal psát poznámky pro svou pozdější práci. Anthropic vydal Agent Skills 16. 10. 2025 a memory tool 29. 9. 2025, formát skillů se pak 18. 12. 2025 stal otevřeným standardem.

Když se agent natrápí přes tři slepé uličky, než najde správný způsob dotazu do databáze, umí to dneska zobecnit a uložit jako skill. Procedurální paměť. Přemýšlecí cache. To už není retrieval, to je začátek učení. Psal jsem o tom podrobněji v článku o software jako paměti, kde si můj domácí agent sám napsal CLI a okomentoval si ho ve skillu.

Jednotka práce v software se za tři roky posunula tak, že se to skoro nedá srovnat. Psal jsem o tom podrobněji v samostatném článku, takže tady jen zkratka:

Podstatné je, že neubývalo práce, ubývalo "jak". Na první příčce jsem musel vědět úplně přesně, co má být na dalším řádku. Na třetí už jenom to, co má být na konci hotové.

Na té třetí příčce se poprvé objevila zpětná vazba. Agent si spustí testy, uvidí červenou a jde to opravit. To je zárodek celé zbývající části tohohle článku - jen se posuneme o jednu vrstvu smyček nahoru.

Když jednotka zadání dorostla do "úlohy", vznikl nový problém. Agent teď pracuje hodinu bez mého dohledu. Chat, ve kterém jsem mu to řekl, je nespolehlivý, zapomíná se, nikdo si ho nepřečte podruhé. Potřeboval jsem trvanlivý artefakt.

Tak vznikl spec-driven development. AWS uvedl Kiro 14. 7. 2025, GitHub vydal Spec Kit 2. 9. 2025 s cyklem Specify → Plan → Tasks → Implement. Specifikace jako živý zdroj pravdy.

Chci zdůraznit, že to není móda, ale dobrý inženýrský nápad, a to ze tří důvodů:

Ten třetí bod je ten důležitý a málo se o něm mluví. Spec-driven totiž do toho příběhu přinesl nezávislého kontrolora. Jeden agent píše kód podle specifikace, druhý agent nebo člověk nezávisle ověří, že ji dodržel. To je strašně užitečná vlastnost, je to auditní artefakt, a nechci o něj přijít ani v budoucnu.

Jenže. A tady je ta trhlina, kvůli které tenhle článek vlastně píšu.

Matt Shumer zveřejnil 25. 7. 2026 post se slovy "Claude Opus 5 one-shotted this game" a ukázkou first-person střílečky. Internet se zbláznil. Metodiku pak o dva dny později popsal pod názvem Gauntlet Loop.

Ten prompt stojí za přečtení celý, protože je to hezky čistá esence toho přístupu.

I want you to build a first-person shooter at the level of the most recent
Call of Duty games. It should be utterly perfect, visually beautiful, with
every single thing done at AAA quality—from textures to physics to anything
you could think of.

Fan out sub-agents and have sub-agents tackle each one individually so that
the game is utterly perfect. You should /loop on each item and have a separate
sub-agent check it visually to ensure it looks triple A. That separate
sub-agent should be a really harsh critic, and if it doesn't look triple A,
it should keep going.

Don't stop until each sub-agent is utterly wowed with the quality when compared
with the actual Call of Duty game. It should literally compare them side by
side blind and say which one looks better. Do this in ThreeJS. /loop until it's
utterly perfect. Fan out sub-agents and ultracode.

Podstatné na tom není zadání hry. Podstatné je, že tam vůbec není napsáno, jak to udělat. Je tam napsáno, jak se pozná, že je to hotové: oddělený subagent, nemilosrdný kritik, slepé porovnání vedle sebe se skutečnou hrou, a smyčka běží dál, dokud kritik neřekne dost.

Shumer to o dva dny později upřesnil: "I gave Claude Code one prompt, then left it alone. It spent many hours working, spawned a massive fleet of subagents, wrote roughly 55,000 lines of code... I did not sit there steering it, at all." Jeden prompt, žádné doptávání, mnoho hodin autonomní práce a zhruba 55 tisíc řádků kódu.

Ten kritik navíc neměl referenční bod jen v paměti modelu. Shumer to popsal doslova: "For the game, I used actual Call of Duty screenshots. The critic was supposed to look at the two side by side, decide which was better, and keep going whenever ours lost."

Technicky to fungovalo tak, že Playwright pustil vytvářenou hru v headless Chromiu, odchytil jedenáct předem definovaných pohledů ve full HD - prostředí, světlo, materiály, zbraň v ruce, zaměřování, dopady, HUD - a ty pak šly kritikovi proti skutečným snímkům z Call of Duty. Naslepo, aby nevěděl, který obrázek je čí.

Když si otevřete jeho repozitář, najdete tam něco, co se do virálních postů nedostalo:

"The goal was to match a modern Call of Duty. It does not."

Skóre se během těch smyček posunulo z 3,59 přes 4,14 a 4,05 na konečných 5,05 z deseti - všimněte si, že jedno kolo bylo dokonce horší než předchozí. Dva z jedenácti pohledů se dostaly na hodnocení "CLOSE", zbytek zůstal na "AMATEUR". A ve všech slepých A/B srovnáních vyhrálo skutečné Call of Duty.

Ta smyčka udělala přesně to, k čemu byla postavená. Poctivě změřila, že cíle nedosáhla, a napsala to nahlas. To je mnohem cennější než naleštěná ukázka bez čísla - protože z čísla se dá pokračovat.

A tady je ta nepříjemná zpráva pro vás.

Což znamená, že tu část, kterou Shumer dostal zadarmo, si musíte vyrobit sami. A to je ta nejtěžší práce v celém řetězci.

Ten posun od zadávání práce k navrhování smyček dostal v červnu 2026 i jméno. Addy Osmani ho 7. 6. definoval jako "replacing yourself as the person who prompts the agent. You design the system that does it instead." Peter Steinberger, autor OpenClaw, řekl tentýž den totéž jinak: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

Já si to překládám takhle. Přestal jsem mluvit s agentem a začal jsem mluvit s předákem. Neříkám mu, jak a co má naprogramovat. Říkám mu, čeho chci dosáhnout. Předák si to rozseká na dílčí úlohy, sám napíše specifikace, rozdá práci ostatním agentům a pak je bičuje tak dlouho, dokud výsledek neodpovídá záměru. Já do toho v mezičase nesahám.

Zní to skvěle. Tak jsem si takovou smyčku postavil.

Cílem byl jednodenní workshop na Microsoft Foundry - kombinace krátké prezentace, demo ukázek a krátkých hands-on labů pro účastníky. Měl jsem agendu, měl jsem plán. Vytvořil jsem ekosystém subagentů úplně v Mattově duchu: jeden se na to díval očima pedagoga, druhý očima studenta, třetí očima grafika, čtvrtý očima inženýra. A makali na tom.

O sedmdesát dolarů později mi představili výsledek. Dokonale naleštěné materiály. Krásné, detailní, fakticky naprosto správné, pedagogicky výborně vystavěné.

Nebyl tam žádný Azure.

Já chtěl skutečná dema a skutečné laby, kde si účastník sáhne na reálný zdroj. Oni to pojali jako teoretické cvičení, kde praktičnost spočívala v interaktivních formulářích, ve kterých se krásně skládala AI architektura. Výborné. Ale ne to, co jsem chtěl. Letělo to celé do koše.

Chyba byla samozřejmě u mě. Moje smyčka kontrolovala témata, strukturu, vizuál a pedagogickou návaznost. Nikdy nesáhla na reálný zdroj v Azure. Vybičoval jsem model k dokonalosti v disciplíně, která nebyla pro výsledek to zásadní. Model nemá uvnitř představu, co je výsledek, není to Call of Duty - a moje definice dobrého výsledku byla mizerně připravená.

Představte si, že tyhle principy chcete posunout do lidské práce ve firmě plné unikátních znalostí. Často nevyřčených. Často fungujících jinak, než je napsané - a přitom dobře a flexibilně, protože ta firma prostě funguje.

Pomáhá mi na to koukat přes tři vrstvy:

Michael Polanyi to v roce 1966 shrnul větou, kterou nikdo nepřekonal: "we can know more than we can tell."

Nechci tvrdit, že první vrstva je bezcenná, to by byla hloupost - bez dat nefunguje nic. Chci říct něco jiného: je to jediná vrstva, kterou umíte předat za odpoledne. A co předáte, to se dá zkopírovat.

Pokud výrobci modelu předáte svoje data, aby je použil na trénink, je to výhoda spíš pro něj než pro vás. A pokud mu necháte poslouchat i lidské interakce a ukládat si je k analýze, může odtéct i to nevyřčené. Mít data v cloudu problém není, odevzdat kontrolu nad nimi problém je. Chci v cloudu použít svoji firemní unikátnost k získání AI na míru - ale chci ten výsledek vlastnit.

Zatím to nevnímám jako problém. Trochu se ale obávám doby, kdy někteří výrobci budou v zájmu "bezpečnosti" ten výsledek vlastnit za vás. A za rok bude vaše unikátnost náhodou v nabídce "as a service" pro všechny.

Satya Nadella tomu v textu z 12. 7. 2026 dal jméno: Reverse Information Paradox. Ekonom Kenneth Arrow kdysi popsal, že hodnotu informace kupující nezná, dokud mu ji neodhalíte - jenže jakmile ji odhalíte, má ji zadarmo. AI ten problém podle Nadelly otočila: teď musí svoje know-how odhalit kupující, aby pro něj ta inteligence byla vůbec užitečná. Platíte tedy dvakrát. Jednou penězi, podruhé znalostí. A čím lepší výsledek chcete, tím víc té znalosti musíte dát.

"Models learn from exhaust, the prompts people write, the tools agents use, and especially the corrections people make when the model is wrong. Every correction is distilled into institutional know-how. It's the kind of knowledge a competitor could never buy, and the kind that leaks almost imperceptibly: trace by trace, correction by correction, eval by eval."

Všimněte si toho konce. Trace by trace, correction by correction, eval by eval.

Když víme, že rozhoduje smyčka, a víme, že u firemních věcí nemáme hotovou definici úspěchu, kudy dál? Za mě je odpověď continuous learning, respektive on-the-job learning. Zkušenost nasbíraná při skutečném provádění práce a v interakci s ostatními je pro naprostou většinu ekonomicky důležitých činností nenahraditelná. Pokud má AI opravdu násobit schopnosti lidí, musí se učit i z nejasných signálů.

Microsoft pro to má hezký název. V oznámení nových MAI modelů z 2. 6. 2026 tým píše, že cílem je postavit "what we think of as a hill-climbing machine: an organization that can continuously improve, cycle after cycle" (zdroj).

Z opačného konce to popisuje Thinking Machines Lab: "Most AI in use today is trained in a handful of places and then frozen" (manifest z 10. 7. 2026). Jejich Inkling z 15. 7. 2026 je pro můj argument obzvlášť pěkný - je to ukázka modelu, který si sám připraví evaly, nasbírá data a přes Tinker se dotrénuje. Řízený experiment, ne magie, ale směr je jasný.

Kde reálně jsme dnes? Za mě ve čtyřech vrstvách, které se překrývají:

Ta třetí vrstva je dneska nejzajímavější prakticky, protože si takového pracanta můžete vychovávat. Mění si vlastní skilly a učí se od vás. Prakticky to jde třeba přes Microsoft 365 Copilot Cowork, který je od června 2026 v GA a pracuje napříč Outlookem, Teams, Office a SharePointem se schvalováním citlivých akcí.

Čtvrtá vrstva je ta, kvůli které tenhle článek píšu, a věnuju jí celou další kapitolu.

Zajímavý kousek skládačky je ale ve Foundry. Agent Optimizer vezme baseline konfiguraci agenta a eval dataset a automaticky vylepší jeho instrukce, obsah skillů, popisy nástrojů i volbu modelu. A Observability k tomu umí z produkčních traces vyrobit ten eval dataset. Dohromady je to smyčka: reálné běhy → dataset → optimalizace → lepší agent.

Aby se agent mohl učit z práce, musí být její součástí. Ne nástroj, který si otevřu, ale kolega, kterému něco přijde.

Na Buildu 2026 k tomu Microsoft představil novou produktovou kategorii, a to docela explicitně: "Today we are introducing a new category of agents called Autopilots. Autopilots are always-on agents that work autonomously, with their own identity, and act on your behalf." (oznámení). Prvním zástupcem je Microsoft Scout. Copilot sedí vedle vás a čeká, až se ozvete. Autopilot běží, i když u toho nejste. Nejsou to konkurenti, jsou to souběžné kategorie - ale ten směr je podle mě jednoznačný.

Firemně použitelné je to až se správou. Microsoft Agent 365 je od 1. 5. 2026 v GA jako enterprise control plane: registr agentů, lifecycle, přístupy, Purview, Defender, identita v Entra. Licencovaný "agent user" má vlastní mailbox, OneDrive, UPN a dá se zmínit v Teams.

Že to nemusí být jen Microsoft, je snad jasné - Hermes Agent od Nous Research se popisuje jako agent, který "creates skills from experience, improves them during use", OpenClaw používám doma. A není to buď-anebo: tyhle systémy můžou běžet v Azure, napojit se na Microsoft 365 a být spravované přes Agent 365 stejně jako Scout.

Tady je moje hlavní doporučení. Firma by měla systematicky budovat a formalizovat definici toho, co je dobrý výsledek. Evaluations, reward funkce, reward model, testy, akceptační kritéria, user stories - říkejte tomu jakkoli. Podstatné je, že to musí být spustitelné, ne jen napsané.

Nejsem v tom naštěstí sám. Kromě citované Satyovy věty o privátních evalech jako největším IP (celý rozhovor) říká Mustafa Suleyman na MAI keynote něco, co tu myšlenku posouvá ještě dál: "So with us, the RLEs and the models you build inside of them become your moat." (přepis). Tedy že moat tvoří reinforcement learning environments a modely, které v nich vytrénujete. To je hezká gradace - evals jsou první krok, prostředí druhý, vlastní model třetí.

Mimo Microsoft to zní stejně. Greg Brockman už v prosinci 2023 napsal "evals are surprisingly often all you need" (zdroj), Garry Tan z Y Combinatoru v roce 2025 "Evals are emerging as the real moat for AI startups" (zdroj) a Anthropic v Demystifying evals upozorňuje, že jejich "value compounds over the lifecycle of an agent".

Co dobré evals odemknou:

Ta poslední položka je podle mě nejpodceňovanější a Satya na ni míří tím svým testem s modelem A a B. Prostředí se mění technologicky, politicky i strategicky a nebude to jen souboj OpenAI versus Anthropic. xAI se 2. 2. 2026 spojilo se SpaceX a vydalo Grok 4.5. V Evropě je Mistral s open modely pod Apache 2.0. A open source je dnes fakt kvalitní - Kimi K3 se v nezávislém Artificial Analysis indexu drží nad GPT-5.5 i nad Claude Opus 4.8, tedy nad modely, které ještě před dvěma měsíci byly extratřída světa. GLM-5.2 je celkově o kus níž, ale na dlouhých kódovacích úlohách se s touhle třídou měří taky. Jestli to platí i pro vaši úlohu, zjistíte jedině vlastními evaly.

Nejde o to, jestli cloud ano nebo ne. Cloud rozhodně ano. Výnosy z rozsahu jsou v téhle hře naprosto zásadní a netýkají se jen infrastruktury - týkají se hlavně platforem, orchestrace, bezpečnostních a compliance systémů, evaluačních nástrojů a rychlosti, s jakou přibývají nové modely. Tohle si sami doma nepostavíte a nemá myslím smysl se o to pokoušet.

Jde o něco jiného: komu se to učení připíše.

Satya to pojmenoval přesně takhle - firemní stopy z reálné práce mají trénovat "not a generalist model, but... the company veteran agent". A z toho plyne, co po dodavateli chtít: skutečnou hranici důvěry, uvnitř které se vaše data, traces, evals, doladěné váhy a paměť hromadí a zlepšují dohromady. Mluví o ní jako o místě, kde se skládá lidský a token kapitál - a o token kapitálu jsem psal samostatně. Shrnul to jednou větou, kterou bych si dal na zeď:

"In consuming intelligence, you are creating intelligence. And what you create should belong to you."

Ta hranice nevede mezi cloudem a onprem. Vede mezi schopností, kterou si kupuji, a schopností, kterou si vychovávám.

To první je naprosto v pořádku a budu to dělat pořád - když chci Copilota, který rozumí Excelu, nechci ho učit Excel. To druhé je pracant, kterému dáte firemní nástroje, pustíte ho k reálné práci a budete ho učit. Může to být klidně taky od Microsoftu: Copilot Cowork, Scout, nebo vlastnoručně postavené řešení ve Foundry napojené do Microsoft 365 a řízené přes Agent 365. Není to o tom, jestli si to napíšete sami. Je to o tom, jestli si necháte to, co se naučí.

Každá zastávka na té cestě byla chvíli tím nejdůležitějším a pak se vsákla do modelu nebo do nástrojů. Prompt engineering se rozpustil ve schopnostech modelů. Context engineering z velké části převzalo agentické chování. Specifikaci vám dneska napíše agent, když mu popíšete záměr.

Co se nevsakuje, je definice toho, co je dobrý výsledek. Ta se nedá odvodit z veřejných dat, protože je specifická pro vás.

Shumerova smyčka fungovala hlavně proto, že měla zadarmo dokonalý referenční bod. Vaše firma taková není a být nemá - pokud model dokonale zná vaše postupy, jste komodita mířící k nulové marži.

Takže to, že model nezná vaši procedurální a implicitní znalost, není problém k vyřešení. Je to vaše konkurenční výhoda, kterou musíte umět převést do měřitelné podoby, aniž byste ji rozdali.

Další fáze adopce není lepší chatbot, ale digitální pracovník, který se učí z toho, jak jeho práce dopadla. Nejdřív ladění skillů a kontextu, později prostředí a doladěné modely pro konkrétní firemní role.

Obojí ale potřebuje totéž: signál, podle kterého se dá stoupat do kopce. A ten signál si musíte vyrobit sami - a nechat si ho.