Mengapa kami memindahkan konteks merek Brew dari objek yang kaku ke dokumen yang bisa diedit, yang menjelaskan pilihan desain sekaligus nilai persisnya.
Kode hex memberi tahu agen email warna biru mana yang harus dipakai. Kode itu tidak menjelaskan mengapa sebuah merek menaruh label monospace kecil di atas setiap judul, atau mengapa pemisahnya berupa garis tipis, bukan kotak.
Itulah masalah model merek pertama kami di Brew. Kami mencatat banyak nilai, tetapi tetap kehilangan detail yang membuat sebuah merek mudah dikenali.
Saat kami memulai, merek tampak seperti data terstruktur. Kami memodelkan warna, tipografi, aset, dan sekumpulan besar properti gaya. Sebuah crawler mengisi field-field itu, lalu alur pembuatan email merangkainya menjadi konteks untuk agen email.
Hasilnya bisa saja memakai warna dan font yang tepat, tetapi tetap terlihat generik. Setiap merek baru membawa detail yang tidak diantisipasi skemanya. Kami bisa terus menambah field, tetapi pertanyaan yang lebih berguna adalah bagaimana seorang desainer akan menjelaskan merek yang sama kepada orang lain.
Seorang desainer akan menulis panduan. Nilai persis di bagian yang penting, contoh di bagian yang membantu, dan uraian yang menjelaskan keputusan di antara keduanya.
Jadi, kami mengubah apa yang kami minta untuk dihasilkan oleh agen ekstraksi.
Kami menyebutnya email-design.md. Ini adalah dokumen Markdown yang bisa diedit dan menjelaskan bagaimana sebuah merek tertentu seharusnya tampil di email.
Berikut contoh fiktif yang sudah dipersingkat:
# 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.Dokumen ini bisa memuat aturan seperti “gunakan warna aksen untuk satu elemen saja per email” di samping nilai warna yang persis. Aturan itu memberi agen instruksi untuk kasus-kasus yang tidak kami antisipasi satu per satu.
Instruksi merek terlihat jelas. Setiap koreksi menjadi bagian dari brief berikutnya.
Markdown berguna di sini karena orang bisa membaca dan mengeditnya tanpa formulir khusus. Judul-judul bagian memberi struktur pada dokumen, dan menambahkan aturan desain baru tidak memerlukan field database baru. Itu pilihan format yang praktis. Ini bukan klaim bahwa Markdown selalu memakai lebih sedikit token daripada JSON atau bahwa setiap model dilatih terutama dengan Markdown.
Situs web dan email memiliki batasan rendering yang berbeda. Dukungan untuk font, tata letak, dan mode gelap berbeda-beda di setiap klien email. Desain yang terlihat benar di pratinjau browser tetap perlu diuji di kotak masuk.
Karena itu, dokumen merek memuat panduan khusus email: font cadangan, lebar kontainer, resep tata letak yang ramah tabel, serta pilihan untuk latar terang dan latar gelap. Instruksi tersebut membantu agen mengambil keputusan yang tepat; instruksi itu tidak menjamin tampilan yang identik di setiap klien email.
Gambar memiliki kebutuhan yang berbeda, jadi Brew juga memakai image-style.md untuk panduan gambar. Memisahkan kedua hal ini secara eksplisit lebih mudah daripada meminta satu daftar token untuk menjelaskan setiap media.
Situs web yang sedang aktif adalah bukti yang berguna, tetapi tidak selalu menjadi acuan utama. Situs itu mungkin masih memuat kampanye lama atau eksperimen gaya yang sudah tidak dipakai lagi oleh tim merek.
Selain domain, Brew bisa memakai panduan merek, logo, gambar, dan materi referensi lain yang Anda berikan. Jika terjadi pertentangan, panduan merek yang diunggah lebih diutamakan daripada kesimpulan yang ditarik dari situs web. Tinjau dokumen yang dihasilkan, terutama jika materi sumbernya tidak lengkap atau tidak konsisten.
Domain dan file yang sudah disetujui memberi proses ekstraksi jenis bukti yang berbeda.
Jika bentuk tombolnya salah, ubah instruksinya. Jika gaya bahasanya terlalu formal, ganti kata sifat yang samar dengan contoh kalimat. Koreksi seperti itu jauh lebih mudah didiskusikan daripada objek besar penuh field yang tidak ingin diedit siapa pun.
Dokumen ini memasukkan lokasi aset yang disetujui, nama produk, dan keputusan desain langsung ke konteks pembuatan email. Dengan begitu, makin sedikit celah yang harus ditebak sendiri oleh model. Namun, dokumen ini tidak menghilangkan kemungkinan hasil yang keliru.
Kami juga mengubah bagian lain dari agen email selama pekerjaan ini. Tanpa perbandingan yang terkendali, saya tidak akan mengaitkan peningkatan kualitas secara keseluruhan hanya dengan format file. Klaim yang bisa saya buat lebih sempit: brief merek kini lebih mudah diperiksa, dikoreksi, dan dipakai ulang.
Email hasil AI tetap perlu ditinjau dari sisi fakta dan visual. Cocokkan klaim di dalamnya dengan brief, uji tautannya, dan periksa hasilnya di kotak masuk. Panduan memberi brief email membahas serah terima tersebut.
Server MCP Brew kini sudah tersedia. Asisten yang kompatibel bisa bekerja dengan Brew melalui alat-alat yang terdokumentasi, dengan memakai konteks merek yang sama seperti di aplikasi. Pengumuman MCP dan dokumentasi penyiapan menjelaskan cara menghubungkannya.
Saya senang instruksi merek kini punya tempat yang jelas. Saat sebuah email terasa kurang pas, kami bisa menunjuk satu kalimat, mengubahnya, lalu mencoba lagi. Itu percakapan yang lebih berguna daripada sekali lagi meminta model untuk “membuatnya lebih sesuai merek”.
