Nejasné workflow selhává dřív než model

Letaido ukazuje, jak bez vývoje a deploymentu postavit marketingové AI workflow v prohlížeči. Od napojení dat přes Ahrefs až po automatizaci: úzce, prakticky a bez zbytečného chaosu.

---

Vy řešíte reporting, monitoring konkurence nebo obsahové workflow, ale nechcete čekat na vývojáře ani řešit deployment. V článku o Letaido a Ahrefs, s odkazem na Canvu, ukazujeme praktičtější cestu: browserový AI workspace bez instalace, správy souborů a nočního běhu notebooku. Některé ukázky stojí na datech z Ahrefs, takže bez zdroje nepůjdou univerzálně.

Proč je těžké začít se stavbou AI workflow pro marketing

Na začátku narážíme na to, že běžné nástroje čekají práci se soubory, terminálem a nasazením na server. Pro marketingové workflow to ale nepotřebujeme, pokud stavíme reporty, sledování konkurence, shlukování klíčových slov nebo obsahové postupy.

V ukázce z Canvy je vidět, že ani týden věnovaný AI nemusí stačit k tomu, abychom věděli, kde začít. Proto si hned na úvod vymezíme jen praktický cíl: postavit workflow, které marketing opravdu používá.

Pak už můžeme pokračovat k tomu, jaký typ řešení dává smysl.

Typ řešení v prohlížeči a co nám odpadá

Navážeme na první krok a vymezíme si pracovní prostor v prohlížeči bez lokálního vývoje. Z popsaného setupu vyplývá, že nemusíme instalovat nic navíc, spravovat soubory ani nechat notebook běžet přes noc.

Současně tím přebíráme hosting i tajemství do platformy. Tím snižujeme riziko vystavených API klíčů a náhodných veřejných zpráv.

Právě proto nám odpadá editor, Git i klávesové zkratky pro vkládání. Na https://letaido.com/ pak pracujeme přímo v prostředí, které řeší provoz za nás.

Základní předpoklady, cena 99 $ a rozdíl mezi Konzolí a veřejnou stránkou

Než začneme stavět, potřebujeme aktivní účet Ahrefs a počítat s tím, že data agent čte z projektu Ahrefs podle našeho plánu.

Platforma stojí 99 $ měsíčně a zahrnuje i AI kredity v hodnotě 50 dolarů, ale limity dat zůstávají vázané na náš plán v Ahrefs.

Interní data držíme v Konzoli. Veřejná stránka je URL, kterou může kdokoli najít, a Google ji může indexovat. Před zveřejněním proto kontrolujeme, co pouštíme ven.

Výstupem kroku je jasno v nákladech, závislosti na Ahrefs a v tom, co zůstane interní a co bude veřejné.

Nastavení účtu, organizace a týmu

Navážeme na volbu pracovního prostoru a otevřeme letaido.com. Přes tlačítko Začít se zaregistrujeme a vytvoříme účet.

Pak pojmenujeme organizaci. Zvolená subdoména se zároveň stane URL pracovního prostoru, takže ji volíme hned přesně.

Nakonec pozveme tým. Místa jsou neomezená a zdarma, takže přidáme všechny, kdo budou pracovní prostor používat.

Tím získáme připravený prostor pro další nastavení workflow.

Volba modelu podle ceny, rychlosti a kvality

V Letaido přepínáme mezi Claude, GPT, Gemini a dalšími modely z rozbalovací nabídky bez samostatného předplatného nebo API klíčů. Tím si hned zjednodušíme provoz.

Model vybíráme podle kvality, rychlosti a ceny. Na mechanické úkoly nasazujeme levnější model, protože ušetříme kredity. Podle uvedených cen stojí GPT-5.4-mini 3 centy, Claude Sonnet 4.6 24 centů a Claude Fable 5 38 centů za běh.

Největší model nepoužíváme na lehké úkoly. Stejně tak nerozjíždíme jeden obrovský chat přes nesouvisející zadání. Po dokončení úkolu začínáme nový chat, aby nám zůstala jen potřebná paměť a neplýtvali jsme kredity.

