# Promptbook ## Od úkolování AI k autonomním agendám **APT Framework — Agent–Project–Task** Whitepaper · verze 0.1 · 2. října 2026 Autor koncepce: Pavol Hejný > Projekt nemá pouze dostávat úkoly od člověka. Má mít vlastní agenty, kteří rozumějí jeho záměru, rozpoznávají potřebnou práci a průběžně ji vykonávají. ## Abstrakt Promptbook je framework pro dlouhodobou autonomní správu projektů a agend. Jeho cílem není pouze prodloužit úkol, který zvládne AI vykonat bez zásahu člověka. Cílem je změnit místo, odkud práce vzniká: od člověka, který opakovaně zadává jednotlivé požadavky, k projektu, jehož agenti sami rozpoznávají potřeby, vytvářejí úkoly a realizují je v rámci svěřených pravomocí. Základem je **APT Framework**, rozdělení kontextu na tři vzájemně propojené části: **agenty**, kteří mají role, cíle a pravidla; **projekt**, který obsahuje spravované materiály a jejich význam; a **úkoly**, které zachycují konkrétní práci. Nejde o pevnou hierarchii ani o předepsané pořadí kroků. Jde o konvenci, jak organizovat dlouhodobý kontext pro AI. V referenčním uspořádání žijí všechny tři části v jednom Git repozitáři. Agentní definice i úkoly se verzují společně s projektem. Dokončení úkolu a změny, kterými byl splněn, se zaznamenávají v jediném commitu. Deterministický orchestrátor vybírá práci, spouští kontroly a zaznamenává přijaté výsledky. Agenti přitom nejen úkoly vykonávají, ale také je vytvářejí: z průběžných zjištění, externích událostí i vlastních dlouhodobých cílů. Nad tímto modelem stojí spustitelný engine a serverové prostředí, které umožňuje provoz mimo počítač vlastníka. Dlouhodobou vizí je projekt schopný samostatně zajišťovat vývoj, provoz i další svěřené agendy a zapojovat člověka především při výjimkách a rozhodnutích přesahujících jeho mandát. ### Rozsah a stav dokumentu Technický popis vychází z implementace a záměrů popsaných autorem koncepce; není nezávislým auditem zdrojového kódu ani výsledkem výkonnostního testování. Kapitola 12 rozlišuje popsané existující schopnosti, plánovaná rozšíření a dlouhodobou vizi. Doporučené provozní pojistky nejsou automaticky tvrzením o již implementovaných funkcích. APT je zde pracovní označení, nikoli výsledek prověření názvu či značky. ### Obsah 1. Od vykonávání úkolů k převzetí agendy 2. A — Agenti: role, cíle a přenositelná expertiza 3. P — Projekt jako kontextová nádoba 4. T — Úkoly jako verzovaná jednotka práce 5. Kontrolovaný pracovní cyklus 6. Jeden commit: výsledek práce i stav úkolu 7. Odkud přichází nová práce 8. Trvalá hodnota a vyměnitelný běh 9. Framework, engine a agentní server 10. Hranice autonomie a provozní pojistky 11. Tři příklady jedné architektury 12. Stav implementace a dlouhodobá vize ## 1. Od vykonávání úkolů k převzetí agendy Výchozím problémem je způsob spolupráce, ve kterém člověk zůstává hlavním iniciátorem práce. Zadá požadavek, AI jej zpracuje a čeká na další. Ani schopnost samostatně vykonat rozsáhlý úkol tento vztah sama o sobě nemění. O tom, co je potřeba udělat příště, stále rozhoduje člověk. Promptbook se zaměřuje na jiný vztah: člověk nesvěřuje systému pouze úkol, ale **dlouhodobou agendu**. Může jí být správa webu, vedení účetních podkladů, komunikace se zákazníky nebo rozvoj digitálního produktu. Agenda zahrnuje záměr, materiály, pravidla, práci i odpovědnost za její průběžné pokračování. Rozdíl není v tom, zda agent dokáže pracovat hodinu nebo několik dní. Rozdíl je v tom, zda potřebuje člověka, aby po každém výsledku znovu uvedl systém do pohybu. Autonomní agenda musí umět rozpoznat další potřebu, posoudit ji vůči svému záměru a vytvořit vykonatelnou práci. Stejně důležitá je schopnost nečinit nic, když žádná přínosná a oprávněná práce není. ### Tři části jednoho kontextu APT rozlišuje tři otázky. **Agent** určuje, kdo pracuje, za čím směřuje a podle jakých pravidel. **Projekt** určuje, nad čím se pracuje a v jakém prostředí. **Úkol** určuje, jaká konkrétní změna nebo činnost má právě nastat. Tyto části tvoří propojený celek, nikoli posloupnost „nejdříve agent, potom projekt, nakonec úkol“. Agent mění projekt. Úkol může měnit definici agenta. Výsledkem úkolu může být další úkol. Změna projektu může vyvolat novou potřebu. Agenda je tento celek v dlouhodobém provozu, nikoli význam písmene A. U softwarového produktu může být přirozeným středem pozornosti projekt a jeho zdrojové soubory. U zákaznické komunikace mohou dominovat agenti a jejich pravidla vystupování. U zpracování jednotlivých požadavků mohou dominovat úkoly. APT zachovává stejné pojmy pro všechny tyto perspektivy, aniž by z různého důrazu vytvářel různé frameworky. ### Konvence, nikoli nový druh dat Každou část lze technicky uložit mnoha způsoby. Přínosem APT je společná konvence: odlišit dlouhodobé instrukce, spravovaný stav a konkrétní práci tak, aby bylo zřejmé, co se přenáší, co se verzováním uchovává a co lze znovu vytvořit. To zároveň neznamená načíst celý repozitář do každého požadavku modelu. Repozitář je organizovaný zdroj kontextu. Pro konkrétní běh se z něj vybírají relevantní části. Dlouhodobá kontinuita má být uložená v tomto zdroji, nikoli závislá na nepřerušené konverzaci s jedním modelem. ## 2. A — Agenti: role, cíle a přenositelná expertiza Agent je v APT definovaný subjekt práce. Jeho identita nevychází primárně z názvu modelu, ale z role a cíle, které v agendě zastává. Typickými názvy jsou Developer, Frontend Developer, Copywriter, Accountant nebo Security Reviewer. Nejdůležitější součástí definice je **cíl**. Cílem developera může být dlouhodobě udržovat projekt v dobrém technickém stavu a rozvíjet jeho funkcionalitu. Cílem bezpečnostního agenta může být rozpoznávat a omezovat bezpečnostní rizika. Cíl přetrvává i tehdy, když agent právě nemá přidělený úkol. Pravidla vymezují způsob práce. Developer může mít předepsané konvence, omezení velikosti souborů nebo povinnost doplňovat testy. Copywriter pravidla tónu komunikace. Právní agent pravidla ověřování podkladů a předávání nejistých závěrů člověku. Definici doplňují znalosti, dovednosti a požadované nástroje. Samotné označení role přitom není potvrzením odborné kvalifikace ani oprávněním jednat bez omezení. ### Dědičnost a specializace V Promptbooku se agenti definují soubory `.book` s vymezenou syntaxí. Základní agent **Adam** poskytuje obecná pravidla, ze kterých mohou ostatní vycházet. Nad ním lze vytvářet specializace: z Adama obecného developera, z developera frontendového a backendového developera. Dědičnost umožňuje sdílet společné instrukce bez opakovaného kopírování. Změna společného základu však zároveň může změnit chování více rolí. Proto je důležité zachovat dohledatelnou podobu děděných definic a při změnách ověřovat výsledné chování. Přesná pravidla řešení konfliktů a případné vícenásobné dědičnosti patří do specifikace jazyka, nikoli do nevyřčených předpokladů tohoto modelu. ### Import a vazba na model Obecná definice agenta může být použitelná v různých projektech i organizacích. Projekt ji může importovat a doplnit o vlastní kontext. Plánovaný katalog agentů má tuto opakovanou použitelnost zpřístupnit jako instalovatelné definice. Přenos definice ale není přenosem přihlašovacích údajů ani automatickým udělením přístupu k firemním datům. Agent je z triády nejblíže modelu a jeho běhovému prostředí, označovanému také jako _harness_. Přesto není s konkrétním modelem totožný. Popsaný framework volí model podle kombinace cíle a schopností agenta a charakteru úkolu. Toto směrování odděluje záměr od prostředku jeho vykonání; neznamená záruku, že libovolné modely budou zaměnitelné bez ověření. ## 3. P — Projekt jako kontextová nádoba Projekt je **kontextová nádoba**: uspořádaný soubor materiálů a informací, nad kterými agenda pracuje. Na rozdíl od agenta nemá předepsaný jednotný vnitřní formát. V implementaci může být libovolnou složkou. Doporučenou a pro společné verzování zásadní podobou je Git repozitář. Bez Gitu zůstává logické dělení APT, nikoli popsané výhody společné historie a návratu změn. Projekt může obsahovat zdrojové soubory aplikace, dokumentaci, faktury, obchodní podklady, komunikační pravidla nebo skripty. Nemusí jít o software ani o časově ohraničený projekt v manažerském smyslu. V APT označuje také dlouhodobě spravovaný pracovní prostor. ### Orientace od obecného ke konkrétnímu Typickým vstupním bodem je `README.md`: vysvětluje, co projekt je, k čemu slouží a jak je uspořádaný. Další instrukce mohou být v `AGENTS.md`, `CLAUDE.md` nebo v oborové dokumentaci. Obdobně standard AGENTS.md rozlišuje úvodní dokumentaci pro člověka a instrukce pro agenty. [4] Adresářová struktura pomáhá postupně zpřesňovat kontext. Dokumentace celého projektu poskytuje orientaci; dokumentace konkrétní části přidává detail. Hloubka umístění však není měřítkem důležitosti. Soubor v hluboké podsložce může být pro daný úkol rozhodující a místní pravidlo může být přesnější než obecné. AGENTS.md s lokálními instrukcemi pro podprojekty výslovně počítá. [4] ### Fyzické umístění není významové zařazení V kořenové složce se nacházejí také definice agentů a úkoly. Fyzicky jsou součástí stejného pracovního prostoru, ale v APT zůstávají samostatnými kategoriemi A a T. Výrok „projekt obsahuje agenty a úkoly“ tedy popisuje uložení, nikoli zrušení rozlišení triády. Stejně tak je potřeba odlišit provozní soubory. `.git` uchovává verzovací historii. Dočasná složka frameworku, v popsaném uspořádání `.promptbook`, slouží pro obnovitelné provozní artefakty a cache a typicky má být ignorována Gitem. Jejich konkrétní názvy jsou implementační konvencí, nikoli podstatou APT. ### Externí kontext a hranice repozitáře Zásada „kontext pohromadě“ nevyžaduje vložit do Gitu každou databázi, přílohu nebo produkční tajemství. Projekt může odkazovat na externí úložiště a služby. Pro kontinuitu potřebuje srozumitelnou mapu těchto zdrojů, pravidla přístupu a identifikaci podkladů významných pro rozhodnutí. Odkaz na proměnlivý zdroj ale neuchovává jeho historický obsah. Má-li být rozhodnutí později doložitelné, je vhodné uchovat odpovídající verzi, bezpečně uložený snímek nebo jiný identifikovatelný záznam. Přihlašovací údaje patří mimo verzované soubory. Repozitář může být zdrojem pravdy o definici a zaznamenaném stavu agendy, aniž by byl jediným úložištěm všech jejích dat. ## 4. T — Úkoly jako verzovaná jednotka práce Úkol vyjadřuje konkrétní práci v rámci agendy. Může požadovat vytvoření aplikace, úpravu menu, přípravu podkladů, analýzu incidentu i návrh dalších úkolů. Jeho výstupem nemusí být kód: může jím být dokument, zjištění nebo nově vytvořený plán. V popsané implementaci jsou úkoly Markdown soubory ve složce `prompts`, zpravidla jeden soubor na úkol. Přechod na formát `.book` je plánovaným rozšířením. Případné přejmenování složky na `tasks` nebo `PRDs` nemění princip: zadání i jeho stav jsou čitelnou a verzovanou součástí pracovního prostoru. ### Od prvního zadání k průběžnému rozvoji Inicializace může začít v prázdné složce i v existujícím projektu. Doplní základní agenty a ukázková zadání; nemusí nahrazovat dosavadní organizaci souborů. V prázdném projektu může první úkol popsat zamýšlený produkt a vytvořit jeho výchozí podobu. Tím však životní cyklus nekončí. Následující úkoly pracují nad výsledkem předchozích úkolů ve stejném prostředí. Počáteční vytvoření projektu a jeho pozdější údržba tak nejsou dvě oddělené disciplíny. Používají stejný kontext, stejné role a stejný mechanismus ověřování. ### Priorita, přiřazení a závislosti Úkol může mít prioritu, konkrétního agenta nebo skupinu agentů, závislosti na dalších úkolech a nejdřívější datum zahájení. Obchodní podmínky mohou připravovat právník s copywriterem a developerem; dashboard developer s datovým specialistou. Pojmenování souborů s prefixem roku, měsíce a pořadového čísla poskytuje deterministické základní pořadí. Priorita a závislosti jej dále zpřesňují. Pořadové číslo proto není náhradou za závislost: prioritní úkol stále musí splnit podmínky svého spuštění. Je také rozdíl mezi datem a událostí. Požadavek „začni v pondělí“ lze vyhodnotit podle času. Požadavek „začni až po oznámení nového modelu“ potřebuje potvrzený signál z externího světa. Datum může být jeho zástupným plánem, nikoli důkazem, že událost skutečně nastala. ### Zadání a vyhodnotitelnost Pro spolehlivé vykonání by zadání mělo popisovat zamýšlený výsledek, podstatná omezení a způsob ověření. Obecné kontroly projektu odpovídají na otázku, zda zůstává ve stanovených mezích. Akceptační kritéria úkolu odpovídají na jinou otázku: zda se skutečně provedlo to, co bylo požadováno. Při práci více agentů je potřeba určit, kdo připravuje výsledek, kdo jej posuzuje a kdy se předává dál. Samotný seznam přiřazených rolí ještě neurčuje bezpečné souběžné úpravy ani pravidla řešení jejich neshod. ## 5. Kontrolovaný pracovní cyklus APT rozlišuje agentní rozhodování a deterministické řízení běhu. Modely navrhují řešení a provádějí práci. Orchestrátor řídí výběr úkolů, spouští kontroly a vytváří commity. Agenti standardně pracují nad aktuálním pracovním stromem; přístup k celé historii není nutnou součástí každého běhu. Základní cyklus nejprve ověří výchozí stav. Pokud kontroly selžou, vznikne opravný úkol. Pokud projdou, vybere se způsobilý úkol podle plánovacích pravidel. Po jeho vykonání následují další kontroly a případné opravy. Teprve přijatý výsledek se zaznamená jako dokončená práce. > Pozorovat stav → vybrat práci → provést změnu → ověřit výsledek → zaznamenat přijatý stav. ### Co znamená „projekt je v dobrém stavu“ Projekt může definovat kontrolní skripty, tedy _checky_. Výsledkem kontroly je strojově vyhodnotitelné splnění nebo nesplnění podmínky. U softwaru může jít o unit testy, end-to-end testy, linting, typovou kontrolu nebo kontrolu pravopisu. U účetních podkladů například o kontrolu součtů a návazností mezi záznamy. „Dobrý stav“ zde znamená **splnění definovaných kontrol**, nikoli důkaz bezchybnosti. Kontrola ověřuje jen to, co skutečně měří. Formální shoda součtů sama nepotvrzuje správnost účetního posouzení; úspěšný build nepotvrzuje použitelnost dashboardu. Proto je nutné spojovat projektové kontroly s ověřením konkrétního zadání. Agentní review může doplnit vlastnosti, které se deterministickým skriptem posuzují obtížně. Je plánovanou vrstvou kontroly, nikoli ekvivalentem deterministického důkazu. Také skriptové kontroly mohou být nestabilní, pokud závisejí na síti nebo proměnlivém prostředí; binární výsledek sám o sobě nezaručuje opakovatelnost. ### Podmínky přijetí změny Zamýšleným výsledkem je historie přijatých, ověřených přechodů místo řady dílčích pokusů. Commit ale sám o sobě nezaručuje kvalitu: Git standardně zaznamenává obsah připraveného indexu. Povinnost zkontrolovat odpovídající obsah musí zajistit orchestrátor. [2] Pro zachování této vlastnosti nesmí mezi kontrolou a commitem nepozorovaně přibýt jiná změna. Základní řešení je serializovat zápisy; souběžná práce vyžaduje izolaci a nové ověření integrovaného výsledku. Po konfliktu při synchronizaci nelze spoléhat pouze na dřívější úspěšný test. Opravný cyklus v produkčním nasazení potřebuje rozpočet a mezní počet pokusů. Při opakovaném selhání se práce zablokuje a předá člověku, místo aby se neomezeně spotřebovávaly prostředky. Jde o doporučenou provozní pojistku nad základním cyklem. ## 6. Jeden commit: výsledek práce i stav úkolu Uložení úkolů uvnitř repozitáře má konkrétní důvod: **výsledek práce a záznam o jejím dokončení lze uložit jako jednu verzovanou změnu**. Git pracuje se snímky verzovaných souborů; do stejného snímku proto může patřit kód, dokumentace, definice agentů i stav úkolu. [1] Před vykonáním například existuje nevyřešený úkol na doplnění zákaznického dashboardu. Po vykonání jediný commit obsahuje jeho implementaci, související testy a označení úkolu za dokončený. Obsah zadání je podle popsané implementace současně použit jako commit message. Historie tak spojuje požadavek, změnu a zaznamenaný stav splnění. Pokud práce vytvoří další úkoly nebo upraví definici agenta, mohou být součástí stejného přechodu i tyto změny. Tento princip označujeme jako **společné verzování práce a jejího výsledku**. Není nutné synchronizovat dokončení úkolu z nezávislé databáze s odpovídající verzí souborů: obojí je součástí téhož commitu. Nástroj nad repozitářem může zobrazovat frontu úkolů, ale nemusí být jediným místem, kde tato informace existuje. ### Návrat změny a práce ve větvích Při úplném revertu takového commitu se spolu s implementací vrací také změna stavu úkolu. Jestliže úkol existoval před implementací jako nesplněný, může se tím znovu objevit mezi nevyřešenými úkoly. Jde o důsledek společného uložení, nikoli o zvláštní integrační mechanismus. Git revert vytváří nový commit obracející dřívější změny; historii jednoduše nemaže. [3] Tato vlastnost má přesné podmínky. Byl-li úkol ve stejném commitu teprve vytvořen a zároveň dokončen, úplný revert jej může odstranit, nikoli znovu otevřít. Vrácení pouze části souborů nemusí vrátit jeho stav. Revert starší změny může vyžadovat řešení konfliktů a neověřuje, zda nadále dávají smysl pozdější závislé úkoly. [3] Při práci ve větvích mají soubory i úkoly svou odpovídající verzi. Při návratu ke staršímu stavu lze číst tehdejší podobu obou. Slučování však stále potřebuje kontrolu významových konfliktů: stav „hotovo“ nelze bez ověření převzít, jestliže sloučený výsledek danou funkci nezachoval. ### Co tento princip nezaručuje Společné verzování zajišťuje souběžný záznam, ne pravdivost libovolného označení „hotovo“. Tu musí podpořit ověřovací cyklus. Git také nevrací změny mimo repozitář. Odeslaný e-mail, provedená platba nebo změna produkčních dat nepřestanou existovat jen proto, že se obrátil commit. Znovu otevřený úkol proto nemusí být okamžitě způsobilý k opakovanému vykonání. Vlastník musí mít možnost jej upravit nebo zablokovat, aby se neopakovalo zamítnuté řešení. Zejména u externích akcí je nutné nejprve zjistit skutečný stav a zabránit nežádoucímu opakování. Pro tyto úlohy je společné verzování součástí evidence, nikoli univerzální transakcí nad okolním světem. ## 7. Odkud přichází nová práce Systém, který pouze postupně vykoná připravenou frontu, po jejím vyčerpání nemá co dělat. Schopnost běžet na serveru tuto vlastnost nemění. Dlouhodobá autonomie vzniká až tehdy, když systém umí práci také rozpoznat a formulovat. V APT je vytvoření úkolu běžnou změnou souborů. Agent proto může při vykonávání jednoho úkolu vytvořit další. Research agent může prozkoumat problém a připravit implementační zadání developerovi. Reviewer může místo přímé opravy formulovat navazující úkol. Plánování se stává dohledatelným výstupem práce, ne jen přechodným obsahem konverzace. ### Tři zdroje úkolů **Člověk** může zadávat nové požadavky, měnit priority a určovat záměr. Autonomie tuto možnost neruší; pouze z ní nedělá nezbytný předpoklad každého dalšího kroku. **Probíhající práce** může odhalit závislosti, vedlejší problémy nebo potřebu dalšího výzkumu. Agent vytvoří navazující zadání, aniž by musel vše bez omezení zahrnout do původního úkolu. **Cíle agentů a vnější události** mohou vyvolávat práci i při prázdné frontě. Podnětem může být uživatelský feedback, e-mail, chybový log, hlášení monitoringu nebo nové informace relevantní pro bezpečnost projektu. ### Agent jako vykonavatel i iniciátor Bezpečnostní agent může mít dlouhodobý cíl, přestože nemá přidělený žádný konkrétní úkol. Z externího hlášení zjistí možné riziko, posoudí vztah k projektu a vytvoří úkol k ověření. Následně může připravit opravné zadání developerovi a kontrolu výsledku dalšímu reviewerovi. Každý přechod vytváří čitelný záznam v kontextu agendy. Dlouhodobý cyklus tedy zahrnuje nejen vykonávání, ale také pozorování, interpretaci a plánování. Cíl určuje, proč je podnět relevantní. Úkol z něj dělá konkrétní práci. Kontroly a zaznamenaný výsledek vracejí zpětnou vazbu do projektu. Samotný text cíle však spící proces neprobudí. Provoz potřebuje spouštěcí mechanismus: událost, pravidelné vyhodnocení nebo jiný signál. Stejně tak musí umět podněty slučovat a vyhodnotit, že další úkol není potřebný. Autonomie není povinnost vytvářet nekonečnou práci; je to schopnost jednat včas a účelně bez každodenního úkolování člověkem. ## 8. Trvalá hodnota a vyměnitelný běh Druhým významným přínosem APT je rozlišení dlouhodobě cenného kontextu od obnovitelných prostředků jeho zpracování. Model, dodavatel i běhové prostředí se mohou změnit. Projekt by kvůli tomu neměl přijít o svůj záměr, pravidla a výsledky práce. Toto rozlišení je samostatnou osou vedle triády A–P–T. Neplatí, že vše v jedné kategorii je trvalé a vše v jiné zahoditelné. Každá kategorie může obsahovat jak autoritativní podklady, tak odvozené reprezentace. ### Co uchovávat Dlouhodobou hodnotu mají záměr projektu, aktuální spravované materiály, zdrojové definice agentů, zadání, rozhodnutí a jejich podklady, akceptační kritéria, kontroly a relevantní historie. Pokud zkušenost z vykonaného úkolu vede ke zlepšení pravidel nebo znalostí agenta, má se toto zlepšení promítnout do udržované definice či dokumentace. Takové učení nevyžaduje změnu vah modelu. Může spočívat v úpravě instrukcí, příkladů, nástrojů nebo projektových pravidel. Změna však musí zůstat dohledatelná a posouditelná; agent nemá nepozorovaně měnit vlastní mandát. ### Co lze znovu vytvořit Cache, odvozené indexy, sestavené prompty nebo dočasné výstupy mohou být obnovitelné, pokud k jejich vytvoření existují zachované vstupy a postup. Samotný fakt, že soubor vytvořila AI, z něj ale nedělá bezpečně zahoditelný artefakt. Vygenerovaný a následně ověřený zdrojový kód může být autoritativní součástí projektu. Také provozní záznamy vyžadují rozlišení. Pomocný výpis lze někdy zahodit. Záznam nutný k doložení externí akce nebo příčiny incidentu patří do trvalé evidence, nikoli pouze do mazatelné cache. ### Změna modelu bez ztráty identity Při přechodu na jiný model má být zachována definice role, cíl, pravidla, projekt i úkoly. Mění se jejich vykonavatel a případně adaptér nástrojů. Kompatibilitu je nutné ověřit na reprezentativních úlohách a kontrolách: zachování textové definice nezaručuje shodné chování. Přenositelnost kontextu tak není slibem identických výsledků. Je architektonickým oddělením dlouhodobé investice do agendy od konkrétního způsobu jejího spuštění. Stejný snímek repozitáře pomáhá dohledatelnosti; s jiným modelem, prostředím nebo externími daty nemusí vést ke stejnému výsledku. ## 9. Framework, engine a agentní server Promptbook je vhodné popisovat ve třech vrstvách. Jejich oddělení umožňuje vysvětlit obecný princip bez závislosti na konkrétním způsobu nasazení. **Framework APT** definuje organizaci kontextu, vztahy mezi agenty, projektem a úkoly a princip společného verzování. Je to koncepční vrstva: jak má být agenda popsaná a jak zachovávat její kontinuitu. **Engine spustitelný z CLI** tento model vykonává nad konkrétní složkou či repozitářem. Inicializuje pracovní prostředí, zpracovává úkoly, spouští kontroly a spravuje přijímání změn. Popsaný režim podobný CI může automaticky synchronizovat změny se vzdáleným Git repozitářem pomocí pull a push. **Agentní server** poskytuje prostředí pro trvalý běh. Zajišťuje provoz mimo počítač vlastníka a rozhraní pro jeho interakci s agendou. Podle popisu autora existuje instalovatelný serverový celek, automatizované přiřazení domény a instalační skript ověřený na Fedoře a při nasazení na DigitalOceanu. Tento dokument nepředpokládá ověřenou kompatibilitu s každým cloudovým prostředím. ### Provoz patří projektu, ne pracovní stanici Projekt má vlastní agenty, úkoly a projektově instalovanou verzi nástroje. Různé projekty proto mohou používat různé verze enginu a odlišné sestavy rolí. Jejich životní cyklus nemusí být navázaný na to, zda konkrétní vývojář zapnul počítač nebo aktualizoval svůj globální nástroj. Projektová instalace sama o sobě neznamená bezpečnostní izolaci. Provoz více agend vyžaduje samostatně vyřešit oprávnění, prostředky a souběžný přístup. Stejně tak automatický push chrání pouze synchronizovaný verzovaný obsah; nenahrazuje zálohy externích dat a obnovu celého serveru. ### Vztah k existujícím přístupům Projektově uložené instrukce nejsou samy o sobě novou kategorií; veřejný formát AGENTS.md je přímo podporuje. [4] Rovněž GitOps staví na verzovaném popisu žádoucího stavu a jeho průběžném slaďování se skutečností. [5] Přínos popsaného uspořádání Promptbooku proto nespočívá v tvrzení, že ostatní nástroje tyto prvky nemají. Spočívá v jejich propojení s dlouhodobými rolemi, tvorbou nové práce podle cílů a společným verzováním úkolů i výsledků. Odlišujícím záměrem je samostatně provozovaná agenda, nikoli pouze pohodlnější rozhraní pro zadávání požadavků. ## 10. Hranice autonomie a provozní pojistky Autonomie má být vždy vztažená k mandátu: co smí systém rozhodovat, jaké prostředky může použít a ve kterých situacích potřebuje vlastníka. Následující zásady vyjadřují doporučené požadavky na provoz, nikoli soupis potvrzených funkcí současné implementace. ### Pravomoci nejsou totéž co cíle Cíl „udržuj produkt bezpečný“ neopravňuje agenta k libovolnému zásahu. Role potřebuje odpovídající technická oprávnění, rozsah povolených změn a pravidla eskalace. Přístup k nástrojům má respektovat nejmenší potřebný rozsah. Limity výdajů, nevratné akce a změny samotných pravidel vyžadují zvláštní zacházení. Vlastník má dostávat rozhodnutí, která skutečně nemůže učinit systém v rámci svého mandátu: chybějící přístup, rozpor cílů, opakované selhání nebo požadavek s významným dopadem. Nemá být nucen potvrzovat každou drobnost, ale nesmí ztratit možnost běh zastavit a změnit jeho směr. ### Ochrana kontrol a zdrojů instrukcí Pokud agent může bez omezení přepsat test, který má jeho práci ověřit, ztrácí úspěch testu význam. Změny kontrol proto potřebují odlišit od obcházení požadavků. Podobně musí být rozlišené běžné úpravy agentních definic a změny jejich oprávnění či nadřazených pravidel. E-mail, uživatelský feedback nebo obsah externího webu může být podkladem pro práci, nikoli automaticky oprávněním měnit instrukce systému. Provozní návrh musí bránit tomu, aby se nedůvěryhodná data proměnila v nadřazený pokyn. Cíl agenta ani umístění textu do projektové složky samo o sobě tuto hranici důvěry neřeší. ### Externí akce a obnova po chybě U akcí mimo repozitář je potřeba trvalá evidence výsledku a ochrana před opakováním. Po přerušení běhu může být lokálně nejasné, zda služba požadavek už provedla. Návrh má proto využít identifikaci operací, kontrolu skutečného stavu a podle možností služby idempotenci, tedy bezpečné opakování stejného požadavku bez násobení účinku. Po revertu, změně větve nebo obnově serveru nelze slepě znovu provést všechny úkoly označené jako nesplněné. Nejprve je nutné zohlednit jejich externí účinky. Závazné podání či finanční operace navíc musí respektovat oprávnění a schvalování vlastníka; tento whitepaper nenahrazuje oborové právní ani účetní posouzení. ### Dohledatelnost a náklady Vedle přijatých změn má provoz uchovávat přiměřené záznamy neúspěšných pokusů, použitých verzí, podkladů a zásahů vlastníka. Čistá Git historie nemusí být kompletním záznamem běhu a sama není nezměnitelným auditním archivem. Rozpočty, omezení opravných pokusů a potlačení duplicitních podnětů chrání před situací, kdy agenti vytvářejí úkoly rychleji, než vzniká hodnota. Bezpečné pozastavení je legitimním výsledkem autonomního rozhodování, nikoli automaticky jeho selháním. ## 11. Tři příklady jedné architektury Následující scénáře ilustrují použití modelu. Nejsou tvrzením o hotové integraci všech uvedených oborů nebo o naměřených výsledcích nasazení. ### Správa a rozvoj webové aplikace Projekt obsahuje zdrojové soubory, dokumentaci, produktový záměr a testy. Developer rozvíjí funkcionalitu, copywriter spravuje texty a bezpečnostní agent vyhodnocuje rizika. Počáteční úkol může aplikaci vytvořit, další úkoly ji postupně rozšiřují. Později monitoring zachytí opakovanou chybu. Agent z ní vytvoří reprodukovatelné zadání, developer připraví opravu a regresní test. Po kontrole vznikne commit s opravou i dokončeným úkolem. Nasazení a ověření skutečného provozu jsou dalšími explicitními kroky; nelze je automaticky zaměnit za úspěšný commit. ### Práce s účetními podklady Projekt obsahuje nebo odkazuje na faktury, bankovní podklady, účetní postupy a relevantní komunikaci. Účetní agent organizuje podklady a sleduje úplnost; další role posuzuje nejasnosti a připravuje otázky k odbornému rozhodnutí. Přijetí nové faktury může vyvolat úkol ke zpracování. Nesoulad podkladů vytvoří navazující úkol k dohledání chybějící informace. Kontroly ověřují formální konzistenci a návaznosti. Příprava podání, jeho schválení a skutečné odeslání mají odlišné stavy a pravomoci; technická kontrola nepřebírá odbornou odpovědnost. ### Komunikace se zákazníky Projekt tvoří znalosti o produktu, komunikační pravidla, šablony a bezpečně zpřístupněná historie. Agent pro podporu řeší požadavky, copywriter rozvíjí formulace a další role posuzuje výjimky. Opakované dotazy mohou vést nejen k jednotlivým odpovědím, ale také k úkolu doplnit dokumentaci nebo změnit matoucí část aplikace. Tím se agenda posouvá od odbavování zpráv k odstraňování jejich příčin. Návrh odpovědi a její odeslání jsou rozlišitelné operace, protože druhá z nich má účinek mimo repozitář. ## 12. Stav implementace a dlouhodobá vize ### Popsané existující jádro Podle autora koncepce existuje definování agentů v `.book` souborech, dědičnost se základním agentem Adamem, práce nad projektovou složkou, Markdown úkoly v `prompts`, jejich přiřazování, prioritizace, závislosti a časové podmínky. Popsána je také volba modelu s ohledem na agenta a úkol. Součástí popisu je engine s kontrolním a opravným cyklem, orchestrátorem vytvářené commity spojující změny s dokončením úkolu, tvorba dalších úkolů agenty, práce s externími podněty, synchronizace se vzdáleným Gitem a serverové nasazení. Dostupnost konkrétních konektorů a přesné chování plánovače musí být doloženy implementační dokumentací příslušné verze. ### Plánovaná rozšíření Výslovně plánovanými směry jsou úkoly ve formátu `.book`, agentní kontroly doplňující deterministické checky a katalog umožňující instalovat opakovaně použitelné agenty. Tento dokument jim nepřiřazuje datum vydání ani je nezaměňuje za současné funkce. Provozní pojistky popsané v kapitole 10 představují požadavky na důvěryhodné nasazení. Rozsah jejich skutečného vynucování je třeba ověřovat samostatně. Whitepaper neobsahuje naměřenou úspěšnost, záruku plné autonomie ani srovnávací benchmark konkurence. ### Jak posuzovat pokrok Užitečným měřítkem není samotný počet dokončených úkolů. Důležité je, kolik smysluplné práce agenda přijme bez operativního zásahu člověka, kolik času a nákladů vyžaduje ověřený výsledek a jak často se změny musí opravovat nebo vracet. Pro pilotní nasazení dává smysl sledovat četnost a důvody lidských zásahů, čas od podnětu k ověřenému výsledku, náklady opravných cyklů a dopad na skutečný cíl agendy. Metriky je nutné vyhodnocovat společně, aby omezení zásahů člověka nevznikalo na úkor kvality nebo zatajených selhání. Jde o návrh hodnocení, nikoli zveřejněné výsledky Promptbooku. ### Projekt, který si udržuje vlastní kontinuitu Dlouhodobou vizí je projekt, který má záměr, vlastní role a prostředky k jednání. Sám vyhledává potřebnou práci, rozvíjí se, komunikuje, sleduje provoz a řeší rizika. U digitálního produktu může tato vize zahrnovat také propagaci, správu plateb a vytváření ekonomického výnosu pro vlastníka. Takový stav není v tomto dokumentu tvrzen jako univerzálně dosažená schopnost. Plná samostatnost napříč technickými, obchodními a právními činnostmi zůstává dlouhodobým směrem, podmíněným schopnostmi modelů, kvalitou kontrol, oprávněními a konkrétním prostředím. **Smyslem Promptbooku je přesunout člověka z role nepřetržitého zadavatele podúkolů do role vlastníka záměru, pravidel a odpovědnosti.** APT k tomu poskytuje trvalou strukturu: agenty, kteří vědí, proč pracují; projekt, který nese kontext; a úkoly, které propojují záměr s ověřitelnými změnami. ## Příloha: orientační uspořádání projektu Následující strom ilustruje rozdělení popsané v dokumentu. Nejde o úplnou instalační šablonu ani o normativní specifikaci názvů a velikosti písmen. ```text projekt/ README.md vstupní orientace a záměr AGENTS.md projektové instrukce Agents/ A: definice rolí adam.book developer.book security-reviewer.book prompts/ T: zadání a jejich stav 2026-10-001-initial.md 2026-10-002-dashboard.md src/ P: příklad spravovaného obsahu docs/ P: dokumentace a rozhodnutí checks/ P: příklad umístění kontrol .git/ verzovací historie .promptbook/ obnovitelné provozní artefakty ``` U jiné než softwarové agendy nahradí `src` odpovídající materiály nebo odkazy na ně. Povaha obsahu je otevřená. Podstatná je rozlišitelnost rolí, kontextu, úkolů a provozních artefaktů, nikoli konkrétní strom adresářů. ### Zdroje a technické opory Koncepce a tvrzení o Promptbooku vycházejí z podkladového popisu Pavola Hejného z 2. října 2026. Následující primární zdroje dokládají pouze odkazované vlastnosti Gitu a souvisejících přístupů, nikoli implementaci Promptbooku. Ověřeno 2. října 2026. [1] Git / Pro Git. **What is Git?** Snímky verzovaných souborů. https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F [2] Git. **git-commit — Record changes to the repository.** Obsah indexu a vytvoření commitu. https://git-scm.com/docs/git-commit [3] Git. **git-revert — Revert some existing commits.** Obracení změn, nové commity a konflikty. https://git-scm.com/docs/git-revert [4] AGENTS.md. **Otevřený formát instrukcí pro kódovací agenty.** Projektové a lokální instrukce. https://agents.md/ [5] OpenGitOps. **GitOps Principles, v1.0.0.** Deklarativní a verzovaný stav, automatické načítání a průběžné slaďování. https://opengitops.dev/