151 secuencias de email reales con el día en que llegó cada mensaje. Explóralas, adapta una como borrador de automatización o léelas todas con la API y MCP.
La mayoría de las galerías de plantillas te muestran los emails de uno en uno. Es la unidad menos útil. Un email de bienvenida aislado no muestra ni el momento en que se envía ni el contexto que lo rodea. La secuencia aporta ese contexto, aunque ver una secuencia no demuestra que haya funcionado bien.
Por eso guardamos las secuencias capturadas. Un flujo en Brew muestra los emails que observamos después de un registro o de una suscripción a una newsletter, en orden y con el día en que llegó cada uno. Por los límites de la captura, puede que no contenga la secuencia completa. En el lanzamiento del 17 de septiembre, la galería tenía 151 flujos. Las cifras de abajo describen esa instantánea del lanzamiento; el catálogo actual puede cambiar.
GET /v1/flows y la herramienta MCP list_flows devuelven los mismos registros, así que un agente puede estudiar las 151 secuencias sin que nadie tenga que hacer clic en nada.emailId que puedes pasar directamente a create_email como referenceEmailId.La secuencia de Zapier tras el registro consta de ocho emails en 10,7 días:
| Día | Asunto |
|---|---|
| 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 ⏲️ |
Fíjate en los días, no solo en los asuntos. Cuatro emails llegan en mañanas consecutivas; después, el intervalo se alarga a dos días y luego a cuatro. El email del “Stuck?” llega el día 10, y el del fin de la prueba, diecisiete horas después. Alguien decidió que lo último útil antes de un muro de pago es ofrecer ayuda, y que los dos emails debían ir casi pegados.
Eso no se ve en la captura de un solo email.
El visor se abre en el primer email, que solo tiene una espera después. Si te sitúas en medio, como en la secuencia de Ro de arriba, el intervalo se ve a ambos lados. El flujo de bienvenida de Ro tiene un ritmo más lento que el de Zapier, 12 emails en 46,7 días, y los intervalos lo dicen antes de que leas un solo asunto.
Cada paso incluye el asunto, el texto de vista previa, el día en que llegó, la espera desde el envío anterior, una categoría y una imagen de vista previa. Si lo pides, también obtienes el HTML renderizado.
El corpus incluye una secuencia por marca, así que 151 flujos son 151 empresas:
Todo esto se suma a la galería de diseños individuales, que reúne otras 4098 newsletters, 105 emails de bienvenida y 68 promociones. Los flujos son la parte que te dice el orden.
Adaptar es la parte que la gente espera que sea una copia. No lo es.
Brew construye primero el grafo de la automatización: tu disparador, después los intervalos del flujo original como nodos de espera y luego un nodo de envío por paso. Esa mitad es aritmética, no generación. Nadie le pide a un modelo que adivine que el cuarto email sale el día tres.
Esos nodos de espera indican 53 y 122 horas porque es lo que envió la marca original, redondeado a la hora más cercana. Un intervalo de días completos se queda en días completos, y cualquier intervalo de menos de una hora pasa a ser de una hora. Solo se generan los emails, y se generan en paralelo, cada uno a partir de tu marca: tus colores, tus fuentes, tu voz, tu producto. Cada paso recibe además un brief que describe su función en la secuencia y lo que tiene antes y después, porque los subagentes que escriben esos emails no ven el trabajo de los demás y, sin ese brief, producirían ocho mensajes inconexos con un calendario compartido.
Obtienes un borrador de automatización con el ritmo de una secuencia que una empresa real ya ha puesto en marcha, y unos textos que son tuyos. Aun así, tienes que leerlo. La adaptación a tu marca es buena, pero no está terminada.
Todos los flujos están disponibles a través de la API REST y de MCP, así que un agente puede leer el corpus directamente.
# 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 por brand, category o type (signup o newsletter). Ordena por emails para ver las secuencias con más emails, por span para las que se extienden durante más días o por remixes para lo que a otras personas les pareció digno de copiar. Pasa semantic para buscar por el tema de una secuencia: así encuentras un email de recuperación por fin de la prueba sin saber qué marca lo escribió.
En el servidor MCP de Brew, esa misma lectura es una herramienta y un recurso:
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 y MCP leen el mismo catálogo público. Los flujos son de toda la organización, así que estas lecturas no llevan marca. Para paginar la lista, pasa el pagination.cursor devuelto como cursor de la siguiente solicitud hasta que sea nulo. Una sola solicitud de lista no devuelve el catálogo completo, pero su total cuenta todos los flujos que coinciden con la consulta.
Un agente puede examinar la secuencia antes de elegir una referencia.
¿Qué flujos de registro incluyen un descuento en el primer email y cuáles esperan a que la prueba esté a punto de terminar? ¿Qué envían las herramientas para desarrolladores el segundo día? ¿Cuánto duran las secuencias de bienvenida de las newsletters antes de detenerse? ¿Cuántas secuencias empiezan con una pregunta en lugar de con un beneficio? Los registros permiten a un agente investigar esas preguntas leyendo steps[]. El análisis de los asuntos y del contenido sigue requiriendo interpretación; la API no ofrece un filtro para cada pregunta.
Lo que hace que todo esto sirva como material de referencia es el emailId de cada paso, que permite pasar el testigo a la herramienta de diseño. Es la misma referencia que usa la galería de plantillas, y es exactamente lo que create_email recibe como referenceEmailId. Así, un agente lee el arco de la secuencia, elige el paso que importa y le pasa ese email a la herramienta de diseño:
get_flow { slug: "zapier.com" }
→ steps[4].emailId = "pt1_k97hmahabyjrp1yfmga8m1rhah8e572q"
create_email {
referenceEmailId: "pt1_k97hmahabyjrp1yfmga8m1rhah8e572q",
prompt: "day-5 activation email for our API product"
}
Estudia el arco, extrae el email concreto y crea tu versión. Sin copiar y pegar por el camino.
La captura guarda como máximo doce emails por flujo y corta el resto, así que emailCount: 12 significa que se enviaron doce o más, no exactamente doce. Son los 59 flujos que mencionamos antes.
El email renderizado ocupa mucho. Si pides el HTML por MCP, lo obtienes del primer paso o de los dos primeros antes de que la respuesta se llene, y el resto llega sin él. El resumen indica cuántos se conservaron. La ruta REST no tiene ese límite, así que lee el flujo por ahí cuando quieras el cuerpo de todos los emails: GET /v1/flows/zapier.com?include=html.
Abre la galería y lee tres secuencias de tu propia categoría antes de escribir nada. Después, adapta aquella cuyo ritmo defenderías ante tu propio equipo y cambia lo que no encaje.
Si vas a poner a un agente a trabajar con esto, la primera llamada correcta es list_flows sin argumentos. Devuelve tarjetas con slugs, y el slug es lo único que necesita get_flow para todo lo demás. La lista completa de campos está en la referencia de la API.
Todos los emails que envió una marca después de un único registro o de una suscripción a su newsletter, en orden y con el día en que llegó cada uno respecto a ese disparador. Hay un flujo por marca, y el slug del flujo es el dominio de la marca.
No. Brew copia la estructura, es decir, el número de pasos, el orden y los intervalos, redondeados a la hora más cercana. Después, cada email se reconstruye para tu marca usando el diseño original como referencia, así que el resultado lleva tus colores, tus fuentes y tu voz.
Las lecturas por REST requieren una clave de API con el permiso templates.read. MCP admite OAuth o una clave de API con el acceso adecuado. La galería en sí es pública y no necesita cuenta.
Hasta doce. La captura guarda los doce primeros y corta el resto, así que un flujo que indica doce emails puede haber sido más largo. De los 151 flujos publicados, 59 están en ese límite.
Sí, con include=html al leer un solo flujo. Por MCP, solo caben en una respuesta el primer paso o los dos primeros, y el resumen te dice cuántos se conservaron. La ruta REST devuelve el cuerpo de todos los emails.