Z popsaného nastavení vyplývá, že při rozpočtu 50 dolarů zvládneme s GPT-5.4-mini zhruba 1 600 běhů, s Claude Sonnet 4.6 asi 200 a s Claude Fable 5 kolem 130. Tím si předem ověříme, jak hluboko nám model sáhne do kreditní spotřeby.

Přesně tímto způsobem se připravíme na další krok, kde už budeme řešit režim Chat.

Režim Chat pro odpovídání a diskusi

V režimu Chat necháváme agenta odpovídat a diskutovat, ale nechat ho stavět nepoužíváme. Tím držíme práci v rovině průběžného upřesňování a neplýtváme na úkol, který má zůstat jen v dialogu.

Když potřebujeme pokračovat v debatě, zůstáváme v Chatu. Jakmile chceme začít stavět, přepneme do jiného režimu; právě tak oddělíme diskusi od práce na výstupu. To je výsledek, který si z tohoto kroku odnášíme.

Režim Build pro vytvoření nebo úpravu výstupu

V režimu Build pracujeme tehdy, když chceme něco vytvořit nebo změnit. Necháváme agenta, aby úkol naplánoval a dodal výslednou podobu. Tím přesně oddělíme stavbu od pouhé diskuse.

Build tedy používáme pro konkrétní výstup, ne pro obecné upřesňování. Jakmile chceme začít tvořit nebo upravovat, přepneme sem a získáme hotovou věc, se kterou můžeme dál pracovat.

Režim Analyze pro zpracování dat a získání poznatků

V režimu Analyze pracujeme s daty tak, abychom z nich dostali poznatky. Nepoužíváme ho pro stavbu nového softwaru.

Tím jasně oddělíme analytickou práci od režimů, které slouží ke stavbě nebo plánování. Pro další krok pak navážeme už bez míchání těchto úloh.

Režim Plan pro zjištění co a jak před stavbou

V režimu Plan nejdřív zjišťujeme, co a jak, než začneme cokoli stavět. Tím si vyjasníme postup ještě před samotnou realizací.

Plan používáme tehdy, když potřebujeme nejprve promyslet zadání a až potom přejít k práci. Z tohoto kroku si odnášíme jasný plán dalšího postupu.

Jakmile máme směr vyjasněný, navážeme dalším režimem.

Režim Brainstorm pro hledání možností a směrů

V Brainstormu necháváme agenta generovat varianty a směry bez okamžitého závazku. Tím získáme prostor pro hledání, aniž bychom se hned vázali na jednu cestu.

Výstupem je sada možností, se kterou pak můžeme dál pracovat v dalším režimu. Tady ještě nic nestavíme ani definitivně nepotvrzujeme; jen si rozšiřujeme pole volby.

To nám dává jasný přechod k dalšímu kroku, kde už budeme řešit režim Auto.

Režim Auto pro automatický výběr správného postupu

V režimu Auto necháme systém přečíst záměr a vybrat vhodný postup sám. Když v chatu potřebujeme něco vytvořit, Auto nám nabídne přepnutí bez ručního rozhodování.

Tím zkrátíme cestu od zadání k akci. Nepřepínáme zbytečně mezi režimy ručně a držíme se toho, co systém podle záměru vyhodnotí jako nejvhodnější.

Jakmile chceme pokračovat ve stavbě, vezmeme nabídnutý přechod jako signál k dalšímu kroku. Tím navážeme na práci bez prodlevy a bez míchání úloh.

Paměť pro opakující se kontext

Do paměti ukládáme jen to, co agent potřebuje při každém spuštění. Z popsaného setupu vyplývá, že ji čte na začátku každého chatu z ~/workspace/.memory.md.

Držíme v ní jen minimum, například opakující se slovní zásobu nebo stylistická pravidla. Vlastní firemní kontext tím často překoná externí zdroj, protože obsahuje detaily, které model nezná z tréninku.

