Agenti v praxi

Už víte, co je agent. Teď: co udělat před ním, co při něm a co po něm - a kam až se to dá posunout. Pokračování školení Claude pro praxi.

Kde jsme skončili
a kam jdeme

Začneme příběhem, který na konci školení budete umět celý vysvětlit - a doma zopakovat.

Kde skončilo první školení

V posledním modulu Agenti v Claude Code jsme si řekli, co je agent, jak vypadají subagenti, k čemu jsou permission prompty a kdy agenta nepoužívat. Dnes předpokládáme, že tohle znáte - a jdeme o patro výš: jak agenta řídit, jak mu věřit a kam až to jde posunout. Pokud jste z prvního školení prošli jen Level 1, projděte si před startem modul Agenti v Claude Code - dnešek na něm staví.

Jste tu správně, pokud…

• Agenta jste už zkusili - a výsledek vás nepřesvědčil. Dvakrát jiný výstup, napůl hotová práce, a nevíte proč.
• Nevíte, co má být hotové předem, než agenta pustíte na úkol.
• Nevíte, co dělat pak - jak výsledek kontrolovat, kdy zasáhnout, jak z toho udělat opakovatelný postup.
• Chcete automatizovat, ale bojíte se dát agentovi volnost bez dozoru.

Ať pracujete v Claude Code, v Claude.ai nebo v n8n - dnešní principy platí ve všech nástrojích; mapu „kdo jste / kde s agenty pracovat“ dostanete v bloku 3. A odnesete si víc než principy: čtyři artefakty k okamžitému použití - šablonu zadání, checklist před / při / po, tabulku nástrojů a provozní checklist autonomního agenta.

Průběžný příklad: jedna revize, celý příběh

Celým školením poroste jeden reálný úkol: revize rozpracované práce před odevzdáním. Dnes ji celou ukazujeme na kódu - na revizi větve; princip zadání, kontroly a automatizace je ale přenositelný na jakoukoli jinou revizi. Nejdřív ji umíme zadat, pak jí rozumíme zevnitř, pak jí věříme, pak ji zdvojíme - a na konci se spouští sama.

Otázka z publika, která tohle školení zapálila: „Než odevzdám větev, požádám Claude Code o revizi podle instructions.md. Jak to dělat lépe?“ - odpovíme na ni celou, kousek po kousku.

Effort a modely: kolik přemýšlení
úkol potřebuje

První kousek odpovědi na otázku z úvodu: volba modelu a effortu. Je to první rozhodnutí u každého agenta - a nejdražší model na všechno je stejná chyba jako nejlevnější na všechno.

Co je effort

Effort říká modelu, kolik smí přemýšlet, než odpoví - a vedle hloubky uvažování ovlivňuje i to, jak stručně model odpovídá. Víc přemýšlení = lepší výsledek u těžkých úloh, ale víc tokenů (peněz) a víc času. U jednoduchých úloh vyšší effort nepřidá kvalitu - jen cenu a čekání.

Od prvního školení mezitím vyšla nová generace modelů - dnes proto pracujeme s řadou Haiku 4.5, Sonnet 5, Opus 4.8 a Fable 5, ne s verzemi, které jste viděli minule. Dvě praktické poznámky. Effort se nastavuje v Claude Code - příkazem /effort nebo šipkami u /model, ne v modelu samotném. A výchozí je high na Sonnet 5, Opus 4.8 i Fable 5; jakmile ho ale jednou přepnete na xhigh, drží napříč sezeními - proto ho spousta lidí na kódování jede nastálo.

Hlavní graf: stejná přesnost, zlomek tokenů

