AI-native firma a druhý mozek podle Jana Tobolíka

Vytvořeno: 1.7.2026 | Aktualizováno: 01.07.2026 15:24

Tento zápisek vychází z videa Jak přejít na AI native firmu krok za krokem (Jan Tobolík). Rozhovor řeší, jak systematicky stavět firmu, ve které AI není jen chatbot bokem, ale pracovní vrstva nad firemními znalostmi, procesy a nástroji.

AI-native firma podle rozhovoru nevznikne tím, že zaměstnanci začnou používat ChatGPT nebo jiný chatovací nástroj. Podstatné je vytvořit systém, ve kterém má AI agent přístup k firemnímu kontextu, umí dohledat správné procesy, ví, kde jsou data, a dokáže z jednorázové zkušenosti udělat opakovatelný postup.

V rozhovoru se pro tento systém používají pojmy jako druhý mozek, AI operační systém firmy, Symbion AI, Covork OS nebo interně Kryton. Prakticky jde o verzovanou znalostní bázi nad Gitem, ve které jsou uložené firemní procesy, šablony, návody, skilly a pravidla práce.

Nejdůležitější principy:

• AI má pracovat nad jedním zdrojem pravdy, ne nad chaotickou sadou dokumentů.
• Do druhého mozku patří znalosti a procesy, ne samotná provozní data.
• Git dává firemním procesům verzování, historii, větvení a možnost návratu.
• Lidé se posouvají od přímého vykonávání práce k navrhování systému, briefování agentů a kontrole výstupů.
• Hodnota není v samotném generování textu nebo kódu, ale v architektuře, údržbě, kvalitě zadání a schopnosti rozpoznat špatný výstup.

Druhý mozek je centrální repozitář firemního know-how. Má být čitelný pro lidi i pro AI agenty, proto se v rozhovoru opakovaně zmiňuje Markdown jako vhodný základní formát.

V mozku jsou zejména:

• popisy procesů,
• workflow,
• šablony,
• skilly pro AI agenty,
• instrukce pro práci s firemními nástroji,
• routovací tabulky, které agentovi říkají, kde hledat relevantní kontext.

Naopak tam nemají být vlastní provozní data. Ve videu je to zdůrazněné jako zásadní architektonické pravidlo: druhý mozek obsahuje znalosti, nikoli data.

AI agent se na data napojuje přes API, MCP nebo jiné konektory. V mozku má být jen popis, kde data jsou a jak se s nimi má bezpečně pracovat.

To má několik důsledků:

• repozitář zůstává relativně čistý a bezpečnější,
• citlivá data neleží v systému, který má číst každý agent,
• procesy se dají verzovat bez toho, aby se verzovala provozní data,
• agent nemusí pro každý úkol procházet celé datové úložiště.

Jedna z nejsilnějších myšlenek videa je použití Gitu jako základu firemní paměti. Git se tu nebere jen jako nástroj pro programátory, ale jako mechanismus datové hygieny pro firemní procesy.

Přirovnání z rozhovoru: Git je jako sešit nebo zápisník moudrosti firmy. Když někdo potřebuje navrhnout změnu, nevezme celou knihu a nepřepíše ji přímo. Udělá si kopii listu, zapíše změnu a pak ji předá ke schválení někomu, kdo ji může spojit zpět do hlavní knihy.

V technickém jazyce:

• kopie listu = branch,
• žádost o začlenění změny = pull request,
• spojení změny do hlavní větve = merge,
• návrat k předchozímu stavu = revert.

• Verzování procesů: proces může mít verzi 1.0, 1.1, 1.2 a lze dohledat, co se změnilo.
• Historii rozhodnutí: je vidět, kdy a proč se měnily postupy.
• Možnost návratu: pokud se nový proces neosvědčí, dá se vrátit předchozí verze.
• Větvení: různí lidé mohou navrhovat změny bez přímého zásahu do hlavního repozitáře.
• Schvalování: změny nemusí jít rovnou do ostrého systému.
• Hygienu: snižuje se riziko, že se znalostní báze časem promění v neudržovaný chaos.

V rozhovoru zaznívá i srovnání s Obsidianem nebo podobnými systémy. Ty jsou na začátku jednodušší a příjemnější, ale podle Tobolíka mohou časem narazit právě na hygienu: dokumenty zastarávají, procesy se mění a bez dobrého verzování je těžké vědět, co platilo kdy.

Ve videu se mluví o několika stavebních prvcích druhého mozku. Nejde o jeden univerzální standard, spíš o praktický model, jak může vypadat repozitář pro AI agenta.

cloud.md
routing-table.md
stanoviste-a/
  zdroje/
  wiki/
  system/
  vystupy/
stanoviste-b/
  zdroje/
  wiki/
  system/
  vystupy/