Nezahlcujeme ji dalšími informacemi. Každá zbytečná položka znamená víc utracených tokenů, takže paměť udržujeme stručnou a další obsah přesouváme jinam.

Tím připravíme čistý základ pro další krok.

Týmová wiki pro hlubší a příležitostný kontext

Do týmové wiki ukládáme znalosti, které potřebujeme jen občas nebo je chceme mít rozpracované do hloubky. Slouží nám jako sdílená báze pracovního prostoru pro rozhodnutí, soubory konkurence, designové podklady nebo specifické projekty.

Od paměti ji držíme odděleně. Paměť používáme pro to, co Letaido potřebuje při každém spuštění. Wiki naopak plníme tím, co stačí čerpat příležitostně.

Tím si udržíme minimum v paměti a zbytek přesuneme do wiki, kde ho můžeme dohledat podle potřeby. Další krok na to naváže už prací s opakovatelným postupem.

Dovednost pro opakovatelný postup a formát výstupu

Know-how, které bychom jinak pokaždé znovu vysvětlovali, zabalíme jako dovednost. Agent ji čte na požádání a použije ji vždy stejně.

Nejrychlejší start získáme tím, že dovednost zkopírujeme z knihovny Ahrefs a přizpůsobíme ji našemu použití. Tím rovnou dostaneme použitelný základ místo psaní od nuly.

Držíme ji odděleně od aplikace, zprávy, artefaktu i automatizace. Tím navážeme na další krok bez míchání typů výstupů.

Aplikace pro klikací interaktivní práci

Aplikaci vytváříme tehdy, když potřebujeme klikací nástroj pro interaktivní práci. Z popsaného setupu vyplývá, že ji agent sestaví tak, aby četla databáze, volala konektory a zobrazovala výsledky.

Jakmile má výstup reagovat na naše kliknutí, volíme aplikaci. Tím držíme tento typ zvlášť a nemícháme ho s ostatními formáty výstupu.

Pro navazující krok si necháváme prostor pro další typ výstupu a pokračujeme bez přehazování stejné práce mezi více režimy.

Zpráva jako živý read-only pohled na data

Zprávu používáme tehdy, když chceme jen číst aktuální data. Při každém otevření načte čerstvá čísla, takže pracujeme s živým pohledem, ne s jednorázovým výstupem.

Držíme ji samostatně a neslučujeme ji s aplikací, dovedností, artefaktem ani automatizací. Tím zůstane jasné, že zpráva slouží k průběžnému nahlížení do dat a ne k interakci nebo spuštění plánu.

Na další krok navážeme už jiným typem výstupu, protože právě tady končí read-only režim a začíná jednorázová momentka.

Artefakt jako zmrazený výstup

Artefakt používáme tehdy, když potřebujeme jednorázovou momentku, která se po vytvoření už nemění. Tím ho držíme odděleně od zprávy, aplikace, dovednosti i automatizace.

V praxi si hlídáme, že artefakt není živý pohled ani klikací nástroj. Jakmile má výstup zůstat statický, zvolíme právě tento režim a nevracíme ho zpět do jiných forem.

Tím navážeme na další krok bez míchání typů výstupů a připravíme si prostor pro automatizaci, která už běží sama podle plánu.

Automatizace podle plánu

Automatizaci přidáme tehdy, když má úkol běžet bez našeho zásahu. Můžeme ji vytvořit s agentem nebo ji nastavit ručně.

Držíme ji jako samostatný typ výstupu a neslučujeme ji se zprávou, aplikací, dovedností ani artefaktem. Tím jasně vymezíme úkol, který se spouští sám v určený čas.

V praxi nastavíme plán tak, aby běžela podle rozvrhu, například každé pondělí v 9 hodin. Když má úkol fungovat bez nás, volíme automatizaci a necháme ji běžet sama.

Jak přidat konektor a schválit přístup

Konektor přidáváme přes chat tak, že agentovi řekneme, který konkrétní konektor chceme připojit. Tím mu dáme přístup k externím nástrojům a datům, včetně čtení i akcí.