Intuice říká „chci nejlepší výsledek, vezmu velký model na plný výkon“. Effort ale dovoluje vyměnit velikost modelu za přemýšlení: u dnešní generace menší model (Sonnet 5) na maximálním effortu dorovná přesnost většího (Opus 4.8) - a zvládne to za zlomek tokenů na úlohu. Stejný vzorec Anthropic poprvé vyčíslil loni na podzim u dvojice Opus 4.5 a Sonnet 4.5; čísla pro aktuální generaci ale nikdo oficiálně nezveřejnil, takže graf níž stojí na hodnotách odečtených z grafů v announcementu Sonnet 5:

Orientační data, stav červen–červenec 2026. Čísla SWE-bench Pro jsou měřená na max effortu - běžný provoz na výchozím high bude o něco níž. Zdroje: Anthropic (announcementy Opus 4.5, Sonnet 5, Fable 5; ceník), Artificial Analysis (rychlost a čas, nezávislé měření).

Který model na jakou práci

Předchozí platilo obecně, teď konkrétně. Není to dogma, ale výchozí volba, od které se odpíchnete - řídící otázka zůstává „kolik úsudku úloha potřebuje“. Sonnet 5 je dnešní tahoun (rychlý, levný, na vyšším effortu blízko Opusu), Opus 4.8 si nechte na nejtěžší úsudek, Haiku 4.5 na objem bez přemýšlení.

Orientační výchozí volby, ne měřená pravda pro každý případ - hlavní páka je effort podle úlohy, model až druhá.

Lokální modely: agent nemusí jet jen proti cloudu

Jak na to prakticky: Claude Code umí jet proti lokálnímu modelu přes kompatibilní endpoint/router - je to ale neoficiální cesta, kterou Anthropic nepodporuje ani negarantuje. OpenCode má lokální modely (Ollama) zabudované. A platí to i pro orchestraci: AgentBoard (blok 5) umí pipeline pustit proti Ollamě, takže celá orchestrace běží bez jediného tokenu v cloudu.

Jiný model na radu, jiný na revizi

Otázka z publika: „Když si nechám poradit od Claudea, mám pak na revizi použít jiný model, nebo jinou AI?“ Odpověď: ano, pomáhá to. Model, který text napsal, sdílí s revizí stejné slepé skvrny - co přehlédl při psaní, přehlédne i při kontrole. Nezávislý pohled (jiný model, jiný effort, klidně jiný dodavatel) snižuje slepotu vůči vlastní práci. Není to dogma - i revize stejným modelem v čerstvém kontextu odhalí hodně - ale u důležitých výstupů se druhý pár očí vyplatí.

Průběžný příklad: na revizi před odevzdáním chci silný model a vyšší effort - je to úsudek, ne mechanika. A radit si nechám od jiného modelu, než který bude revidovat.

Co před agentem:
zmapuj, vyber, zadej

Model a effort máme vybrané - teď co agentovi dát za práci. Agent nemůže automatizovat proces, který nemá tvar: většina zklamání z agentů nevzniká při běhu, ale před ním.

Nejdřív zmapovat proces

Než napíšete první písmeno zadání, odpovězte si na tři otázky. Písemně - když to nejde napsat, není co delegovat.

Který proces svěřit agentovi první

Nejčastější důvod, proč lidi s agenty skončí: vyberou si špatný první proces, spálí se a už se nevrátí. Vybírejte podle čtyř kritérií:

Ideální první proces: častý, snadno ověřitelný, s levnou chybou a jasným „hotovo“. Revize před odevzdáním tohle splňuje celé - proto je naším průběžným příkladem.

Zadání, které agent zvládne

Z prvního školení znáte čtyři elementy promptu (role, kontext, úkol, formát). Zadání pro agenta přidává dvě věci navíc: definici hotovo (podle čeho agent i vy poznáte, že je konec) a hranice (co agent nesmí - měnit git, sahat na produkci, posílat cokoli ven).

A rozlišujte dvě vrstvy: CLAUDE.md je trvalý briefing projektu (konvence, kontext, pravidla - píše se jednou, platí pořád), instructions.md je jednorázové zadání konkrétního úkolu. Co platí vždy, patří do CLAUDE.md; do zadání jen to, co je dnes jinak.