Soubor typu cloud.md nebo podobná hlavní instrukce říká agentovi, co je cílem repozitáře. Například: že jde o sekundární mozek firmy, jaký problém řeší a jak má agent s uloženým kontextem pracovat.

Ve videu se zmiňuje, že různé nástroje mohou používat různé názvy hlavních instrukčních souborů. Podstatný je princip: agent musí mít na začátku jasně definované, co repozitář je a jakou roli má plnit.

Routovací tabulka je rozcestník pro agenta. Místo toho, aby agent při každém úkolu četl celý mozek, má dostat pravidla typu:

• když řešíš sales, načti tyto dokumenty a tyto skilly,
• když řešíš mzdy, použij tento proces,
• když řešíš marketing, načti brand manuál, barvy, tone of voice a šablony,
• když řešíš faktury, použij skill pro vytěžování a ověřování.

Tento princip šetří kontextové okno, tokeny a snižuje riziko, že agent použije nesouvisející informace.

Ve videu je popsaný praktický způsob členění pracovního prostoru:

• Zdroje: sběrné místo pro surové vstupy, poznámky, přepisy, dokumenty a další materiály.
• Wiki: přechroupané poznatky ze zdrojů do čitelnější struktury.
• Systém: procesy, skilly, postupy a šablony.
• Výstupy: pracovní a dočasné soubory, které agent generuje při řešení úkolu.

Složka vystupy je praktická ochrana proti tomu, aby agent nezačal ukládat do repozitáře náhodné Markdown soubory kamkoli. Ve videu zaznívá přirovnání ke kuchyni: při vaření vznikne binec, ale na stůl se má dostat čistý talíř. Stejně tak agent může tvořit pracovní soubory, ale do hlavní knihy mají jít až očištěné výsledky.

YAML hlavičky fungují jako kartotéka v knihovně. Agent si nejdřív přečte metadata dokumentu, zjistí, zda je relevantní, a teprve potom případně čte celý obsah.

Praktický význam:

• rychlejší orientace v rozsáhlém repozitáři,
• nižší spotřeba tokenů,
• menší riziko, že se do kontextu dostanou nerelevantní dokumenty,
• lepší udržovatelnost znalostní báze.

Zavedení druhého mozku není jen technický problém. Ve videu je silně přítomná otázka rolí a odpovědnosti.

Důležité je, že běžný uživatel nemusí vědět, co je Git. Může pracovat přes jednoduchou aplikaci nebo chat. Git, větve a pull requesty zůstávají v pozadí.

Ve videu se jako hlavní pracovní rozhraní zmiňují zejména Claude Code, OpenAI Codex, VS Code a vlastní nadstavby. V transkriptu se název Claude Code objevuje foneticky jako „Cloud Code“ nebo „cloud kód“.

Claude Code je ve videu popisovaný jako nástroj, který běžně funguje přes příkazovou řádku. Tobolíkovi ale nevyhovovalo čisté CLI rozhraní, proto si ho integroval do VS Code.

Výhody rozhraní ve VS Code:

• prostředí může vypadat podobně jako běžná aplikace nebo prohlížeč,
• lze pracovat se záložkami,
• lze nahrávat soubory a obrázky,
• builder má pořád přístup k souborům repozitáře,
• agent může upravovat Markdown dokumenty a pracovat se strukturou mozku.

Pro běžné uživatele je důležitá izolace. Ve videu je popsané sandboxové řešení na serveru, připravené v Dockeru nebo podobném izolovaném prostředí. Cílem je, aby uživatel neměl agenta spuštěného neřízeně nad celým lokálním počítačem.

Praktický model:

• prostředí běží na serveru,
• uživatel se přihlásí do připraveného rozhraní,
• přihlásí se ke GitHubu a agentnímu nástroji,
• agent pracuje nad repozitářem,
• uživatel komunikuje jen s chatem,
• Git a technické detaily jsou odstíněné.

Ve videu zaznívá, že takové prostředí lze ve firmě připravit rychle, ale důležitější než rychlost je bezpečnostní model: agent musí mít přístup jen tam, kam skutečně má mít přístup.

Interně je systém nazýván Kryton podle Červeného trpaslíka. Kryton je hlavní mozek, tedy repozitář se strukturami, procesy, workflow a šablonami.

Kocour je jednoduché uživatelské rozhraní pro lidi, kteří nepotřebují chápat Git ani technické pozadí. Mají jen komunikovat s aplikací a výsledek se má propsat do systému přes kontrolované workflow.

Nejpraktičtější příklad ve videu je řešení pojistné události po srážce se zvěří. Podstatné není samotné vyřízení pojistky, ale způsob, jak se z jednorázové situace stane opakovatelný firemní proces.

Přibližná formulace zadání z videa:

Měl jsem srážku se zvěří (srnka). Zařiď vše, co je potřebné.

