Por que levamos o contexto de marca do Brew de um objeto rígido para um documento editável que explica as escolhas de design, além dos valores exatos.
Um código hexadecimal diz a um agente de e-mail qual azul usar. Não diz por que uma marca coloca um pequeno rótulo em fonte monoespaçada acima de cada título, nem por que os divisores dela são linhas finas, e não caixas.
Esse era o problema do nosso primeiro modelo de marca no Brew. Capturávamos muitos valores e, mesmo assim, perdíamos os detalhes que tornavam uma marca reconhecível.
No começo, uma marca parecia um conjunto de dados estruturados. Modelamos cores, tipografia, mídia e uma grande coleção de propriedades de estilo. Um crawler preenchia os campos, e o processo de geração os juntava em um contexto para o agente de e-mail.
O resultado podia ter a cor e a fonte certas e ainda assim parecer genérico. Cada marca nova trazia um detalhe que o esquema não tinha previsto. Poderíamos continuar adicionando campos, mas a pergunta mais útil era como um designer explicaria essa mesma marca para outra pessoa.
Um designer escreveria um guia. Valores exatos onde eles importam, exemplos onde ajudam e, entre eles, texto corrido explicando as decisões.
Então mudamos o que pedíamos ao agente de extração.
Nós o chamamos de email-design.md. É um documento Markdown editável que descreve como uma marca específica deve aparecer no e-mail.
Veja um exemplo fictício e resumido:
# 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.O documento pode trazer uma regra como “use a cor de destaque em uma só coisa por e-mail” ao lado do valor exato da cor. Assim, o agente tem uma instrução para casos que não previmos um a um.
As instruções da marca ficam à vista. Uma correção passa a fazer parte do próximo briefing.
O Markdown é útil aqui porque as pessoas conseguem ler e editar o documento sem um formulário especial. Os títulos de seção dão estrutura ao documento, e acrescentar uma nova regra de design não exige um novo campo no banco de dados. É uma escolha prática de formato. Não é uma afirmação de que o Markdown sempre usa menos tokens do que o JSON, nem de que todo modelo foi treinado principalmente com Markdown.
Um site e um e-mail têm restrições de renderização diferentes. O suporte a fontes, layout e modo escuro varia entre os clientes de e-mail. Um design que parece certo na prévia do navegador ainda precisa ser testado na caixa de entrada.
Por isso, o documento de marca inclui orientações específicas para e-mail: fontes alternativas, larguras de contêiner, soluções de layout que funcionam com tabelas e escolhas para fundos claros e escuros. Essas instruções ajudam o agente a tomar decisões adequadas; elas não garantem uma renderização idêntica em todos os clientes.
As imagens têm outras exigências, por isso o Brew também usa o image-style.md para orientar as imagens. Manter essas duas preocupações explícitas é mais fácil do que pedir a uma única lista de tokens que descreva todos os meios.
Um site no ar é uma evidência útil, mas nem sempre é a referência final. Ele pode ter uma campanha antiga ou um experimento de estilo que a equipe de marca não usa mais.
O Brew pode usar guias de marca, logos, imagens e outros materiais de referência que você fornecer, junto com o domínio. Quando há divergência, as orientações de marca enviadas por upload têm precedência sobre o que é inferido do site. Revise o documento resultante, principalmente onde o material de origem estiver incompleto ou inconsistente.
Um domínio e arquivos aprovados dão ao processo de extração tipos diferentes de evidência.
Se o formato do botão estiver errado, mude a instrução. Se o tom de voz estiver formal demais, troque o adjetivo vago por uma frase de exemplo. Essa correção é muito mais fácil de discutir do que um objeto enorme, cheio de campos que ninguém quer editar.
O documento coloca os endereços dos arquivos aprovados, os nomes dos produtos e as decisões de design direto no contexto de geração. Isso reduz as lacunas que o modelo teria de preencher no chute. Não elimina resultados incorretos.
Também mudamos outras partes do agente de e-mail durante esse trabalho. Sem uma comparação controlada, eu não atribuiria uma melhora geral de qualidade só ao formato do arquivo. O que posso afirmar é mais restrito: o briefing de marca é mais fácil de inspecionar, corrigir e reutilizar.
Um e-mail gerado ainda precisa de uma revisão factual e visual. Confira as afirmações com o briefing, teste os links e examine o resultado na caixa de entrada. O guia de briefing para e-mails trata dessa passagem de bastão.
O servidor MCP do Brew já está disponível. Um assistente compatível pode trabalhar com o Brew pelas ferramentas documentadas, usando o mesmo contexto de marca do app. O anúncio do MCP e a documentação de configuração explicam a conexão.
Gosto de que as instruções da marca tenham um lugar óbvio para ficar. Quando um e-mail parece errado, podemos apontar uma frase, mudá-la e tentar de novo. É uma conversa mais útil do que pedir ao modelo, mais uma vez, para “deixar mais com a cara da marca”.
