Publikováno 15. července 2026 · Aktualizováno 23. července 2026

Jak jsem z e-mailového agenta postavil AI vrstvu pro celý online business

Produkční case study: e-mailový agent, několik RAG kolekcí, FAPI, Stripe, MioWeb a MCP servery nad jednou průběžně aktualizovanou datovou vrstvou.

Nezačal jsem vizí, že chat jednou nahradí všechny aplikace. Začal jsem konkrétním problémem klienta, který prodává online videokurzy.

Klient dostává velké množství e-mailů. Lidé se ptají, který kurz je pro ně vhodný, co přesně obsahuje aktuální nabídka, kde najdou přístup nebo proč se nemohou přihlásit do členské sekce. Do toho se mění ceny a akce, vznikají nové produkty a část nabídek patří partnerům, se kterými spolupracuje — například u doplňků stravy.

Správná odpověď proto není jen hezky napsaný text. Musí zohlednit aktuální produkt, platbu konkrétního zákazníka, přístup do členské sekce, obchodní pravidla i obsah, který už klient publikoval.

Postavil jsem a nasadil systém, který tyto informace spojuje. Nejdřív jsem postavil e-mail agenta připravující koncepty odpovědí. Postupně jsem ale zjistil, že jeho nejcennější část není samotné generování e-mailu. Je to vrstva aktualizovaných znalostí, integrací a bezpečně vymezených nástrojů pod ním.

Dnes stejnou vrstvu používá nejen e-mailový agent, ale i soukromé MCP servery a support chatbot na webu.

První produkční use case: e-mailový agent

Když přijde nový e-mail, agent nejdřív určí, co člověk skutečně potřebuje. Podle typu dotazu pak nesahá do jednoho univerzálního promptu, ale vybírá správné zdroje.

Pokud má zákazník problém s přihlášením, agent může ověřit:

kdo zákazník je a pod jakým e-mailem nakupoval;
které objednávky a faktury má ve fakturačním systému;
jestli platba prošla přes Stripe;
které kurzy skutečně zaplatil;
do jaké části webu a členské sekce má mít v MioWebu přístup;
jaký je správný postup pro obnovení nebo opravu přístupu.

Z těchto faktů připraví návrh odpovědi rovnou do e-mailu. Nic automaticky neodesílá. Člověk koncept zkontroluje, případně upraví a teprve potom odešle.

U produktového dotazu je postup jiný. Agent hledá v aktuálních popisech kurzů, pravidlech nabídek, cenách, bonusech a probíhajících akcích. Když se člověk zatím nechce rozhodnout pro placený produkt, může nejdřív doporučit relevantní článek nebo konkrétní video zdarma.

Tohle už není experiment nad několika ukázkovými dokumenty. Systém je nasazený v reálném provozu, pracuje s živými dotazy a musí zvládat nepořádek, který v ukázkovém demu obvykle není: různé e-mailové adresy, více nákupů, staré nabídky, partnerské produkty, změny cen i neúplně položené otázky.

Ve skutečnosti nejde o jednu RAG databázi

Na začátku by bylo lákavé nahrát všechno do jedné vektorové databáze a nechat model, ať si poradí. Po nasazení se ale rychle ukáže, že jednotlivé typy znalostí mají jinou autoritu, jiný způsob aktualizace a jiný účel.

Proto jsem obsah rozdělil do samostatných kolekcí.

1. Produkty, nabídky a obchodní pravidla

První kolekce obsahuje produktové informace z webu a relevantní obsah z Facebooku: popisy kurzů, ceny, bonusy, probíhající akce, pravidla jednotlivých nabídek i informace o partnerských produktech.

To je zdroj pro otázky typu:

„Co obsahuje tento kurz?“
„Platí ještě sleva?“
„Je produkt vhodný i pro začátečníka?“
„Které bonusy dostanu k této variantě?“