Pak vložíme API klíče a odeslání potvrdíme. Z popsaného postupu vyplývá, že konektor se po schválení objeví v Ovládání → Schváleno a můžeme ho kdykoli zrušit.

Po jednorázovém připojení agent při zadání úkolu ví, co má dělat, a pracuje s konektorem v pozadí. Tím navážeme na další krok bez ručního obcházení dat.

Jak přesně určit požadovaný výstup v promptu

V první větě promptu pojmenujeme hotový výstup co nejkonkrétněji. Nepsali bychom neurčité zadání, ale rovnou řekli, co má model dodat.

Tento prvek necháváme samostatně. Neslučujeme ho s dalšími částmi promptu, aby bylo jasné, jaký výsledek od workflow chceme.

Takto navážeme na další krok, kde už budeme řešit, odkud mají data pocházet.

Odkaz na datový zdroj v promptu

Druhou část promptu věnujeme jen tomu, odkud mají data pocházet. Píšeme to samostatně a bez slučování s ostatními částmi zadání.

Uvedeme konkrétní zdroj, například konektor, soubor nebo stránku k procházení. Tím přesně vymezíme, s čím má workflow pracovat.

V praxi bereme fakta z konektoru nebo souboru a necháváme paměť stranou. Nepožadujeme, aby model metriky vyvolával z hlavy.

Tím připravíme přesný datový základ a můžeme navázat na další část promptu, kde doplníme instrukce a omezení.

Instrukce a omezení v promptu

Třetí část promptu držíme odděleně a vypíšeme v ní kroky, hranice, co porovnat, co ignorovat a co ponechat beze změny. Tím uzavřeme zadání do jasných pravidel.

Nejasné zadání si vyžádá upřesnění. My proto raději uvedeme konkrétní formát výstupu, řekneme, co model nemá dělat, a když není stavba jasná, požádáme o plán.

Takto připravíme prompt na přesnou práci a plynule navážeme na další krok, kde už budeme řešit samotné zmapování dat.

Seznam nástrojů a konkrétních datových bodů

Než něco stavíme, sepíšeme všechny nástroje, aplikace a stránky, které v práci používáme. U každé položky hned doplníme, s jakými daty pracujeme a kde se nacházejí.

Nekončíme u obecného označení typu SEO data. Místo toho pojmenujeme konkrétní datové body, například pozice klíčových slov, kliknutí na stránku nebo denní zobrazení.

Tím získáme přesný seznam vstupů pro další krok a můžeme plynule navázat na napojení dat přes konektory.

Konektory pro nástroje v dostupném seznamu

Druhým způsobem napojení dat v Letaido jsou konektory. Použijeme je tehdy, když je nástroj v dostupném seznamu, a tím získáme přímý přístup bez dalšího obcházení dat.

V praxi nejdřív ověříme, jestli náš nástroj mezi konektory skutečně je. Pokud ano, napojíme ho tímto způsobem a necháme workflow pracovat s daty přímo přes konektor.

Tím oddělíme tento postup od API klíčů i web scrapingu. Pro další krok pak přejdeme k napojení přes API klíče, kde už budeme řešit jiný typ přístupu.

API klíče pro napojení dat mimo dostupné konektory

API klíče použijeme ve chvíli, kdy nástroj nenajdeme v dostupném seznamu konektorů. Tím si držíme samostatný způsob přístupu a nesmísíme ho s jinými variantami napojení dat.

V praxi tím doplníme druhou cestu, jak dostat data do Letaido. Nejdřív ověříme, jestli konektor existuje; pokud ne, sáhneme po API klíči.

Tím uzavřeme napojení dat přes přímý přístup a plynule navážeme na web scraping, kde už půjde o další typ práce s daty.

Web scraping pro veřejné stránky bez přihlášení

Jako třetí způsob napojení dat použijeme web scraping. Tím vymezíme samostatnou cestu vedle konektorů a API klíčů.

