# email-design.md: un brief de marca para el agente de email

URL canónica: https://brew.new/es/blog/email-design-md
Autoría: Thomas Park
Publicado: 2026-06-15
Actualizado: 2026-09-28

Un código hexadecimal le dice a un agente de email qué azul usar. No le dice por qué una marca pone una pequeña etiqueta en tipografía monoespaciada sobre cada titular, ni por qué sus divisores son líneas finas y no recuadros.

Ese era el problema de nuestro primer modelo de marca en Brew. Recogíamos muchos valores y, aun así, perdíamos los detalles que hacían reconocible una marca.

## El objeto tenía un campo para casi todo

Al principio, una marca parecía un conjunto de datos estructurados. Modelamos los colores, la tipografía, los recursos y una gran colección de propiedades de estilo. Un rastreador web completaba los campos y, después, el proceso de generación los reunía en el contexto que recibía el agente de email.

El resultado podía tener el color y la fuente correctos y, aun así, parecer genérico. Cada marca nueva traía un detalle que el esquema no había previsto. Podíamos seguir añadiendo campos, pero la pregunta más útil era cómo le explicaría un diseñador esa misma marca a otra persona.

Un diseñador escribiría una guía: valores exactos donde importan, ejemplos donde ayudan y texto que explique las decisiones que hay entre unos y otros.

Así que cambiamos lo que le pedíamos al agente de extracción.

## El documento es el brief

Lo llamamos `email-design.md`. Es un documento Markdown editable que describe cómo debe verse una marca concreta en el email.

Este es un ejemplo ficticio y abreviado:

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

El documento puede incluir una regla como “usa el color de acento en una sola cosa por email” junto al valor exacto del color. Así, el agente tiene una instrucción para los casos que no habíamos previsto uno por uno.

![Brew muestra un email-design.md editable junto a la conversación sobre la marca.](/blog/email-design-md-editor.png)

*Las instrucciones de la marca están a la vista. Cada corrección pasa a formar parte del siguiente brief.*

Markdown es útil aquí porque cualquiera puede leerlo y editarlo sin un formulario especial. Los encabezados dan estructura al documento, y añadir una regla de diseño nueva no exige un campo nuevo en la base de datos. Es una elección práctica de formato. No afirmamos que Markdown use siempre menos tokens que JSON ni que todos los modelos se hayan entrenado principalmente con Markdown.

## El email necesita sus propias instrucciones de diseño

Un sitio web y un email tienen limitaciones de renderizado distintas. La compatibilidad con fuentes, maquetación y modo oscuro varía de un cliente de correo a otro. Un diseño que se ve bien en la vista previa del navegador sigue necesitando pruebas en la bandeja de entrada.

Por eso, el documento de marca incluye indicaciones específicas para email: fuentes de respaldo, anchos de contenedor, recetas de maquetación compatibles con tablas y decisiones para fondos claros y oscuros. Esas instrucciones ayudan al agente a tomar decisiones adecuadas, pero no garantizan que el email se vea idéntico en todos los clientes.

Las imágenes tienen otros requisitos, así que Brew también usa `image-style.md` para las indicaciones sobre imágenes. Mantener separados y explícitos estos dos ámbitos es más sencillo que pedirle a una sola lista de tokens que describa todos los medios.

## Parte del material en el que ya confías

Un sitio web publicado es una prueba útil, pero no siempre es la referencia definitiva. Puede contener una campaña antigua o un experimento de estilo que el equipo de marca ya no usa.

Brew puede usar, además del dominio, las guías de marca, los logos, las imágenes y otro material de referencia que le facilites. Si no coinciden, las guías de marca que subas tienen prioridad sobre lo que Brew deduzca del sitio web. Revisa el documento resultante, sobre todo donde el material de partida esté incompleto o sea incoherente.

![El formulario de configuración de la marca, con un campo para el sitio web y un espacio para archivos de apoyo.](/blog/email-design-md-ingest.png)

*Un dominio y unos archivos aprobados aportan al proceso de extracción distintos tipos de pruebas.*

Si la forma del botón no es la correcta, cambia la instrucción. Si la voz es demasiado formal, sustituye el adjetivo vago por una frase de ejemplo. Es mucho más fácil hablar de esa corrección que de un objeto enorme lleno de campos que nadie quiere editar.

## Lo que demuestra el cambio y lo que no

El documento lleva directamente al contexto de generación las ubicaciones de los recursos aprobados, los nombres de los productos y las decisiones de diseño. Eso reduce las lagunas que, de otro modo, el modelo tendría que suplir a ciegas. No elimina los resultados incorrectos.

Durante este trabajo también cambiamos otras partes del agente de email. Sin una comparación controlada, no atribuiría una mejora general de la calidad solo al formato del archivo. Lo que sí puedo afirmar es algo más acotado: el brief de marca es más fácil de revisar, corregir y reutilizar.

Un email generado sigue necesitando una revisión de los datos y del diseño. Contrasta lo que afirma con el brief, prueba los enlaces y revisa el resultado en la bandeja de entrada. La [guía para preparar el brief de un email](/es/blog/how-to-brief-an-email-agent) explica ese traspaso.

## Los agentes conectados tienen el mismo contexto

El [servidor MCP](/es/mcp) de Brew ya está disponible. Un asistente compatible puede trabajar con Brew a través de las herramientas documentadas, con el mismo contexto de marca que la aplicación. El [anuncio de MCP](/es/blog/brew-mcp) y la [documentación de configuración](https://docs.brew.new/api-reference/mcp/overview) explican cómo conectarlo.

Me gusta que las instrucciones de la marca tengan un lugar evidente donde vivir. Cuando un email no termina de encajar, podemos señalar una frase, cambiarla y volver a intentarlo. Es una conversación más útil que pedirle al modelo, una vez más, que lo haga “más fiel a nuestra marca”.