Tahle kolekce se musí průběžně aktualizovat. Cena nebo akce, která platila minulý měsíc, nesmí být dnes použita jen proto, že má vysokou podobnost s dotazem.

2. Blogové články

Druhá kolekce obsahuje články, které klient napsal. Slouží nejen e-mailovému agentovi, ale také při tvorbě nového obsahu.

Klient se může zeptat, co už o tématu publikoval, jaké argumenty používal nebo které starší texty by nový článek zbytečně opakoval. Stejný zdroj pomáhá agentovi doporučit nejdřív užitečný obsah zdarma místo okamžitého prodeje kurzu.

3. Videa a jejich přepisy

Třetí kolekce obsahuje videa, metadata a přepisy. Díky tomu systém nehledá jen podle názvu videa, ale podle toho, co v něm skutečně zaznělo.

Agent může doporučit video odpovídající konkrétnímu problému a ideálně odkázat rovnou na relevantní pasáž. To je mnohem užitečnější než poslat člověku obecný seznam deseti videí a nechat ho, aby si správnou odpověď našel sám.

RAG není databáze, kterou jednou naplním

Nejdůležitější část systému není embedding model. Je to aktualizační proces.

Web se mění, přibývají články, na Facebooku vznikají nové nabídky, videa dostávají nové přepisy a staré produkty přestávají být aktuální. Každý záznam proto potřebuji spojit s původním zdrojem, typem obsahu, časem poslední změny a stabilním identifikátorem.

Kde je to možné, změnu zachytí webhook. Vedle toho běží pravidelná synchronizace, která porovnává zdroj s obsahem v indexu. Změněné položky znovu zpracuje, nové přidá a odstraněné nebo neplatné označí tak, aby je agent nepoužíval jako aktuální pravdu.

Produkční RAG pro mě není hromada textu převedená na vektory. Je to spravovaná znalostní vrstva, u které dokážu odpovědět:

odkud informace přišla;
kdy byla naposledy ověřena;
jestli jde o aktuální nabídku, nebo historický obsah;
který systém je pro daný typ informace autoritativní.

Některá data do RAG vůbec nepatří

RAG se hodí pro obsah a znalosti. Nehodí se jako zdroj pravdy pro aktuální stav platby, faktury nebo přístupu uživatele.

Tyto informace agent zjišťuje až v okamžiku dotazu přes API:

FAPI pro objednávky, faktury a účetní operace;
Stripe pro stav plateb a transakcí;
WordPress a MioWeb pro obsah webu, účty a přístupy do členské sekce.

Rozdíl je zásadní. Obecná otázka „co kurz obsahuje?“ může jít do znalostní kolekce. Otázka „zaplatil tento člověk kurz a má mít přístup?“ musí jít do živého systému.

Agent pak skládá odpověď z obou vrstev. RAG mu řekne, jak produkt funguje a jaký je správný postup. API mu řekne, co se skutečně stalo konkrétnímu zákazníkovi.

Z e-mailového agenta vznikla znovupoužitelná infrastruktura

Když e-mailový agent začal fungovat, došlo mi, že jsem nepostavil jen automatizaci schránky. Měl jsem už hotovou většinu těžké práce:

aktualizované znalostní kolekce;
konektory do FAPI, Stripe, WordPressu a MioWebu;
pravidla, který zdroj má přednost;
nástroje s přesně definovanými vstupy a výstupy;
autentizaci, audit a kontrolu rizikových akcí.

Byla by škoda tuto infrastrukturu uzamknout v jediném workflow. Proto jsem nad vybranými částmi postavil vzdálené MCP servery běžící na Hetzner VPS.

Model Context Protocol umožňuje nabídnout data a operace různým AI klientům přes společné rozhraní. Klient se nemusí učit interní strukturu FAPI ani vědět, kde je uložený videoarchiv. Vidí jen konkrétní nástroje, například:

najít faktury zákazníka;
ověřit duplicitní platbu;
připravit storno faktury;
zjistit zakoupené kurzy a dostupné přístupy;
vyhledat články k tématu;
doporučit relevantní video;
porovnat nový text s dříve publikovaným obsahem.

Přístup k serveru je chráněný přes standardní OAuth/OIDC tok. Každý klient a uživatel dostává jen oprávnění, která potřebuje. Nástroj pro práci s obsahem nemusí umět stornovat fakturu a veřejný chatbot nemá důvod vidět zákaznické objednávky.

FAPI ovládané přes konverzaci

Jedním z praktických výsledků je možnost pracovat s FAPI z chatovacího klienta.

Místo proklikávání administrace se klient může zeptat:

Najdi zákazníka podle e-mailu, zkontroluj, jestli nezaplatil dvakrát, a připrav storno duplicitní faktury.

MCP server zavolá přesně vymezené operace nad FAPI, vrátí nalezené doklady a připraví další krok. Zápisová akce není obecný přístup k API. Má vlastní validaci, auditní záznam, ochranu proti dvojímu provedení a před skutečným stornem vyžaduje potvrzení.

To je pro mě důležitý rozdíl mezi chatem napojeným na data a systémem, který se dá bezpečně používat. Model nerozhoduje, jaký libovolný HTTP požadavek pošle. Vybírá z malé sady operací, jejichž chování jsem předem definoval.

Stejná data, další rozhraní

Nad stejnou infrastrukturou dnes fungují další vstupy.

Obsahový asistent v ChatGPT

Při psaní nového článku se klient může zeptat, co už o tématu napsal, které video se k němu hodí nebo zda nový text není v rozporu s aktuální nabídkou. MCP server použije stejné kolekce článků a videí jako e-mailový agent.

Nevzniká další kopie znalostí, která by se musela samostatně udržovat. Mění se rozhraní a oprávnění, ne zdroj pravdy.

Na webu je support chat, který přes FastAPI server volá vybranou znalostní kolekci. Návštěvník může položit otázku běžným jazykem a dostat odpověď založenou na aktuálním obsahu.

Veřejný widget má samozřejmě jinou sadu možností než soukromý e-mailový nebo účetní agent. Umí pracovat s produktovými informacemi a doporučovat obsah, ale nedostane přístup k fakturám ani k cizím zákaznickým údajům.

Notebook, telefon nebo jiné AI rozhraní

Hlavní výhoda oddělené MCP a API vrstvy je, že nejsem závislý na jedné aplikaci ani jednom zařízení. Ke stejným schopnostem se můžu připojit z notebooku, z webového chatu nebo z telefonu — podle toho, co konkrétní klient právě podporuje.

Business logika neběží v notebooku. Běží na serveru. Zařízení je jen vstupní rozhraní, takže nemusím na každém z nich znovu řešit integrace do FAPI, Stripe nebo databáze.

Co běží dnes a co je další krok

Dnes systém umí číst e-maily, hledat v oddělených znalostních kolekcích, ověřovat živá data v připojených službách a připravovat koncepty odpovědí. Vybrané interní funkce jsou dostupné také přes vzdálené MCP servery a veřejná část znalostí přes support widget.

Další krok není přidat další chatovací bublinu. Chci zlepšit způsob, jakým se výsledky zobrazují.

Mám například nástroj napojený na webovou analytiku a reklamní systémy. Na otázku „jak si vedla reklama tento měsíc?“ dnes může vrátit data a slovní shrnutí. Přirozenější by ale byl interaktivní graf s filtrem období a možností rozkliknout konkrétní kampaň.

Podobně u faktury nechci vždy jen textový výpis. Užitečnější může být náhled dokumentu nebo formulář s jasně označenou změnou před potvrzením. U doporučeného videa by dával smysl přehrávač otevřený rovnou na relevantním čase.

MCP Apps: když chat potřebuje graf, formulář nebo náhled