Případová studie: revize před odevzdáním

Otázka z úvodu, tentokrát doslova: „Než odevzdám větev, zadám do Claude Code: Use the attached instructions.md - do you see any issues in the current branch? … Jak postupovat lépe? Jak vypadá optimální md file a proč?“ Ten postup je správně - agent jen čte, nic nemění, dostal zadání úkolu. Co mu chybí, je struktura toho md souboru. Takhle může vypadat šablona pro takové zadání:

# Review before merge

## Task (what was supposed to be done)
[Paste the original task here - verbatim, not from memory.]

## What to check (in this order)
1. Does the change meet the task? Go point by point, say YES/NO + where for each.
2. Did anything change that shouldn't have? (files outside the task's scope)
3. Error states: what happens on empty input / failure / bad data?
4. Consistency with the project's conventions (see CLAUDE.md).

## What NOT to do
- Don't modify any files, don't run git operations. Only read and report.

## Output format
- A list of findings, ordered from most severe.
- For each: file + line, what it is, why it matters, suggested fix.
- If everything is fine, say so explicitly - don't invent findings to hit a count.

Proč zrovna tohle: původní zadání doslova (agent kontroluje proti němu, ne proti dojmu), pořadí kontrol (nejdřív správnost, pak úklid), explicitní zákazy (revizor nemá měnit), a hlavně poslední řádek - povolení najít nulu. Bez něj agent vyrobí nálezy i tam, kde nejsou, protože cítí, že „se čekají“.

Jak velké sousto agent zvládne

Druhá nejčastější příčina selhání po špatném zadání: moc velký úkol. Agentovi během dlouhé práce přeteče kontext (co přesně je kontext, rozebereme v bloku 3) a nástroj ho v tichosti zhustí - a při tom zhuštění se může ztratit i půlka zadání. Agent pak sebevědomě dokončí něco jiného, než jste chtěli.

• Velký proces rozřežte na kroky, z nichž každý má vlastní „hotovo“ a dá se zkontrolovat samostatně.
• Základní pravidlo: když neumíte výsledek kroku ověřit do pár minut, je krok moc velký.
• Mezivýstupy nechte zapisovat do souborů - soubor přežije, kontext ne.

Průběžný příklad: revize má zadání podle šablony - s doslovným zadáním úkolu, pořadím kontrol, zákazy a povolením najít nulu. Agent ji teď zvládne.

Co je agent
uvnitř

Zadání z bloku 2 je napsané - teď se podíváme, co s ním agent udělá. Abyste mu věřili, potřebujete vidět, co se děje mezi „spustil jsem“ a „hotovo“. Není to černá skříňka - je to smyčka.

Čtyři součásti každého agenta

Minutový záznam jednoho běhu

Takhle vypadá revize z našeho průběžného příkladu zevnitř - krok za krokem, jak ji agent skutečně provede:

Všimněte si dvou věcí: agent průběžně plánuje a přehodnocuje (nález nejdřív ověřil, pak teprve hlásil) - a každý krok je zpětně čitelný. K záznamu běhu se vrátíme v bloku 4, je to váš hlavní nástroj důvěry.

Subagenti: agent si přizve pomocníky

V Claude Code může agent spustit subagenty - samostatné agenty s vlastním čistým kontextem, kterým deleguje část práce (např. „prohledej projekt a vrať mi jen závěr“). A jde to do hloubky: subagent může spustit dalšího, až do úrovně 5 pod hlavním vláknem - hlouběji už ne, limit nejde zvednout (a subagent k tomu potřebuje povolený nástroj Agent).

K čemu je hloubka dobrá: hlavní agent drží celek a deleguje špinavou práci - průzkum, dílčí kontroly, mechanické úpravy - aniž by si zaplnil vlastní kontext. To je mimochodem odpověď na „jak velké sousto agent zvládne“ z bloku 2: velké sousto se krájí i směrem dolů, mezi subagenty.

