O AI agentech se dnes mluví hlavně v souvislosti se zákaznickou podporou a vývojem softwaru. Nás zajímala nudnější a možná užitečnější otázka: co by AI agent dělal jako běžný kolega v provozu menší firmy? Ne jako chatbot na webu, ale jako někdo, kdo jednou týdně objedná obědy, ráno pošle shrnutí a večer připraví podklady pro vedení.
Odpověď jsme si vyzkoušeli na zubní klinice. Vznikla Sindy, interní AI asistentka, se kterou si tým píše v chatu stejně jako s kýmkoli jiným. Je to prototyp postavený za pár týdnů, ne hotový produkt. Právě proto je na něm dobře vidět, co funguje, co ne a kde AI agent v provozu firmy opravdu dává smysl.
Co Sindy dělá
Sindy je tvář, kterou tým zná. Za ní běží malá platforma několika specializovaných agentů, kteří sdílejí data a nástroje:
- Obědy: každý týden zpracuje jídelníček od dodavatele, vypíše hlasování, v pondělí ráno uzavře objednávku, pošle ji dodavateli a na konci měsíce připraví rozúčtování.
- Reporty pro vedení: denní přehledy po oblastech (personál, provoz, finance, marketing), průběžný seznam otevřených bodů a pondělní shrnutí týdne pro celý tým.
- HR systém: HR agent pracuje s docházkovým a HR systémem kliniky přes jeho oficiální MCP server, pondělní report z něj bere odpracované hodiny.
- Běžná komunikace: v týmovém chatu Sindy odpoví, když ji někdo osloví, a občas krátce zareaguje na narozeniny nebo povedenou hlášku. Jinak mlčí.
Obědy: nejvděčnější případ užití
Objednávání obědů vypadá jako drobnost, jenže má pevný týdenní rytmus, termíny, e-maily s dodavatelem a spoustu malých výjimek. Celý tok je teď automatický:
- Dodavatel posílá jídelníček na další týden e-mailem jako Excel. Sindy denně v 16:00 kontroluje schránku a nový lístek zpracuje.
- Do týmového chatu pošle úvodní zprávu a pod ni hlasování na každý den (Po až Pá), úvodní zprávu připne, aby v historii neodjela.
- Změnové okno končí v pondělí v 7:00. Do té doby si každý může výběr měnit. Pak Sindy hlasy sečte, vygeneruje objednávku pro dodavatele a rozpis k tisku pro recepci, odešle je e-mailem a hlasování odepne.
- Každý pracovní den v 11:00 pošle krátký přehled, kdo má dnes jaké jídlo. Po celý pracovní den hlídá, jestli se po odeslání objednávky něco nezměnilo, a změny hlásí recepci e-mailem.
- Prvního v měsíci připraví rozúčtování za minulý měsíc v Excelu.
Nejzajímavější je obědová burza. Po uzávěrce je oběd zaplacený, takže se neruší, jen předává. Kdo nemůže, napíše Sindy, že oběd nechce, ona ho nabídne ostatním a první, kdo napíše „beru“, ho dostane. Převod se sám promítne do denního přehledu i do měsíčního rozúčtování.
Podstatné je, jak Sindy objednávky mění. Smí pracovat jen s objednávkou toho, kdo jí právě píše. Identitu neurčuje model z textu, ale nástroj z ID zprávy: zpráva, odesílatel, zaměstnanec. Příkaz na změnu cizí objednávky má Sindy v oprávněních výslovně zakázaný. A v personě má napsáno, že nesmí tvrdit „hotovo“, dokud nástroj nevrátí OK.
Reporty: z konverzací přehled pro vedení
Druhá polovina práce je analytická. Tým si během dne píše o směnách, porouchaném přístroji, docházejícím materiálu nebo dotazu pojišťovny. Z takových zpráv vedení nemá šanci udělat přehled. Sindy ano:
- Každou hodinu projde nové zprávy menší model (Claude Haiku) a roztřídí je na signály podle oblasti: personál, provoz, finance, marketing, ostatní. U každého určí důležitost a jestli je potřeba něco udělat.
- Každý večer ve 20:00 z nich větší model (Claude Sonnet) sestaví denní report za každou oblast a aktualizuje průběžný seznam otevřených bodů.
- V pondělí v 8:00 dostane celý tým shrnutí minulého týdne: kolik unikátních pacientů se ošetřilo, odordinované hodiny z ordinačního systému (jen agregáty, žádná jména), odpracované hodiny z HR systému a s nadsázkou i nejlepší „hlásiče týdne“ podle reakcí smajlíky.
Reporty se zobrazují na jednoduchém interním dashboardu, který poslouchá jen na localhostu a ven vede přes Cloudflare Tunnel s přihlášením přes Cloudflare Access. Finanční a marketingový agent navíc umí odpovídat na ad-hoc dotazy nad provozní databází kliniky, třeba vývoj nových pacientů po měsících, a výsledek poslat jako Excel.
HR systém a další agenti
Agenti mají jasně rozdělené role: HR, provoz, finance, marketing a správcovský agent, který se stará o samotnou platformu. Vedení s nimi mluví přes Claude Code Remote Control, tedy z prohlížeče nebo z mobilu, každý agent ve vlastní session a s vlastními oprávněními.
HR agent je napojený na oficiální MCP server HR systému kliniky. Data umí číst i měnit (třeba absence), ale v personě má, že zápis dělá jen na výslovný pokyn a se shrnutím změny předem. HR systém se hodí i jinde: Sindy přes něj páruje lidi v chatu se zaměstnanci, aby objednávka a rozúčtování nesly skutečná jména. Telefonní čísla se při tom používají jen interně k párování a do výstupu se nikdy nedostanou.
Pro pondělní report jsme ale z MCP přešli na REST API téhož systému. Dotaz v přirozeném jazyce přes MCP je pohodlný pro člověka, který se ptá. Pro report, který má každý týden vrátit stejná čísla stejným způsobem, potřebujete deterministické volání.
Jak je postavená
Na Sindy není nic exotického, a to je záměr:
- Linuxová VM v Azure, všechny procesy běží pod jedním neprivilegovaným uživatelem jako systemd služby a timery. Zmeškaný běh se po restartu VM dožene.
- Claude Code jako runtime agentů. Plánované úlohy volají
claude -pv neinteraktivním režimu, interaktivní agenti běží jako Remote Control sessions. Každý agent je adresář s instrukcemi a souborem oprávnění. - Jedna SQLite databáze (WAL) jako sdílená sběrnice: zprávy, hlasování, signály. Kolem ní jsou malé skripty v Node.js a Pythonu, platforma má dohromady zhruba 2 300 řádků kódu.
- Konverzační smyčka se dívá na nové zprávy každých 5 sekund, ale odpovídá až 20 sekund po poslední zprávě, aby nereagovala na půl myšlenky. Dostane posledních 30 zpráv jako kontext a vrátí buď akci, nebo
NOOP. Pojistkou proti zacyklení je limit 40 odeslaných zpráv za hodinu na agenta a session se každý den resetuje. - Přístup do provozní databáze jen pro čtení: přihlášení přes managed identity VM bez hesla, databázová role s read-only transakcemi a jen SELECT granty, timeout 20 sekund. Pojistku na straně skriptu bereme jako bonus, skutečná ochrana je v databázi.
Dva detaily, které považujeme za nejdůležitější. Zaprvé, před odesláním do modelu se z textu odstraní e-maily, telefonní čísla, rodná čísla a čísla pojištěnců. Zadruhé, instalace je rozdělená na neprivilegovanou část a root skript, který se instaluje jednou ručně a přijme jen systemd jednotky odpovídající pevným pravidlům. Agent, který běží pod stejným uživatelem jako platforma, si tak nemůže sám rozšířit práva.
Osobnost v Markdownu, pravidla v konfiguraci
„Osobnost“ agenta není nic tajemného. Je to několik Markdown souborů v repozitáři:
- Společná pravidla pro všechny agenty (nejmenovat pacienty, nevypisovat kontakty, nevymýšlet si, citovat zdroj).
- Krátká persona role pro večerní report, např. „provozní asistent manažera: seskupuj podle tématu, rozlišuj urgentní / tento týden / někdy“.
- Persona pro konverzaci: u Sindy „milá, přátelská a lehce vtipná, píše krátce, tyká, občas emoji, není upovídaná“. Hlavně ale obsahuje pravidla, kdy mluvit: odpověz, když tě někdo osloví; u výrazného společenského momentu smíš krátce zareagovat; jinak nedělej nic. Nikdy nepředstírej, že jsi člověk.
Instrukce pro každého agenta se z těchto dílů skládají jedním příkazem, takže se společná pravidla nekopírují ručně. Vedle persony leží soubor oprávnění: jaké příkazy agent smí spustit, kam smí zapisovat a co má zakázané (mazání, sudo, síťové nástroje, tajemství). Persona říká, jak se má agent chovat. Oprávnění určují, co technicky vůbec může udělat. Na první se dá spolehnout většinou, na druhé vždycky.
Co jsme se naučili
- Nejčastější chyby nedělá model, ale integrace. Jednou dorazily burgery místo špaget. Objednávku jsme posílali jako dodavatelovu šablonu přeuloženou knihovnou a Excel ji pak hlásil jako poškozenou. Dodavatel přílohu nepoužil a v těle e-mailu byla jen čísla jídel, která se u něj číslovala jinak. Řešením byl čistý nový sešit a názvy jídel přímo v těle e-mailu, aby objednávka byla jednoznačná i bez přílohy.
- Identita je těžší, než vypadá. Jeden člověk hlasoval ze dvou zařízení a prázdný výběr z jednoho přepsal objednávku z druhého. Teď vyhrává nejnovější skutečná volba a odznačení nic nepřepíše.
- Kde je potřeba stejný výsledek, patří deterministický kód. Párování jmen přes model mezi běhy kolísalo, a tak se jednou nalezené jméno drží a seznam se nepřepíše, když by nová verze měla jmen méně. Report bere čísla přes REST, ne přes konverzaci.
- Idempotence všude, kde se něco posílá ven. Uzávěrka obědů ukládá postup po krocích, takže po výpadku se objednávka dodavateli neodešle dvakrát.
- Provozní minimum od prvního dne: hlídač každých 10 minut kontroluje služby a disk a posílá e-mail, denní zálohy se drží 14 dní. Off-site kopie záloh je zatím na seznamu úkolů, k prototypu to poctivě patří.
Kdy to dává smysl (a kdy ne)
Sindy vznikla rychle: repozitář má 54 commitů, první je z 10. září 2026 a většina práce proběhla během prvního týdne. Rychlost ale nebyla v AI, nýbrž v tom, že jsme si vybrali úlohy s jasnými hranicemi.
Dává smysl, když se proces opakuje každý týden, má jasný začátek a konec (uzávěrka, report), vstupy už existují (e-mail, chat, databáze) a chyba je vratná nebo ji ještě před dopadem uvidí člověk. Obědy, týdenní přehledy a třídění provozní komunikace splňují všechno.
Nedává smysl tam, kde by agent rozhodoval o něčem nevratném bez lidské kontroly, kde chybí data, nebo kde jde o zdravotní či právní rady. Sindy má takové věci v personě výslovně zakázané a technicky k nim nemá přístup.
Pokud o podobném asistentovi uvažujete, začněte jedním nudným procesem, který dnes někoho stojí hodinu týdně. Zkuste napsat, co přesně má agent udělat, z jakých dat a kdo uvidí výsledek. Když to jde na půl stránky, je to dobrý kandidát. S návrhem a stavbou rádi pomůžeme, viz AI agenti a automatizace.