151 echte E-Mail-Sequenzen mit dem Tag, an dem jede Nachricht ankam. Stöbere darin, remixe eine als Automatisierungsentwurf oder lies alle per API und MCP aus.
Die meisten Vorlagengalerien zeigen dir immer nur eine einzelne E-Mail. Das ist die am wenigsten nützliche Einheit. Eine einzelne Willkommens-E-Mail verrät nichts über das Timing oder den Kontext drumherum. Die Sequenz liefert diesen Kontext, auch wenn eine Sequenz zu sehen noch nicht beweist, dass sie gut funktioniert hat.
Deshalb haben wir die erfassten Sequenzen als Ganzes behalten. Ein Flow in Brew zeigt die E-Mails, die wir nach einer Registrierung oder einem Newsletter-Abo beobachtet haben, der Reihe nach und jeweils mit dem Tag, an dem sie ankam. Weil die Erfassung begrenzt ist, enthält er womöglich nicht die ganze Sequenz. Zum Launch am 17. September umfasste die Galerie 151 Flows. Die Zahlen unten beschreiben diesen Stand zum Launch; der aktuelle Katalog kann sich ändern.
GET /v1/flows und das MCP-Tool list_flows liefern dieselben Datensätze. Ein Agent kann also alle 151 Sequenzen studieren, ohne dass ein Mensch irgendetwas anklickt.emailId, die du direkt als referenceEmailId an create_email übergeben kannst.Die Sequenz, die Zapier nach der Registrierung verschickt, umfasst acht E-Mails in 10,7 Tagen:
| Tag | Betreff |
|---|---|
| 0 | Welcome aboard 👋 | Let's make some magic with AI |
| 1 | Why you should ditch spreadsheets for Tables |
| 2 | Build your first Zap workflow with Copilot ⚡ |
| 3 | What engineers are automating this week |
| 5 | Put AI to work for you |
| 9 | Go beyond workflows 🚀 |
| 10 | Stuck? Or need automation ideas? |
| 10,7 | Your Zapier trial ends in three days ⏲️ |
Lies die Tage, nicht nur die Betreffzeilen. Vier E-Mails kommen an aufeinanderfolgenden Morgen an, dann wächst der Abstand auf zwei Tage, dann auf vier. Die E-Mail mit „Stuck?“ kommt an Tag 10, die zum Ablauf der Testphase folgt siebzehn Stunden später. Jemand hat entschieden, dass das letzte Nützliche vor einer Paywall ein Hilfsangebot ist und dass die beiden fast unmittelbar aufeinanderfolgen sollen.
Auf dem Screenshot einer einzelnen E-Mail siehst du das nicht.
Die Ansicht öffnet sich bei der ersten E-Mail, vor der es noch keine Wartezeit gibt, nur danach. Springst du in die Mitte, wie bei der Sequenz von Ro oben, siehst du den Abstand auf beiden Seiten. Der Willkommens-Flow von Ro ist langsamer getaktet als der von Zapier, 12 E-Mails in 46,7 Tagen, und die Abstände zeigen das, bevor du auch nur eine Betreffzeile gelesen hast.
Jeder Schritt enthält den Betreff, den Vorschautext, den Tag, an dem die E-Mail ankam, die Wartezeit seit dem vorherigen Versand, eine Kategorie und ein Vorschaubild. Auf Wunsch bekommst du auch das gerenderte HTML.
Der Bestand umfasst eine Sequenz pro Marke, 151 Flows bedeuten also 151 Unternehmen:
Daneben gibt es die Galerie mit einzelnen Designs, die weitere 4.098 Newsletter, 105 Willkommens-E-Mails und 68 Aktions-E-Mails enthält. Flows sind der Teil, der dir die Reihenfolge verrät.
Beim Remix erwarten viele eine Kopie. Das ist er nicht.
Brew baut zuerst den Graphen der Automatisierung: deinen Trigger, dann die Abstände des Original-Flows als Wartezeiten, dann pro E-Mail einen Versandschritt. Diese Hälfte ist Rechnen, keine Generierung. Niemand lässt ein Modell raten, dass die vierte E-Mail an Tag drei rausgeht.
Diese Wartezeiten zeigen 53 und 122 Stunden, weil die Originalmarke in genau diesen Abständen versendet hat, auf die Stunde gerundet. Ganze Tage bleiben ganze Tage, und alles unter einer Stunde wird zu einer Stunde. Generiert werden nur die E-Mails, und zwar parallel, jede passend zu deiner Marke. Deine Farben, deine Schriften, deine Tonalität, dein Produkt. Jeder Schritt bekommt außerdem ein Briefing, das seine Aufgabe in der Sequenz beschreibt und was davor und danach kommt. Denn die Subagenten, die diese E-Mails schreiben, sehen die Arbeit der anderen nicht und würden sonst acht zusammenhanglose Nachrichten mit gemeinsamem Zeitplan produzieren.
Du bekommst den Entwurf einer Automatisierung mit der Taktung einer Sequenz, die ein echtes Unternehmen schon verschickt hat, und Texte, die dir gehören. Lesen musst du sie trotzdem. Das Rebranding ist gut, aber nicht fertig.
Jeder Flow ist über die REST-API und über MCP verfügbar. Ein Agent kann den Bestand also direkt lesen.
# First page, newest first
curl "https://brew.new/api/v1/flows" \
-H "Authorization: Bearer $BREW_API_KEY"
# One sequence, every step
curl "https://brew.new/api/v1/flows/zapier.com" \
-H "Authorization: Bearer $BREW_API_KEY"Filtere nach brand, category oder type (signup oder newsletter). Sortiere nach emails für die Sequenzen mit den meisten E-Mails, nach span für die, die sich über die meisten Tage erstrecken, oder nach remixes für das, was andere kopierenswert fanden. Mit semantic suchst du danach, worum es in einer Sequenz geht. So findest du eine Rückgewinnungssequenz zum Ende der Testphase, ohne zu wissen, welche Marke so etwas geschrieben hat.
Denselben Lesezugriff gibt es auf dem MCP-Server von Brew als Tool und als Ressource:
list_flows # the list, same filters and sorts
get_flow { slug: "zapier.com" } # one sequence with every step
brew://flows # @-mentionable in a chat
REST und MCP lesen denselben öffentlichen Katalog. Flows gelten organisationsweit, deshalb brauchen diese Abfragen keine Marke. Zum Blättern durch die Liste übergibst du den zurückgegebenen pagination.cursor als cursor der nächsten Anfrage, bis er null ist. Eine einzelne Listenanfrage liefert nicht den ganzen Katalog, aber ihr total zählt jeden Flow, auf den die Abfrage passt.
Ein Agent kann sich die Sequenz ansehen, bevor er eine Referenz wählt.
Welche Sequenzen nach der Registrierung bieten schon in der ersten E-Mail einen Rabatt an, und welche warten damit, bis die Testphase fast vorbei ist? Was verschicken Entwicklertools an Tag zwei? Wie lange laufen Willkommenssequenzen für Newsletter, bevor sie enden? Wie viele Sequenzen beginnen mit einer Frage statt mit einem Nutzen? Anhand der Datensätze kann ein Agent diesen Fragen nachgehen, indem er steps[] liest. Betreff- und Inhaltsanalysen erfordern trotzdem Interpretation; die API bietet nicht für jede Frage einen Filter.
Die Übergabe, die das Ganze zu brauchbarem Referenzmaterial macht, ist die emailId an jedem Schritt. Es ist dieselbe Referenz, die die Vorlagengalerie verwendet, und genau das, was create_email als referenceEmailId erwartet. Ein Agent liest also den Verlauf der Sequenz, wählt den entscheidenden Schritt und übergibt genau diese eine E-Mail an das Design-Tool:
get_flow { slug: "zapier.com" }
→ steps[4].emailId = "pt1_k97hmahabyjrp1yfmga8m1rhah8e572q"
create_email {
referenceEmailId: "pt1_k97hmahabyjrp1yfmga8m1rhah8e572q",
prompt: "day-5 activation email for our API product"
}
Den Verlauf studieren, die passende E-Mail herausgreifen, die eigene Version bauen. Ohne Copy-and-paste dazwischen.
Die Erfassung behält höchstens zwölf E-Mails pro Flow und schneidet den Rest ab. emailCount: 12 bedeutet also, dass zwölf oder mehr versendet wurden, nicht genau zwölf. Das sind die 59 Flows von oben.
Gerendertes E-Mail-HTML ist umfangreich. Forderst du per MCP das HTML an, bekommst du es für den ersten oder die ersten zwei Schritte, dann ist die Antwort voll, und der Rest kommt ohne HTML. Die Zusammenfassung sagt, für wie viele es enthalten ist. Die REST-Route hat keine solche Grenze. Lies den Flow also dort, wenn du das HTML aller E-Mails brauchst: GET /v1/flows/zapier.com?include=html.
Öffne die Galerie und lies drei Sequenzen aus deiner eigenen Kategorie, bevor du irgendetwas schreibst. Remixe dann die, deren Taktung du vor deinem eigenen Team verteidigen würdest, und ändere, was nicht passt.
Wenn du einen Agenten darauf ansetzt, ist list_flows ohne Argumente der richtige erste Aufruf. Er liefert Karten mit Slugs, und der Slug ist alles, was get_flow für den Rest braucht. Die vollständige Liste der Felder steht in der API-Referenz.
Jede E-Mail, die eine Marke nach einer einzelnen Registrierung oder einem Newsletter-Abo versendet hat, der Reihe nach und jeweils mit dem Tag, an dem sie relativ zu diesem Trigger ankam. Ein Flow pro Marke, und der Slug des Flows ist die Domain der Marke.
Nein. Brew übernimmt die Struktur, also die Zahl der Schritte, die Reihenfolge und die Abstände, auf die Stunde genau nachgebildet. Jede E-Mail wird dann mit dem Original-Design als Referenz für deine Marke neu aufgebaut. Das Ergebnis trägt also deine Farben, Schriften und Tonalität.
Lesezugriffe per REST brauchen einen API-Key mit templates.read. MCP unterstützt OAuth oder einen API-Key mit passenden Berechtigungen. Die Galerie selbst ist öffentlich und braucht kein Konto.
Bis zu zwölf. Die Erfassung behält die ersten zwölf und schneidet den Rest ab. Ein Flow mit zwölf E-Mails kann also länger gelaufen sein. 59 der 151 veröffentlichten Flows liegen an dieser Grenze.
Ja, mit include=html beim Abruf eines einzelnen Flows. Per MCP passen nur der erste oder die ersten zwei Schritte in eine Antwort, und die Zusammenfassung sagt dir, für wie viele das HTML enthalten ist. Die REST-Route liefert das HTML jeder E-Mail.