Postup volíme jen pro veřejné stránky bez přihlášení. Z popsaného setupu sem patří například ceny konkurence, recenzní stránky nebo SERP.

Tím držíme zdroj dat odděleně a hned víme, kdy má smysl sáhnout po scrapingu. Na další krok navážeme výběrem prvního use case.

S čím začít jako první use case

Začneme jedním opakovaným workflow z vlastního kontextu. Nezakládáme hned tucet variant, protože cílem je mít jednu hotovou věc, kterou skutečně používáme.

Po registraci a propojení nástroje si vybereme malý postup, který už tým dělá pravidelně. Pak ho sepíšeme jako jednoduché kroky 1 až 5 a necháme Letaido, aby proces provedlo krok za krokem.

Na první verzi přidáme jen to, co projde našimi kvalitativními standardy. Tím získáme funkční základ, který můžeme dál zlepšovat bez zbytečného rozptylování.

Takto postavený první use case nám dá jasný výsledek a připraví půdu pro další krok.

Kontrola modelu, chatu, paměti a publikování

Po prvním nasazení zkontrolujeme, zda nepálíme kredity zbytečně. Největší model nenasazujeme na lehké úkoly.

Pak oddělíme nesouvisející práce do nových chatů. Jeden dlouhý chat přes různé úkoly držíme jen tehdy, když na sebe přímo navazují.

V paměti necháme jen minimum. Zbytek přesuneme do wiki, aby nám nerostla spotřeba tokenů.

Prompty kontrolujeme podle toho, jestli jasně určují výstup, data a omezení. Nejasný prompt vede k upřesňujícím dotazům a dalším korekcím.

Při publikování držíme interní data v Konzoli. Veřejnou stránku používáme jen tam, kde nevadí dohledatelnost a indexace veřejné URL. Výstup pak zkontrolujeme a teprve potom nastavíme automatizaci, protože AI nenahradí strategii, vkus ani vztahy.

Začít úzce a s daty, ne široce a naslepo

Když máme v Letaido postavit marketingový AI workflow od nuly, nevyhrává technická zručnost, ale disciplína. Začneme jedním opakovaným procesem, přesně ho popíšeme jako sled kroků, napojíme konkrétní data a teprve potom necháme automatizaci běžet. Tím získáme výstup, který je použitelný v praxi, místo dalšího obecného experimentu, který jen spotřebuje čas a kredity.

V praxi tím vyřešíme hlavní problém většiny startů: nejasné zadání, příliš široký záběr a chybějící datovou mapu. Když postup držíme úzce, hlídáme kvalitu výstupu, oddělíme práci od publikování a automatizujeme až ve chvíli, kdy víme, že workflow dává stabilní výsledky, začneme AI používat jako oporu marketingu, ne jako zdroj chaosu.

FAQ

Musíme mít nejdřív hotovou datovou architekturu?
Nemusíme. Stačí jeden konkrétní use case a jasně pojmenované vstupy. Datovou architekturu ladíme až ve chvíli, kdy víme, co workflow skutečně používá.

Kde týmy nejčastěji selžou?
Nejčastěji začnou příliš široce a bez přesného výstupu. Pak se míchá analýza, stavba i publikování v jednom chatu a výsledkem je zmatek a vyšší spotřeba.

Je lepší rovnou automatizovat, nebo nejdřív testovat ručně?
Nejdřív testujeme ručně. Automatizace má přijít až po kontrole výstupu, jinak jen zrychlíme chybu a budeme ji opakovat ve smyčce.

Má smysl používat nejvýkonnější model hned od začátku?
Většinou ne. Na jednoduché a opakovatelné úkoly nám stačí levnější model. Tím šetříme kredity a přitom si ověříme, jestli workflow funguje.

Co když nemáme všechna data v jednom nástroji?
To není problém. Napojíme nejdůležitější zdroj přes konektor, API nebo scraping, ale vždy jen pro data, která workflow opravdu potřebuje. Zbytek necháme stranou.

Zdroj: ahrefs.com

---