Trasforma le email in fatturato con Brew.
151 sequenze email reali, con il giorno di arrivo di ogni email. Sfogliale, remixane una come bozza di automazione o leggile tutte dal codice via API e MCP.
La maggior parte delle gallerie di modelli mostra un’email alla volta. Ed è l’unità meno utile. Una singola email di benvenuto non mostra i tempi né il contesto che la circondano. La sequenza aggiunge quel contesto, anche se vedere una sequenza non dimostra che abbia funzionato bene.
Per questo abbiamo conservato le sequenze raccolte. Un flusso in Brew mostra le email che abbiamo osservato dopo una registrazione o un’iscrizione alla newsletter, in ordine, con il giorno in cui è arrivata ciascuna. A causa dei limiti della raccolta, potrebbe non contenere l’intera sequenza. Al lancio del 17 settembre, la galleria conteneva 151 flussi. I numeri che seguono descrivono lo snapshot di quel momento; il catalogo attuale può cambiare.
GET /v1/flows e lo strumento MCP list_flows restituiscono gli stessi record, quindi un agente può studiare tutte le 151 sequenze senza che una persona debba cliccare su nulla.emailId che puoi passare direttamente a create_email come referenceEmailId.La sequenza di Zapier dopo la registrazione conta otto email in 10,7 giorni:
| Giorno | Oggetto |
|---|---|
| 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 ⏲️ |
Leggi i giorni, non solo gli oggetti. Quattro email arrivano in mattine consecutive, poi l’intervallo si allunga a due giorni, poi a quattro. L’email “Stuck?” arriva il giorno 10 e quella sulla scadenza della prova la segue diciassette ore dopo. Qualcuno ha deciso che l’ultima cosa utile prima di un paywall è un’offerta di aiuto, e che le due email dovessero quasi toccarsi.
Nello screenshot di una singola email questo non si vede.
Il visualizzatore si apre sulla prima email, che ha un’attesa solo dopo di sé. Se ti sposti a metà sequenza, come nella sequenza di Ro qui sopra, l’intervallo compare su entrambi i lati. Il flusso di benvenuto di Ro ha un ritmo più lento di quello di Zapier, 12 email in 46,7 giorni, e gli intervalli lo dicono prima ancora che tu legga un oggetto.
Ogni passaggio riporta l’oggetto, il testo di anteprima, il giorno di arrivo, l’attesa dall’invio precedente, una categoria e un’immagine di anteprima. Se lo chiedi, ottieni anche l’HTML renderizzato.
Il corpus contiene una sequenza per brand, quindi 151 flussi significano 151 aziende:
Si affianca alla galleria dei singoli design, che contiene altre 4.098 newsletter, 105 email di benvenuto e 68 promozioni. I flussi sono la parte che ti dice l’ordine.
Tutti si aspettano che il remix sia una copia. Non lo è.
Per prima cosa Brew costruisce il diagramma dell’automazione: il tuo trigger, poi gli intervalli del flusso originale come nodi Attesa, poi un nodo di invio per ogni passaggio. Questa metà è aritmetica, non generazione. Nessuno chiede a un modello di indovinare che la quarta email parte il terzo giorno.
Quei nodi Attesa indicano 53 e 122 ore perché sono gli intervalli con cui ha inviato il brand originale, arrotondati all’ora più vicina. Un intervallo di un giorno intero resta di un giorno intero, e qualsiasi intervallo inferiore a un’ora diventa di un’ora. Solo le email vengono generate, e vengono generate in parallelo, ciascuna sulla base del tuo brand: i tuoi colori, i tuoi font, il tuo tono di voce, il tuo prodotto. Ogni passaggio riceve anche un brief che descrive il suo ruolo nella sequenza e cosa c’è prima e dopo, perché i subagenti che scrivono quelle email non possono vedere il lavoro degli altri e altrimenti produrrebbero otto messaggi scollegati con una programmazione in comune.
Ottieni una bozza di automazione con il ritmo di una sequenza che un’azienda reale ha già usato, e testi che sono tuoi. Devi comunque rileggerla. Il rebranding è buono, ma non finito.
Ogni flusso è disponibile tramite l’API REST e tramite MCP, quindi un agente può leggere direttamente il corpus.
# 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"Filtra per brand, category o type (signup o newsletter). Ordina per emails per trovare le sequenze con più email, per span per quelle distribuite sul maggior numero di giorni, o per remixes per ciò che altri hanno trovato degno di essere copiato. Passa semantic per cercare in base all’argomento di una sequenza: è così che trovi un flusso di riattivazione legato alla scadenza della prova senza sapere quale brand ne abbia scritto uno.
La stessa lettura è disponibile come strumento e come risorsa sul server MCP di Brew:
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 e MCP leggono lo stesso catalogo pubblico. I flussi valgono per l’intera organizzazione, quindi queste letture non richiedono un brand. Per la paginazione dell’elenco, passa il pagination.cursor restituito come cursor della richiesta successiva, finché non diventa null. Una singola richiesta di elenco non restituisce l’intero catalogo, ma il suo total conta tutti i flussi che corrispondono alla query.
Un agente può esaminare la sequenza prima di scegliere un riferimento.
Quali flussi di registrazione mettono uno sconto nella prima email, e quali aspettano che la prova stia per finire? Cosa inviano gli strumenti per sviluppatori il secondo giorno? Quanto durano le sequenze di benvenuto delle newsletter prima di fermarsi? Quante sequenze si aprono con una domanda invece che con un vantaggio? I record permettono a un agente di esplorare queste domande leggendo steps[]. L’analisi di oggetti e contenuti richiede comunque un’interpretazione: l’API non espone un filtro per ogni domanda.
Il raccordo che trasforma tutto questo in materiale di riferimento utilizzabile è l’emailId di ogni passaggio. È lo stesso riferimento usato dalla galleria dei modelli, ed è esattamente ciò che create_email accetta come referenceEmailId. Così un agente legge l’arco della sequenza, sceglie il passaggio che conta e passa quell’email allo strumento di design:
get_flow { slug: "zapier.com" }
→ steps[4].emailId = "pt1_k97hmahabyjrp1yfmga8m1rhah8e572q"
create_email {
referenceEmailId: "pt1_k97hmahabyjrp1yfmga8m1rhah8e572q",
prompt: "day-5 activation email for our API product"
}
Studia l’arco, prendi l’email specifica, crea la tua versione. Nessun copia-incolla nel mezzo.
La raccolta conserva al massimo dodici email per flusso e taglia la coda, quindi emailCount: 12 significa che ne sono state inviate dodici o più, non esattamente dodici. Sono i 59 flussi citati sopra.
Un’email renderizzata è voluminosa. Se chiedi l’HTML tramite MCP, ottieni il primo passaggio o i primi due prima che la risposta si riempia, e il resto arriva senza. Il riepilogo indica quanti ne sono stati conservati. La route REST non ha questo limite, quindi leggi lì il flusso quando vuoi tutti i corpi delle email: GET /v1/flows/zapier.com?include=html.
Apri la galleria e leggi tre sequenze della tua categoria prima di scrivere qualsiasi cosa. Poi remixa quella il cui ritmo difenderesti davanti al tuo team, e modifica ciò che non si adatta al tuo caso.
Se fai lavorare un agente su questi dati, list_flows senza argomenti è la prima chiamata giusta. Restituisce delle schede con gli slug, e lo slug è l’unica cosa di cui get_flow ha bisogno per tutto il resto. L’elenco completo dei campi è nel riferimento API.
Tutte le email che un brand ha inviato dopo una singola registrazione o iscrizione alla newsletter, in ordine, con il giorno in cui è arrivata ciascuna rispetto a quel trigger. C’è un flusso per brand, e lo slug del flusso è il dominio del brand.
No. Brew copia la struttura, cioè il numero di passaggi, l’ordine e gli intervalli, riprodotti con un arrotondamento all’ora più vicina. Ogni email viene poi ricostruita sulla base del tuo brand usando il design originale come riferimento, quindi il risultato ha i tuoi colori, i tuoi font e il tuo tono di voce.
Le letture tramite REST richiedono una chiave API con templates.read. MCP supporta OAuth o una chiave API con l’accesso adeguato. La galleria in sé è pubblica e non richiede un account.
Fino a dodici. La raccolta conserva le prime dodici e taglia la coda, quindi un flusso con dodici email potrebbe essere durato di più. Dei 151 flussi pubblicati, 59 hanno raggiunto quel limite.
Sì, con include=html nella lettura di un singolo flusso. Tramite MCP, in una risposta entrano solo il primo passaggio o i primi due, e il riepilogo ti dice quanti ne sono stati conservati. La route REST restituisce tutti i corpi delle email.