Agent díky firemnímu kontextu zjistil, že jde o firemní auto, doptal se na konkrétní vůz, dohledal smlouvu, zjistil pojišťovnu a začal řešit potřebné kroky. Když chyběl záznam od policie, navrhl požádat datovou zprávou o číslo jednací a připravil zprávu.

Důležitý je následný krok: po vyřešení se celý postup uloží do interního mozku jako proces nebo skill. Příště už agent nemusí improvizovat od nuly, ale ví, jak se řeší srážka se zvěří u firemního auta.

Tento vzor je použitelný obecně:

1. začne to konkrétní situací,
2. agent ji s pomocí kontextu vyřeší,
3. člověk výstup zkontroluje,
4. z ad-hoc řešení se vytvoří proces,
5. proces se uloží do Gitu,
6. další člověk nebo agent ho může znovu použít.

Další silná část videa je metoda metaplánování. Nejde rovnou napsat aplikaci, proces nebo text. Nejdřív se staví plán, někdy dokonce plán na tvorbu plánů.

Přibližná formulace principu:

Zamysli se nad tím, jak správně postavit plán na implementaci tohoto úkolu.
Navrhni plán na vytvoření jednotlivých plánů.
Zvaliduj ho z více úhlů pohledu.

Tobolík popisuje, že u složitějšího projektu může mít metaplán, z něj vznikne sada dílčích plánů a ty se pak nechají znovu validovat. Důležité je, aby se dílčí plány mezi sebou „bavily“: bezpečnost, testování, implementace, architektura a provoz nesmí vznikat izolovaně.

Ve videu zaznívá příklad, kdy u většího technického úkolu strávil zhruba 15,5 hodiny plánováním a samotná implementace měla trvat jen několik hodin. Pointa není dělat těžkopádné plánování pro každou drobnost, ale u komplexních úkolů nepodlehnout dojmu, že když AI generuje rychle, lze přeskočit architekturu.

Metaplánování pomáhá zejména proti:

• chaotickému vibe codingu,
• nekontrolovanému růstu funkcí,
• dopaminové smyčce „ještě jeden prompt“,
• neudržitelnému kódu,
• plánům, které si protiřečí,
• agentům, kteří pracují dlouho špatným směrem.

Zajímavý postup je nechat plán zkontrolovat jiným modelem nebo z jiného úhlu pohledu. Například:

• bezpečnostní audit plánu,
• hledání logických děr,
• kontrola testovatelnosti,
• kontrola provozních nákladů,
• kritika architektury,
• hledání míst, kde agent pravděpodobně selže.

Tady se člověk posouvá do role manažera agentů. Nejde jen promptovat jeden model, ale stavět systém kontroly, validace a delegování.

Dobře nabriefovaný agent může pracovat dlouho samostatně. Ve videu zaznívá představa práce, kdy agent běží třeba dvě hodiny, uživatel má notifikaci a mezitím dělá jinou práci.

Aby to fungovalo, musí mít agent:

• jasné zadání,
• dostupný kontext,
• plán,
• hranice oprávnění,
• kritéria hotového výstupu,
• pravidla pro ukládání pracovních souborů,
• způsob, jak se má zastavit nebo zeptat.

Ve videu se rozlišuje používání AI přes předplatné a přes API.

Předplatné je výhodné pro běžného uživatele, protože náklady jsou předvídatelné. Ve videu zaznívá příklad osobního používání tarifu kolem 100 USD měsíčně a limitů, které se obnovují po několika hodinách. U základních tarifů se mluví o řádu desítek dolarů měsíčně.

Nevýhody:

• limity mohou dojít u intenzivní práce,
• firma dotuje používání uživatele,
• model nemusí být vhodný pro dlouhé automatizované běhy,
• každý nástroj má vlastní pravidla limitů.

API je vhodné pro agentní provoz a automatizace, ale vyžaduje disciplínu. Bez limitů může špatně napsaný agent nebo smyčka vygenerovat extrémní náklady.

Praktická pravidla:

• nastavit tvrdé finanční limity,
• logovat spotřebu tokenů,
• oddělit experimentální a produkční klíče,
• nepouštět neotestované agenty bez rozpočtového omezení,
• pro rutinní úkoly používat levnější modely,
• drahé modely používat hlavně na návrh, architekturu a kontrolu.

Silná myšlenka z rozhovoru: AI se má používat i k tvorbě deterministických nástrojů, které pak už AI nepotřebují.

Příklad s fakturami:

• drahá varianta: každou fakturu poslat do AI modelu,
• levnější a bezpečnější varianta: pomocí AI si vytvořit interní OCR nástroj, který běží lokálně a vytěžuje faktury algoritmicky.

Výhody deterministického řešení:

• neplatí se tokeny za každý běh,
• citlivá data nemusí odcházet ven,
• výsledek je předvídatelnější,
• nástroj lze testovat a provozovat jako běžnou aplikaci.

Ve videu se bezpečnost neřeší jako doplněk, ale jako nutná součást zavádění AI do firmy.

Hlavní varování:

• free verze AI nástrojů nepatří na citlivá firemní data,
• je potřeba vědět, kam data odcházejí,
• některá data by neměla odcházet mimo EU nebo mimo kontrolované prostředí,
• firmy potřebují interní pravidla používání AI,
• zaměstnanci musí rozumět rizikům,
• agent spuštěný nad lokálním počítačem může mít nebezpečně široký přístup.

V rozhovoru zaznívá AI Act, GDPR a NIS 2 jako rámce, kvůli kterým bude téma governance a bezpečnosti stále důležitější. Tento zápisek není právní výklad; je to praktická poznámka, že při firemním nasazení AI nestačí řešit jen produktivitu.

• Oddělit znalosti od dat.
• Citlivá data neposílat do free AI nástrojů.
• Používat enterprise tarify, API s vhodnými podmínkami nebo lokální modely tam, kde je to potřeba.
• Nastavit oprávnění agentů podle principu nejmenších práv.
• Používat sandbox pro netechnické uživatele.
• Vést audit toho, kdo používá jaké AI nástroje a na jaká data.
• Testovat vlastní weby, servery a aplikace na zranitelnosti.
• U agentních workflow logovat kroky a změny.
• Důležité procesy verzovat a schvalovat přes pull requesty.

Rozhovor se dotýká i toho, jak se mění cesta od juniora k seniorovi. Pokud AI převezme jednoduché úkoly, ubývá přirozených příležitostí, na kterých se lidé dřív učili.

Tobolíkova linka je zhruba tato:

• AI je skvělý učitel, pokud se jí člověk ptá proč a jak.
• AI je nebezpečná zkratka, pokud člověk jen kopíruje výsledek.
• Seniorita není v množství napsaného kódu, ale v porozumění architektuře, provozu a důsledkům.
• Junior se musí učit aktivně zevnitř, nečekat jen na úkoly zvenčí.

Výstižná myšlenka z videa: AI je lopata a člověk má být mozek, ne naopak. Pokud AI jen generuje a člověk přestane chápat souvislosti, systém bude křehký.

Možný postup zavedení druhého mozku ve firmě podle myšlenek z videa:

1. Vybrat malý pilotní use-case. Například opakovaný administrativní proces, který má jasný začátek a konec.
2. Zmapovat, co je znalost a co jsou data. Proces patří do mozku, konkrétní dokumenty do datového systému.
3. Založit Git repozitář. Na začátku stačí jednoduchá struktura v Markdownu.
4. Vytvořit hlavní instrukci. Soubor typu cloud.md popíše účel repozitáře a roli agenta.
5. Vytvořit routovací tabulku. Agent musí vědět, kam sáhnout pro sales, marketing, faktury, HR nebo technickou dokumentaci.
6. Oddělit pracovní výstupy. Agent má mít místo, kam může odkládat dočasné soubory, aniž by zanesl hlavní znalostní bázi.
7. Přidat YAML metadata. Dokumenty mají mít stručné hlavičky pro rychlou orientaci.
8. Nastavit role. Uživatel, builder, administrátor a vlastník procesu mají jiné odpovědnosti.
9. Nastavit schvalování změn. Do hlavní větve nemá zapisovat každý.
10. Připravit bezpečné rozhraní. Běžný uživatel nemá pracovat přímo s Gitem, ale přes chat nebo jednoduchou aplikaci.
11. Z první úspěšné akce vytvořit skill. Každé dobré ad-hoc řešení se má proměnit v opakovatelný postup.
12. Pravidelně čistit a refaktorovat. Druhý mozek je živý systém a bez údržby začne stárnout.

Nejcennější na videu není jeden konkrétní nástroj, ale způsob přemýšlení. AI-native firma není firma, která má všude chatbota. Je to firma, která má své znalosti a procesy ve struktuře, se kterou umí pracovat lidé i agenti.

Praktické takeaway:

• Git se dá použít jako verzovací systém firmy, nejen kódu.
• Druhý mozek má obsahovat postupy, ne citlivá data.
• Každý dobrý jednorázový postup se má stát skill nebo proces.
• Agenti potřebují routování, metadata a pracovní prostor.
• Bez governance vznikne AI chaos rychleji než produktivita.
• Dlouhé běhy agentů vyžadují dobré plány a kontrolní mechanismy.
• Člověk má zůstat architektem a hodnotitelem, ne pasivním příjemcem výstupu.

• Jak přejít na AI native firmu krok za krokem (Jan Tobolík)
• AI zápisy a workflow – cílová sekce wiki