Napojení na okolí: MCP servery

Z prvního školení víte, co je MCP. Pro agenty jsou klíčová dvě napojení: issue tracker (agent si sám přečte task, na kterém pracuje, a zapíše výsledek) a source control (agent čte repozitář, zakládá větve a pull requesty). Tím se z „pomocníka v okně“ stává kolega zapojený do firemního oběhu práce.

A když nejste vývojář?

Principy z tohohle bloku platí všude - liší se jen nástroj, ve kterém je použijete:

Průběžný příklad: teď rozumíme, co se při revizi děje uvnitř - a víme, že záznam běhu se dá číst jako deník.

Co po agentovi:
důvěra, selhání, workflow

Agent doběhl a hlásí „hotovo“. Tady se rozhoduje, jestli agenty budete používat za rok - protože „hotovo“ je začátek vaší práce, ne konec.

Tři způsoby, jak agent selhává

Ve všech třech případech je první krok stejný: přečíst záznam běhu (v Claude Code celý průběh session - co agent četl, co spouštěl, co si myslel). Neptejte se „proč jsi to udělal?“ agenta, který selhal - odpověď si vymyslí. Čtěte, co skutečně dělal.

Co opravit nejdřív

Když výsledek nesedí, opravujte v tomhle pořadí - od nejčastější příčiny k nejvzácnější:

A kdy běh zabít a začít znovu místo opravování? Když agent v záznamu viditelně bloudí (krouží, mění věci mimo rozsah) - čerstvý start s lepším zadáním je skoro vždy rychlejší než záchrana zabloudilého běhu. Stejné pravidlo jako „kdy iterovat a kdy začít znovu“ z prvního školení.

Proč stejné zadání dá dvakrát jiný výsledek

Zlaté případy: poznáte, že agent nezhloupl

U agenta, kterého používáte opakovaně, si držte 5–10 zlatých testovacích případů - vstupy, u kterých znáte správný výstup. Po každé změně zadání, modelu nebo nástroje je prohnat. Bez toho každá úprava probíhá naslepo a agent může tiše degradovat týdny, než si toho někdo všimne.

Kdy z promptu udělat workflow

Jakmile stejný postup spouštíte potřetí, přestaňte ho psát do chatu a uložte ho: v Claude Code jako skill (postup + šablona zadání pod jedním povelem, znáte z prvního školení), v Claude.ai jako projekt s instrukcemi, v n8n jako uložený tok. Workflow = zadání + kontrola + formát výstupu, zabalené tak, aby je příště spustil kdokoli - ne jen autor.

Opakující se úkoly, které se pro agenty hodí

Druhá otázka z publika: „Konkrétní příklady opakujících se úkolů, které jste předali agentům.“ Vzorové příklady, které se hodí nejčastěji:

• Revize před odevzdáním - náš průběžný příklad; běží podle šablony z bloku 2.
• Dokumentace ke starým systémům - agent projde zdrojáky a podklady a sestaví dokumentaci; člověk verifikuje po kapitolách.
• Zápis z porady → úkoly - z nahrávky/poznámek strukturovaný zápis a seznam úkolů s termíny, podle pevné šablony.
• Týdenní report - agent posbírá čísla ze systémů a naplní šablonu; člověk píše jen komentář.
• První síto příchozích požadavků - klasifikace a příprava podkladů, rozhodnutí zůstává na člověku.

Vzorec je pokaždé stejný: častý úkol + jasná šablona výstupu + levná kontrola. Přesně kritéria z bloku 2.

Checklist k odnesení: před / při / po

PŘED
[ ] Proces zmapován: co / jak / proč (písemně)
[ ] Prošel sítem: častý · ověřitelný · levná chyba · jasné hotovo
[ ] Zadání má: definici hotovo, hranice (co nesmí), formát výstupu
[ ] Sousto akorát: každý krok ověřím do pár minut

