Waarom we de merkcontext van Brew van een star object naar een bewerkbaar document verhuisden dat naast exacte waarden ook ontwerpkeuzes uitlegt.
Een hexcode vertelt een e-mailagent welk blauw hij moet gebruiken. Niet waarom een merk boven elke kop een klein label in een monospace-lettertype zet, of waarom het secties scheidt met dunne lijnen in plaats van met kaders.
Dat was het probleem met ons eerste merkmodel bij Brew. We legden veel waarden vast en raakten toch de details kwijt die een merk herkenbaar maakten.
Toen we begonnen, leek een merk op gestructureerde data. We modelleerden kleuren, typografie, assets en een grote verzameling stijleigenschappen. Een crawler vulde de velden, en daarna voegde de generatiepijplijn ze samen tot context voor de e-mailagent.
Het resultaat kon de juiste kleur en het juiste lettertype hebben en er toch generiek uitzien. Elk nieuw merk bracht een detail mee waar het schema niet op had gerekend. We hadden velden kunnen blijven toevoegen, maar de nuttigere vraag was hoe een designer hetzelfde merk aan iemand anders zou uitleggen.
Een designer zou een gids schrijven. Exacte waarden waar ze ertoe doen, voorbeelden waar ze helpen, en lopende tekst die de keuzes daartussen uitlegt.
Dus veranderden we wat de agent die het merk ophaalt moest opleveren.
We noemen het email-design.md. Het is een bewerkbaar Markdown-document dat beschrijft hoe een specifiek merk eruit hoort te zien in e-mail.
Hier is een fictief, ingekort voorbeeld:
# 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.Het document kan een regel als “gebruik de accentkleur voor één ding per e-mail” naast de exacte kleurwaarde bevatten. Zo krijgt de agent een instructie voor gevallen die we niet stuk voor stuk hadden voorzien.
De merkinstructies zijn zichtbaar. Een correctie wordt onderdeel van de volgende briefing.
Markdown is hier handig omdat mensen het zonder speciaal formulier kunnen lezen en bewerken. Koppen geven het document structuur, en voor een nieuwe ontwerpregel is geen nieuw databaseveld nodig. Dat is een praktische keuze voor het formaat. Het is geen bewering dat Markdown altijd minder tokens gebruikt dan JSON of dat elk model vooral op Markdown is getraind.
Een website en een e-mail hebben andere beperkingen bij de weergave. De ondersteuning voor lettertypen, lay-out en donkere modus verschilt per e-mailclient. Een ontwerp dat in een browservoorbeeld goed oogt, moet je toch in de inbox testen.
Het merkdocument bevat daarom richtlijnen speciaal voor e-mail: fallbacklettertypen, containerbreedtes, lay-outrecepten die met tabellen werken en keuzes voor lichte en donkere achtergronden. Die instructies helpen de agent passende beslissingen te nemen; ze garanderen geen identieke weergave in elke client.
Beeldmateriaal stelt andere eisen, dus Brew gebruikt ook image-style.md voor richtlijnen over afbeeldingen. De twee onderwerpen expliciet gescheiden houden is makkelijker dan één lijst met designtokens elk medium te laten beschrijven.
Een live website is nuttig bewijsmateriaal, maar niet altijd de doorslaggevende bron. Er kan een oude campagne op staan of een stijlexperiment dat het merkteam niet meer gebruikt.
Brew kan naast het domein ook aangeleverde merkrichtlijnen, logo’s, afbeeldingen en ander referentiemateriaal gebruiken. Geüploade merkrichtlijnen gaan vóór wat Brew uit de website afleidt als die elkaar tegenspreken. Controleer het document dat eruit komt, vooral waar het bronmateriaal onvolledig of inconsistent is.
Een domein en goedgekeurde bestanden leveren verschillende soorten bewijs voor het ophalen van je merk.
Klopt de vorm van de knoppen niet, pas dan de instructie aan. Is de tone of voice te formeel, vervang het vage bijvoeglijk naamwoord dan door een voorbeeldzin. Over zo’n correctie praat je veel makkelijker dan over een groot object vol velden die niemand wil bewerken.
Het document zet goedgekeurde locaties van assets, productnamen en ontwerpkeuzes direct in de context voor het genereren. Dat verkleint de gaten die het model anders zelf zou moeten invullen. Onjuiste output verdwijnt er niet door.
Tijdens dit werk hebben we ook andere onderdelen van de e-mailagent veranderd. Zonder gecontroleerde vergelijking zou ik een algemene kwaliteitsverbetering niet alleen aan het bestandsformaat toeschrijven. Wat ik wel kan zeggen, is beperkter: de merkbriefing is makkelijker te controleren, te corrigeren en te hergebruiken.
Een gegenereerde e-mail moet je nog steeds inhoudelijk en visueel controleren. Leg de claims naast de briefing, test de links en bekijk het resultaat in de inbox. De gids Zo brief je een e-mailagent gaat over die overdracht.
De MCP-server van Brew is nu beschikbaar. Een compatibele assistent kan via de gedocumenteerde tools met Brew werken, met dezelfde merkcontext als de app. De aankondiging van MCP en de documentatie over het instellen leggen uit hoe je koppelt.
Ik vind het fijn dat de merkinstructies een vanzelfsprekende plek hebben. Voelt een e-mail niet goed, dan kunnen we een zin aanwijzen, die aanpassen en het opnieuw proberen. Dat is een nuttiger gesprek dan het model voor de zoveelste keer vragen: “maak het meer merkconform”.
