# email-design.md: een merkbriefing voor de e-mailagent

Canonieke URL: https://brew.new/nl/blog/email-design-md
Auteur: Thomas Park
Gepubliceerd: 2026-06-15
Bijgewerkt: 2026-09-28

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.

## Het object had voor bijna alles een veld

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.

## Het document is de briefing

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:

```markdown
# 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.

![Brew toont een bewerkbaar email-design.md naast het gesprek over het merk.](/blog/email-design-md-editor.png)

*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.

## E-mail heeft eigen ontwerpinstructies nodig

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.

## Begin met het materiaal dat je al vertrouwt

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.

![Het formulier voor het instellen van je merk, met een veld voor de website en een plek voor ondersteunende bestanden.](/blog/email-design-md-ingest.png)

*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.

## Wat de verandering wel en niet bewijst

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](/nl/blog/how-to-brief-an-email-agent) gaat over die overdracht.

## Gekoppelde agents hebben dezelfde context

De [MCP-server](/nl/mcp) 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](/nl/blog/brew-mcp) en de [documentatie over het instellen](https://docs.brew.new/api-reference/mcp/overview) 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”.