PŘI
[ ] Vím, kde běží a jak ho zastavím
[ ] U delšího běhu občas mrknu na záznam (nebloudí?)

PO
[ ] Výstup proti definici hotovo, bod po bodu
[ ] Nález/pochybnost → čtu záznam běhu, ne dojmy
[ ] Potřetí stejný postup → uložit jako skill/workflow
[ ] Opakovaný agent → prohnat zlaté případy po každé změně

Průběžný příklad: revize doběhla - umíme poznat, jestli jí věřit, víme, co opravit, když ne, a ukládáme ji jako skill. Konec části 1: máme agenta, kterému věříme.

Orchestrace:
víc agentů vedle sebe

Jeden agent, kterému věříte, je základ. Teď je dáme vedle sebe - a řekneme si, kdy se to vyplatí a kdy je to jen drahé divadlo.

Dva důvody pro víc agentů

Kdy se to vyplatí - a kdy ne

• Vyplatí se: úloha se dá rozdělit na nezávislé kusy · výsledek stojí za dvojitou kontrolu · práce je víc než koordinace.
• Nevyplatí se: úkol je malý a sekvenční · agenti by si předávali jeden výstup jako štafetu · orchestrujete pro pocit „mám multiagentní systém“. Víc agentů = víc koordinace, víc tokenů, víc míst, kde se to zlomí.

Prakticky v Claude Code: subagenti z bloku 3 běží klidně paralelně; když víc agentů zapisuje do stejného projektu, každý dostane izolovanou kopii (worktree z prvního školení), ať si nepřepisují soubory.

Člověk ve smyčce (HITL) je návrhový prvek, ne přiznání slabosti

Anglicky se tomu říká human in the loop. Při orchestraci rozhodněte předem, kde stojí člověk. Pravidlo: vratné akce automaticky, nevratné přes schvalovací bránu. Přepsat koncept je vratné. Odeslat mail zákazníkovi, smazat data, zaplatit - nevratné, tam agent čeká na potvrzení.

AgentBoard: jak taková pipeline vypadá

Jak taková pipeline vypadá v praxi, ukazuje AgentBoard - naše aplikace, ve které se orchestrace skládá a spouští vizuálně, jako graf (možná na ni dojde i krátká ukázka). A není to obecné demo: v grafu běží přesně náš scénář revize - jeden agent reviduje, druhý kontroluje. Všechno na obrazovce, ne v terminálu:

• pipeline jako graf kroků - kdo po kom, co komu předává;
• schvalovací brány přímo v toku - běh se zastaví a čeká na člověka;
• opakování a návrat - selže-li krok, opakuje se nebo se tok vrátí, běh neumírá celý;
• běh proti lokálnímu modelu (Ollama) - celá orchestrace bez jediného tokenu v cloudu.

Pod kapotou je LangGraph - knihovna pro vývojáře, o které uslyšíte v bloku 6. A orchestraci si můžete pustit i u sebe: agent-flow je náš plugin pro Claude Code, kterým si pipeline z několika agentů spustí kdokoli. A nejsme v tom sami: stejný princip staví celý ekosystém - LangChain pro vývojáře, klikací Flowise nebo n8n, Zapier na propojení běžných aplikací. Pointa: orchestrace není magie, je to nakreslitelný proces - přesně ten, který jste v bloku 2 zmapovali.

Průběžný příklad: revizi zdvojíme - druhý agent s čistým kontextem a jiným modelem kontroluje po prvním. Autor a revizor, jako v redakci.

Automatizace: agent,
který se spustí sám

Vracíme se ke scénáři z úvodu: 9:14 přišel mail, 9:20 je hotový návrh odpovědi. Spouštěč je na tom to nejjednodušší - práce je všechno okolo.

Nejdřív: kde ten agent vlastně poběží?

Nejčastější zádrhel hned na startu: plánovaná úloha na zavřeném notebooku neběží. Agent, který se má spouštět sám, potřebuje stroj, který je vzhůru:

• Bez okna (headless): Claude Code umí běžet jako příkaz bez interakce (claude -p "zadání") - spustitelný plánovačem, skriptem, čímkoli.
• Ve firemní automatizaci (CI/CD): agent jako krok v pipeline - typicky revize při každém pull requestu.
• V cloudu: plánované běhy na serveru či ve službě - stroj je vzhůru vždy. Pod jakým účtem běží, řešíme níž.

Tři druhy spouštěčů

U spouštěčů na událost nezapomeňte na paměť mezi běhy: agent si musí někam zapisovat, co už vyřídil - jinak po restartu zpracuje stejný mail dvakrát a zákazník dostane dvě odpovědi.

Jak agenta napojit na e-mail

Scénář počítá s tím, že agent přečte mail. Jak se k němu ale dostane? Čtení a psaní mailu je oddělené od přemýšlení (to dělá model) - jsou dva knoflíky:

Pozor: skill ani plugin sám o sobě mail nečte - potřebuje k tomu nástroj (konektor/MCP) nebo skript. Skill jen zabalí postup „přečti, sestav koncept, ulož do konceptů", ne přístup ke schránce.

Bezpečnost: tři věci, které dohromady nesmí být

• Nejmenší nutné oprávnění: agent, který se spouští sám, běží pod vlastním servisním účtem s minimem práv - nikdy pod osobním účtem správce.
• Co smí vidět ≠ co smí udělat: řešte obojí. Přístup k datům a povolené akce (nevratné přes bránu z bloku 5).
• Domluva s IT předem: firemní agent čtoucí mail a interní systémy je téma pro IT a bezpečnost - přineste jim tenhle seznam, ne hotovou věc, kterou najdou sami.

Ekonomika: kdy se automatizace vyplatí

• Síto: ušetřený čas × četnost > náklad na vytvoření a hlídání. Půlka nápadů tímhle sítem neprojde - a je lepší to vědět předem než po měsíci práce.
• Cena běhu: denní automatizace = cena jednoho běhu × 30 × měsíce. Spočítejte, než zapnete - blok 1 vám k tomu dal ceník.
• Pojistky: limit útraty (zacyklený noční agent jinak protočí měsíční rozpočet do rána) a počítejte s limity počtu požadavků u API.
• Předplatné vs. API: osobní práce jede na předplatném; automatizace na API platí za spotřebu - proto se effort a volba modelu z bloku 1 u automatizací násobí.

Který nástroj pro koho

Nevybírejte „vítěze“ - vyberte nástroj podle člověka, který automatizaci bude vlastnit a udržovat.

Provozní checklist autonomního agenta

[ ] Vlastník: konkrétní člověk, který o agentovi ví a ručí za něj
[ ] Účet: vlastní servisní účet, nejmenší nutná oprávnění
[ ] Trojkombinace: data × cizí vstupy × odesílání - aspoň jedno chybí
[ ] Nevratné akce: jen přes schvalovací bránu (draft, ne odeslat)
[ ] Paměť mezi běhy: co už vyřídil, nezpracuje podruhé
[ ] Limity: strop útraty + max. počet běhů za den
[ ] Záznam: každý běh dohledatelný (kdy, co, proč)
[ ] Hlášení selhání: když běh spadne, někdo se to dozví (ne ticho)
[ ] Vypínač: jeden krok, kterým agenta kdokoli z týmu zastaví
[ ] Zlaté případy: sada testů, spouštěná po každé změně

Scénář z úvodu, rozkreslený

