Proč jsme kontext značky v Brew přesunuli z rigidního objektu do upravitelného dokumentu, který vysvětluje nejen přesné hodnoty, ale i designová rozhodnutí.
Hex kód e-mailovému agentovi řekne, jakou modrou má použít. Neřekne mu ale, proč značka nad každý nadpis dává malý popisek neproporcionálním písmem nebo proč jsou její oddělovače tenké čáry, a ne rámečky.
Přesně tohle byl problém našeho prvního modelu značky v Brew. Zachytili jsme spoustu hodnot, a stejně jsme přišli o detaily, podle kterých byla značka k poznání.
Když jsme začínali, vypadala značka jako strukturovaná data. Modelovali jsme barvy, typografii, podklady a velkou sbírku stylových vlastností. Crawler pole vyplnil a při generování se z nich pak poskládal kontext pro e-mailového agenta.
Výsledek mohl mít správnou barvu i písmo, a přesto vypadat genericky. Každá nová značka přinesla detail, se kterým schéma nepočítalo. Mohli jsme dál přidávat pole, ale užitečnější otázka byla, jak by stejnou značku jinému člověku vysvětlil designér.
Designér by napsal manuál. Přesné hodnoty tam, kde na nich záleží, příklady tam, kde pomůžou, a mezi nimi text, který vysvětluje rozhodnutí.
Změnili jsme tedy, co po agentovi pro načtení značky chceme.
Říkáme mu email-design.md. Je to upravitelný dokument v Markdownu, který popisuje, jak má konkrétní značka vypadat v e-mailu.
Tady je smyšlený, zkrácený příklad:
# Acme email design
## Voice
Write for engineers who want the setup instructions first.
Use short explanations and name the product action precisely.
## Signature details
- Put a small monospace label above the main headline.
- Use thin dividers between sections, without drop shadows.
- Reserve the accent color for the primary action.
- Use one product screenshot when it explains the task.
## Assets
Use the approved logo URL from the asset list.
Do not invent product images or customer logos.Dokument může vedle přesné hodnoty barvy obsahovat i pravidlo jako „akcentní barvu použij v každém e-mailu jen na jednu věc“. Agent tak má pokyn i pro případy, které jsme jednotlivě nepředvídali.
Pokyny ke značce máš na očích. Oprava se stane součástí dalšího briefu.
Markdown se tu hodí, protože ho lidé umí číst a upravovat bez speciálního formuláře. Nadpisy dávají dokumentu strukturu a nové designové pravidlo nevyžaduje nové pole v databázi. Je to praktická volba formátu. Netvrdíme tím, že Markdown vždycky spotřebuje méně tokenů než JSON nebo že se každý model trénoval hlavně na Markdownu.
Web a e-mail mají při vykreslování jiná omezení. Podpora písem, rozvržení a tmavého režimu se mezi e-mailovými klienty liší. Design, který v náhledu v prohlížeči vypadá správně, je pořád potřeba otestovat ve schránkách.
Dokument značky proto obsahuje pokyny specifické pro e-mail: záložní písma, šířky kontejnerů, recepty na rozvržení postavené na tabulkách a volby pro světlé i tmavé pozadí. Tyto pokyny agentovi pomáhají zvolit vhodná řešení; stejné zobrazení ve všech klientech ale nezaručí.
Obrázky mají jiné požadavky, a proto Brew pro pokyny k obrázkům používá ještě image-style.md. Držet obě oblasti výslovně oddělené je jednodušší, než chtít po jednom seznamu tokenů, aby popsal každé médium.
Živý web je užitečný zdroj, ale ne vždycky je směrodatný. Může na něm být stará kampaň nebo stylový experiment, který tým značky už nepoužívá.
Brew vedle domény umí využít i dodané manuály značky, loga, obrázky a další referenční podklady. Když se nahrané pokyny ke značce s webem neshodují, mají přednost před tím, co Brew z webu vyvodil. Výsledný dokument zkontroluj, zvlášť tam, kde jsou zdrojové podklady neúplné nebo si odporují.
Doména a schválené soubory dávají procesu načtení značky různé druhy podkladů.
Pokud nesedí tvar tlačítka, změň pokyn. Pokud je tón příliš formální, nahraď vágní přídavné jméno ukázkovou větou. O takové opravě se diskutuje mnohem snáz než o velkém objektu plném polí, která nikdo nechce upravovat.
Dokument vkládá umístění schválených podkladů, názvy produktů a designová rozhodnutí přímo do kontextu pro generování. Model tak musí méně hádat. Chybné výstupy to ale neodstraní.
Během této práce jsme změnili i další části e-mailového agenta. Bez kontrolovaného srovnání bych celkové zlepšení kvality nepřipisoval jen formátu souboru. Tvrdit můžu něco užšího: brief značky se snáz kontroluje, opravuje a znovu používá.
Vygenerovaný e-mail pořád potřebuje věcnou i vizuální kontrolu. Porovnej tvrzení s briefem, otestuj odkazy a prohlédni si výsledek ve schránce. Tomuto předání se věnuje článek Jak napsat brief pro e-mailového agenta.
MCP server Brew je teď k dispozici. Kompatibilní asistent může s Brew pracovat přes zdokumentované nástroje a používá přitom stejný kontext značky jako aplikace. Jak připojení funguje, vysvětlují oznámení MCP a dokumentace k nastavení.
Líbí se mi, že pokyny ke značce mají jasné místo. Když e-mail nesedí, můžeme ukázat na konkrétní větu, změnit ji a zkusit to znovu. To je užitečnější rozhovor než už poněkolikáté žádat model, ať to „udělá víc v duchu značky“.
