Warum Brew den Markenkontext aus einem starren Objekt in ein bearbeitbares Dokument verlegt hat, das neben exakten Werten auch Designentscheidungen erklärt.
Ein Hex-Code sagt einem E-Mail-Agenten, welches Blau er verwenden soll. Er sagt ihm nicht, warum eine Marke über jede Headline ein kleines Label in Monospace setzt oder warum sie Abschnitte mit dünnen Linien trennt statt mit Kästen.
Genau das war das Problem mit unserem ersten Markenmodell bei Brew. Wir haben viele Werte erfasst und trotzdem die Details verloren, die eine Marke wiedererkennbar machen.
Am Anfang sah eine Marke für uns wie strukturierte Daten aus. Wir haben Farben, Typografie, Assets und eine große Sammlung von Stileigenschaften modelliert. Ein Crawler füllte die Felder, und die Generierung setzte sie dann zu Kontext für den E-Mail-Agenten zusammen.
Das Ergebnis konnte die richtige Farbe und Schrift haben und trotzdem generisch aussehen. Jede neue Marke brachte ein Detail mit, das das Schema nicht vorgesehen hatte. Wir hätten immer weiter Felder ergänzen können, aber die nützlichere Frage war, wie ein Designer dieselbe Marke einem anderen Menschen erklären würde.
Ein Designer würde einen Leitfaden schreiben: exakte Werte, wo sie zählen, Beispiele, wo sie helfen, und Fließtext, der die Entscheidungen dazwischen erklärt.
Also haben wir geändert, was der Agent liefern soll, der Marken ausliest.
Wir nennen es email-design.md. Es ist ein bearbeitbares Markdown-Dokument, das beschreibt, wie eine bestimmte Marke in E-Mails auftreten soll.
Hier ein fiktives, gekürztes Beispiel:
# 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.Das Dokument kann neben dem exakten Farbwert eine Regel enthalten wie „die Akzentfarbe nur für ein Element pro E-Mail verwenden“. So bekommt der Agent eine Anweisung auch für Fälle, die wir nicht einzeln vorhergesehen haben.
Die Markenanweisungen sind sichtbar. Eine Korrektur wird Teil des nächsten Briefings.
Markdown ist hier praktisch, weil Menschen es ohne spezielles Formular lesen und bearbeiten können. Überschriften geben dem Dokument Struktur, und eine neue Designregel braucht kein neues Datenbankfeld. Das ist eine pragmatische Formatentscheidung. Es ist keine Behauptung, dass Markdown immer weniger Tokens verbraucht als JSON oder dass jedes Modell vor allem mit Markdown trainiert wurde.
Für eine Website und eine E-Mail gelten unterschiedliche Einschränkungen bei der Darstellung. Wie gut Schriften, Layout und Dunkelmodus unterstützt werden, ist von E-Mail-Client zu E-Mail-Client verschieden. Ein Design, das in der Browser-Vorschau richtig aussieht, muss trotzdem im Posteingang getestet werden.
Das Markendokument enthält deshalb E-Mail-spezifische Vorgaben: Fallback-Schriften, Container-Breiten, tabellenfreundliche Layout-Rezepte und Entscheidungen für helle und dunkle Hintergründe. Diese Anweisungen helfen dem Agenten, passende Entscheidungen zu treffen, garantieren aber keine identische Darstellung in jedem Client.
Für Bilder gelten andere Anforderungen, deshalb nutzt Brew für Bildvorgaben zusätzlich image-style.md. Beide Themen ausdrücklich zu trennen ist einfacher, als von einer einzigen Liste von Design-Tokens zu verlangen, jedes Medium zu beschreiben.
Eine Live-Website ist ein nützlicher Anhaltspunkt, aber nicht immer die maßgebliche Quelle. Sie kann eine alte Kampagne oder ein Stilexperiment enthalten, das das Markenteam nicht mehr verwendet.
Brew kann neben der Domain auch bereitgestellte Markenleitfäden, Logos, Bilder und anderes Referenzmaterial nutzen. Hochgeladene Markenvorgaben haben Vorrang vor Schlüssen aus der Website, wenn sich beide widersprechen. Prüfe das entstandene Dokument, vor allem dort, wo das Ausgangsmaterial unvollständig oder widersprüchlich ist.
Eine Domain und freigegebene Dateien liefern dem Auslesen der Marke unterschiedliche Arten von Belegen.
Wenn die Form der Buttons nicht stimmt, ändere die Anweisung. Wenn der Ton zu förmlich ist, ersetze das vage Adjektiv durch einen Beispielsatz. Über eine solche Korrektur lässt sich viel leichter sprechen als über ein großes Objekt voller Felder, die niemand bearbeiten will.
Das Dokument bringt freigegebene Speicherorte von Assets, Produktnamen und Designentscheidungen direkt in den Kontext der Generierung. Das verringert die Lücken, die das Modell sonst durch Raten füllen müsste. Fehlerhafte Ergebnisse schließt es nicht aus.
Während dieser Arbeit haben wir auch andere Teile des E-Mail-Agenten geändert. Ohne kontrollierten Vergleich würde ich eine insgesamt bessere Qualität nicht allein dem Dateiformat zuschreiben. Was ich sagen kann, ist enger gefasst: Das Marken-Briefing lässt sich leichter prüfen, korrigieren und wiederverwenden.
Eine generierte E-Mail braucht trotzdem eine inhaltliche und visuelle Prüfung. Gleiche die Aussagen mit dem Briefing ab, teste die Links und sieh dir das Ergebnis im Posteingang an. Der Leitfaden So briefst du einen E-Mail-Agenten beschreibt diese Übergabe.
Der MCP-Server von Brew ist jetzt verfügbar. Ein kompatibler Assistent kann über die dokumentierten Tools mit Brew arbeiten und nutzt dabei denselben Markenkontext wie die App. Die MCP-Ankündigung und die Dokumentation zur Einrichtung erklären die Verbindung.
Mir gefällt, dass die Markenanweisungen einen klaren Platz haben. Wenn sich eine E-Mail falsch anfühlt, können wir auf einen Satz zeigen, ihn ändern und es noch einmal versuchen. Das ist ein nützlicheres Gespräch, als das Modell ein weiteres Mal zu bitten, die E-Mail „markenkonformer“ zu machen.