• 9:14 - mail dorazil; spouštěč probudil agenta (servisní účet, jen čtení schránky + psaní konceptů).
• 9:15 - agent zkontroloval paměť běhů: tenhle mail ještě nevyřizoval. (Že se probudil do minuty, platí, když schránka umí poslat notifikaci hned - push; když ji agent jen periodicky kontroluje - polling - počítejte s prodlevou podle intervalu.)
• 9:16 - přečetl mail a související historii, sestavil návrh odpovědi podle šablony.
• 9:18 - uložil návrh do konceptů - odeslání je nevratné, takže zůstává na člověku.
• 9:19 - zapsal záznam běhu a označil mail štítkem „návrh připraven“.
• 9:20 - vy otevíráte schránku: hotový koncept + deník, co se stalo a proč.

Všimněte si: žádný krok není magie. Zadání (blok 2), smyčka s nástroji (blok 3), kontrola člověkem (blok 4), brána na nevratnou akci (blok 5), spouštěč + provozní pravidla (blok 6).

Průběžný příklad: revize se teď spouští sama při každém založeném pull requestu. Z promptu z bloku 2 je služba - kruh se uzavřel.

Kam až to jde
posunout

Revize se teď spouští sama - to je šestá, nejvyšší příčka žebříku. Teď si ho ukážeme celý: šest příček od promptu k autonomii. Nejde o to vyběhnout je za týden - jde o to vědět, na které stojíte a která je další.

Žebřík samostatnosti

Poctivá zpráva: většina firem dnes stojí mezi příčkami 2 a 3 - a to je v pořádku. Každá příčka funguje sama o sobě a vydělává si na tu další. Přeskakovat se nevyplácí: autonomie bez zvládnuté kontroly (příčka 3) je jen rychlejší výroba chyb.

Ukázka na závěr: forge - kam až to dojde

Poslední ukázka spojuje všechno z dneška do jednoho reálného nástroje. forge (Filipův otevřený plugin pro Claude Code) vezme jednu větu zadání a dovede ji až k ověřenému, otestovanému kódu - přes deset fází a tři místa, kde to schválí člověk. Není to teorie, běží to.

Ten pětičlenný tým u verifikace (fáze 8) vypadá takhle:

• Bezpečnost - hraje útočníka, hledá díry.
• Správnost - pustí skryté testy, které autor kódu neviděl.
• Soulad se zadáním - auditor: dělá kód přesně to, co měl?
• Ďáblův advokát - musí najít aspoň tři způsoby, jak to selže; prázdný report neprojde.
• Velitel - sečte předchozí čtyři a vynese verdikt; když je něco pod prahem, vrací výsledek na opravu.

Každá vrstva forge je přitom jeden dnešní blok:

A protože každý běh zůstává celý na disku - každá fáze, každé rozhodnutí, každý nález - dá se zpětně rozebrat a celý proces podle něj vylepšit: doladit prompty, brány, kontroly. Nástroj se tak učí z vlastních běhů - přesně tak vznikla i ta verze, co přepsala sama sebe.

Od osobního agenta k týmovému

• Sdílejte postupy, ne dojmy: skill/šablona v repozitáři nebo sdíleném prostoru, kde si ji vezme celý tým.
• Každý sdílený agent má vlastníka - kdo ho udržuje, když se změní proces. Jinak přežije svého autora a nikdo neví, co dělá (checklist z bloku 6 platí i tady).
• Sdílejte i zlaté případy: kolega pozná, že jeho úprava agenta nic nerozbila.

Co udělat zítra ráno

Úspěch vypadá takhle: do týdne máte jednoho agenta, kterému věříte, na úkolu, který se opakuje. Všechno ostatní - orchestrace, spouštěče, autonomie - roste z tohohle semínka.

Co si odnášíte

• Šablona zadání pro revizi/kontrolu (blok 2)
• Checklist před / při / po (blok 4)
• Tabulka nástrojů - který pro koho (blok 6)
• Provozní checklist autonomního agenta (blok 6)
• Žebřík samostatnosti - mapa, kde jste a co je dál (blok 7)

Napřímo znamená: bez kouzel. Agent je proces, který jste zmapovali, zadání, které jste napsali, a kontrola, kterou neošidíte. Všechno ostatní je násobení.