Od ledna 2026 jsou MCP Apps oficiálním rozšířením protokolu. MCP nástroj už nemusí vracet jen text nebo strukturovaná data. Může dodat interaktivní uživatelské rozhraní, které podporovaný klient zobrazí přímo v konverzaci.

Pro můj systém to otevírá několik konkrétních možností:

graf prodejů, návštěvnosti nebo výkonu reklamy;
náhled faktury před stornem;
formulář pro kontrolu údajů před zápisem;
přehrávač videa otevřený na relevantní pasáži;
dashboard kombinující data z více systémů;
vícekrokové schválení citlivé operace.

Konverzace tak nemusí grafické rozhraní odstranit. Může ho sestavit podle aktuálního záměru. Když je nejlepší odpovědí věta, vrátí větu. Když je lepší graf, dokument nebo formulář, zobrazí správnou komponentu.

Podpora zatím není ve všech klientech a na všech zařízeních stejná. Dokumentace OpenAI k developer mode a MCP Apps v červenci 2026 uvádí, že plná MCP podpora včetně zápisových akcí se zavádí v beta režimu pro ChatGPT Business, Enterprise a Edu. MCP Apps jsou v ChatGPT dostupné na webu, ne v mobilní aplikaci; uživatelé Pro mohou v developer mode připojit vlastní MCP pro čtení a vyhledávání, ale ne pro plné zápisové akce.

Proto držím dlouhodobou architekturu oddělenou od momentálních omezení konkrétního klienta. MCP server, RAG kolekce a integrační vrstva mohou zůstat stejné. Nad nimi se může měnit ChatGPT, vlastní MCP klient, webový widget nebo jiné rozhraní.

Pokud bude podpora v používaných klientech dostačující, postavím vizuální výstupy jako MCP Apps. Pokud ne, stejná data může zobrazit vlastní klient. Důležité je, že analytika, oprávnění a business logika už existují na serveru a nemusím je stavět znovu.

Bezpečnost není vlastnost protokolu

MCP standardizuje, jak klient objeví a zavolá nástroj. Sám o sobě ale nezaručuje, že je nástroj bezpečný.

V systému proto odděluji veřejná a interní data, čtení a zápis i jednotlivé role. Citlivá operace má co nejmenší rozsah, ověřuje vstupy, zapisuje audit a před provedením ukáže člověku, co přesně se stane. Pro akce jako storno faktury je důležitá také idempotence, aby opakované volání nevytvořilo druhou změnu.

Stejně důležité je bránit se prompt injection. Text stažený z webu, e-mailu nebo dokumentu je nedůvěryhodný vstup, ne instrukce s právem změnit chování agenta. Doporučení pro autorizaci, správu tokenů a práci s rizikovými vstupy shrnují také bezpečnostní doporučení MCP.

Co jsem si z produkčního nasazení odnesl

Nejtěžší část nebyla napsat prompt, který vytvoří pěkný e-mail. Nejtěžší bylo rozhodnout, odkud se bere pravda, jak se aktualizuje a co přesně smí který nástroj udělat.

Fungující systém stojí na poměrně obyčejných věcech:

obsah je rozdělený podle účelu a autority;
aktuální transakční data se čtou z API, ne ze starého indexu;
znalostní kolekce se průběžně synchronizují;
jeden zdroj pravdy používá více specializovaných rozhraní;
zápisové akce jsou úzké, auditované a potvrzované člověkem;
klient se může změnit, aniž bych přepisoval business logiku.

Chat je v tomto systému viditelná špička. Skutečná hodnota je pod ním: živá znalostní vrstva, napojení na firemní systémy, jasná oprávnění a nástroje navržené pro konkrétní práci.

Právě díky tomu dnes stejný základ nepřipravuje jen e-mailové koncepty. Umí odpovídat návštěvníkům webu, pomáhat s obsahem, kontrolovat zákaznické nákupy a přes MCP zpřístupnit vybrané operace tam, kde je klient právě potřebuje — na notebooku, ve webovém chatu nebo postupně i v dalších rozhraních.