Pembelajaran Hermes × Basim

Versi detail: catatan pembelajaran dari penggunaan Hermes bersama Basim tentang WhatsApp bridge, Telegram topics, cron ringkasan, Codex quota, writing workflow, verifikasi, dan operasional agent lintas kanal.

Versi diperluas. Catatan ini disusun dari penggunaan Hermes bersama Basim di Telegram dan WhatsApp. Fokusnya bukan hanya daftar fitur yang pernah dicoba, tetapi pelajaran operasional: apa yang rusak, kenapa rusak, bagaimana memperbaikinya, dan aturan kerja apa yang perlu dipertahankan.

Ringkasan besar

Hermes dalam setup Basim berfungsi seperti operator kecil yang hidup di beberapa kanal: Telegram, WhatsApp DM, WhatsApp group read-only, cron job, file lokal, API eksternal, dan proses server. Karena itu cara memakainya tidak bisa disamakan dengan chatbot biasa. Chatbot biasa cukup menjawab pertanyaan. Agent lintas kanal harus bisa menerima pesan, menjaga konteks, mengeksekusi perintah, memverifikasi hasil, tidak membocorkan rahasia, tidak spam, dan tahu kapan harus diam.

Pembelajaran terpenting dari penggunaan ini adalah bahwa agent yang berguna perlu diperlakukan seperti sistem produksi. Ia butuh konfigurasi yang eksplisit, observability lewat log dan status, prosedur recovery, batasan kanal, serta kebiasaan verifikasi. Banyak masalah tidak selesai hanya dengan “restart”. Contoh paling jelas adalah WhatsApp: ketika sesi linked-device invalid, restart bridge tidak cukup; perlu backup, reset session, pairing ulang, lalu verifikasi file credential, proses bridge, dan log gateway.

Di sisi lain, Telegram terbukti lebih stabil sebagai kanal kontrol utama karena memakai Bot API resmi. WhatsApp tetap berguna, terutama untuk ingest percakapan dan ringkasan group, tetapi harus dipakai dengan ekspektasi yang realistis: koneksinya lebih rapuh, pairing bisa gagal, dan group sebaiknya read-only agar agent tidak menjadi sumber spam.

Catatan ini merangkum 12 pembelajaran utama. Masing-masing dibuat lebih panjang agar bisa dibaca sebagai “satu halaman” kecil: ada konteks, kejadian, pelajaran teknis, risiko, dan aturan praktis yang bisa dipakai ulang.

1. WhatsApp/Baileys itu rapuh, Telegram lebih stabil

Kejadian WhatsApp yang sempat tidak dibalas memperlihatkan perbedaan besar antara integrasi resmi dan integrasi berbasis linked-device. Telegram Bot API berjalan dengan model yang jelas: bot punya token, Telegram menyediakan endpoint resmi, dan status pengiriman relatif mudah diverifikasi. WhatsApp via Baileys bekerja seperti perangkat WhatsApp Web yang ditautkan ke akun utama. Ini bisa sangat berguna, tetapi secara operasional lebih rapuh.

Saat WhatsApp Hermes bermasalah, gejalanya bukan sekadar “agent lambat”. Dari sisi runtime, connector WhatsApp sempat mati atau dipause. Port bridge kosong, proses bridge.js tidak aktif, dan log menunjukkan sesi tidak valid. Ada pesan seperti device_removed, Logged out, dan kondisi di mana gateway mem-pause WhatsApp setelah beberapa kali gagal reconnect. Artinya masalahnya berada pada lapisan koneksi, bukan pada kemampuan model menjawab.

Bagian yang paling penting adalah membedakan tiga level masalah. Pertama, model bisa saja sehat tetapi gateway tidak menerima pesan. Kedua, gateway bisa saja hidup tetapi adapter WhatsApp mati. Ketiga, adapter bisa hidup tetapi sesi WhatsApp invalid sehingga tidak bisa melakukan handshake. Kalau tiga level ini tidak dipisahkan, debugging mudah salah arah. Kita bisa mengira “Hermes tidak pintar” atau “model tidak merespons”, padahal pesan WhatsApp sama sekali tidak sampai ke agent.

Pairing QR juga memberi pelajaran tambahan. QR bisa muncul tetapi tetap gagal ditautkan. Pada beberapa percobaan, ponsel menampilkan pesan gagal menautkan perangkat, sementara sisi server mendapat timeout atau connection closed. Percobaan berulang yang terlalu cepat justru bisa memperburuk keadaan karena WhatsApp dapat menolak handshake sementara. Dalam kondisi seperti itu, strategi yang lebih aman adalah berhenti sejenak, bersihkan sesi partial, lalu pairing ulang dengan proses yang jelas.

Aturan praktisnya: Telegram adalah kanal kontrol utama yang stabil; WhatsApp adalah kanal tambahan yang berguna tetapi harus dimonitor. Jika WhatsApp tidak membalas, jangan langsung menyimpulkan agent mati. Cek proses gateway, cek proses bridge, cek log adapter, cek apakah session credential masih ada, baru ambil tindakan. Recovery yang sehat adalah backup sesi lama, reset sesi yang corrupt, pastikan dependency bridge tersedia, pairing ulang, lalu verifikasi end-to-end dengan pesan masuk dan balasan keluar.

2. Allowlist WhatsApp harus pakai identitas runtime, bukan asumsi nomor telepon

Masalah allowlist WhatsApp mengajarkan bahwa identitas yang terlihat di aplikasi pengguna belum tentu sama dengan identitas yang dipakai sistem runtime. Di aplikasi, user melihat nama kontak atau nomor lokal. Di Baileys dan gateway, pesan bisa datang sebagai nomor internasional, JID, atau LID. Jika allowlist hanya berisi format yang “terlihat benar” oleh manusia, pesan bisa tetap ditolak oleh sistem karena ID aktualnya berbeda.

Ini penting karena allowlist adalah mekanisme keamanan. Kita ingin Hermes hanya merespons pengirim yang memang diizinkan. Tetapi mekanisme keamanan yang salah format akan menimbulkan dua risiko sekaligus. Risiko pertama: user sah tidak bisa dilayani karena ID runtime tidak cocok. Risiko kedua: admin tergoda melonggarkan filter terlalu luas agar “cepat jalan”, yang bisa membuka akses ke pengirim yang tidak diinginkan.

Pembelajaran teknisnya adalah selalu ambil identitas dari log runtime, bukan dari asumsi. Saat pesan masuk, log gateway atau bridge biasanya menunjukkan pengirim aktual. Itulah nilai yang perlu masuk allowlist. Jika WhatsApp memakai LID, maka LID tersebut juga perlu dipertimbangkan. Jika memakai nomor internasional, gunakan format internasional yang sama, tanpa simbol tambahan yang tidak dipakai runtime.

Untuk sistem agent, allowlist juga sebaiknya dipisahkan berdasarkan fungsi. Ada allowlist untuk DM yang boleh dibalas. Ada allowlist group yang boleh dibaca. Ada aturan khusus bahwa group boleh diingest tetapi tidak boleh dibalas. Jika semuanya dicampur, perilaku agent menjadi sulit diprediksi: satu perubahan kecil bisa membuat Hermes tiba-tiba membalas di tempat yang tidak diinginkan.

Aturan praktisnya: saat menambah akses WhatsApp, lakukan tiga langkah. Pertama, kirim pesan uji dari akun atau group target. Kedua, baca ID aktual di log. Ketiga, masukkan ID aktual itu ke konfigurasi yang sesuai. Setelah itu, verifikasi bukan hanya “pesan masuk terlihat”, tetapi juga apakah response dikirim atau disuppress sesuai kebijakan. Untuk Basim, kebijakan pentingnya adalah DM boleh dibalas, group default read-only.

3. Group WhatsApp harus read-only secara default

WhatsApp group punya risiko sosial yang berbeda dari DM. Di DM, balasan agent biasanya hanya memengaruhi satu orang. Di group, satu balasan yang salah konteks bisa mengganggu banyak orang, memicu spam, atau membuat agent terlihat terlalu agresif. Karena itu keputusan paling aman adalah memisahkan “membaca group” dan “membalas group”. Hermes boleh mengamati group untuk membuat ringkasan, tetapi tidak otomatis menjawab di group.

Model read-only ini cocok untuk kebutuhan Basim. Group WhatsApp sering berisi diskusi panjang, link, keputusan kecil, dan konteks yang tersebar. Nilainya muncul ketika Hermes bisa menyimpan transcript lalu merangkum ke DM. Dengan begitu, user tetap mendapat manfaat: tidak perlu membaca semua pesan manual, tetapi group tidak terganggu oleh bot.

Secara teknis, read-only berarti pipeline harus punya titik suppress yang jelas. Bridge boleh menerima pesan group yang allowlisted. Gateway boleh menyimpan pesan ke session atau transcript. Cron job boleh mengambil data itu untuk diringkas. Tetapi auto-reply ke group harus ditahan kecuali ada override eksplisit. Kebijakan ini tidak boleh hanya bergantung pada “semoga model tahu jangan jawab”, karena model bekerja setelah pesan masuk ke sistem. Batas perilaku kanal harus ditegakkan di lapisan gateway atau adapter.

Ada implikasi desain yang penting: ringkasan group harus dikirim ke DM, bukan ke group. Ini sesuai preferensi Basim dan menghindari noise. Jika suatu hari perlu membuat mode balas group, sebaiknya memakai trigger eksplisit, misalnya mention bot, command tertentu, atau allowlist per group dengan mode berbeda. Tanpa trigger eksplisit, default tetap diam.

Aturan praktisnya: group adalah sumber data, bukan ruang respons otomatis. Hermes harus bisa membaca, mengarsipkan, dan menganalisis group, tetapi tidak mengubah dinamika group. Untuk ringkasan, kirim hasilnya ke chat pribadi. Untuk follow-up yang perlu dibalas ke group, minta konfirmasi manusia dulu atau gunakan perintah eksplisit yang memang dirancang untuk itu.

4. Cron job harus silent kalau tidak ada informasi penting

Cron job sangat berguna untuk membuat Hermes proaktif: merangkum group, mengecek status, memantau feed, atau mengirim update berkala. Tetapi proaktif yang buruk berubah menjadi spam. Dalam penggunaan Basim, muncul pelajaran bahwa cron tidak boleh mengirim pesan hanya untuk membuktikan bahwa ia berjalan. Jika tidak ada informasi penting, output terbaik sering kali adalah diam.

Ini terutama berlaku untuk ringkasan WhatsApp group. User tidak butuh pesan “tidak ada pesan baru” setiap interval. User juga tidak butuh update teknis seperti “checkpoint berhasil dibuat” jika tidak ada insight. Yang dibutuhkan adalah ringkasan ketika memang ada percakapan yang layak dibaca: ada keputusan, pertanyaan, link penting, perubahan rencana, atau risiko yang perlu diketahui.

Secara teknis, mode no_agent=true pada cron memberi pola yang bagus: stdout kosong berarti tidak ada delivery. Artinya script bisa dirancang sebagai filter. Ia membaca data, menentukan apakah ada konten bernilai, lalu hanya mencetak pesan jika perlu dikirim. Log operasional seperti jumlah pesan yang diproses, checkpoint, atau error ringan sebaiknya masuk stderr/log, bukan stdout yang dikirim ke user.

Ada juga pelajaran soal delivery target. origin berarti chat asal saat job dibuat, bukan selalu chat aktif sekarang. Ini penting untuk menghindari ringkasan terkirim ke tempat yang salah. Jika job dibuat dari DM Telegram, hasilnya kembali ke DM tersebut. Untuk WhatsApp group, karena preferensi Basim adalah jangan membalas group, delivery harus dipilih hati-hati dan sebaiknya diarahkan ke DM/home channel.

Aturan praktisnya: setiap cron harus punya definisi “layak kirim”. Untuk ringkasan group, layak kirim jika ada pesan baru yang substansial. Untuk monitoring, layak kirim jika ada perubahan status, error, atau threshold terlampaui. Untuk update rutin, layak kirim jika memang user meminta heartbeat. Kalau tidak, diam lebih bernilai daripada aktif tetapi mengganggu.

5. Format ringkasan group yang disukai Basim

Ringkasan group yang baik bukan sekadar memendekkan log chat. Log chat bersifat kronologis: siapa bicara apa, berurutan. Ringkasan yang berguna harus mengubah log menjadi pemahaman: topik apa yang sebenarnya dibahas, kenapa penting, siapa membawa informasi apa, keputusan apa yang muncul, risiko apa yang belum selesai, dan link mana yang perlu dibuka.

Preferensi Basim jelas: ringkasan WhatsApp group perlu lebih dalam tetapi tetap mudah dibaca. Formatnya dimulai dengan heading “Ringkasan group wa”, lalu “Group: ”. Setelah itu, topik sebaiknya bernomor dan ditulis naratif. Bukan bullet pendek yang terlalu kering, tetapi juga bukan esai panjang tanpa struktur. Narasi perlu menjelaskan konteks, detail teknis, URL jika ada, nuansa diskusi, implikasi, dan risiko.

Bagian “siapa mengatakan apa” juga penting, tetapi harus dipakai secukupnya. Tujuannya bukan membuat transkrip ulang, melainkan memberi bobot pada informasi. Jika seseorang membagikan link, sebutkan siapa dan linknya. Jika seseorang mengusulkan keputusan, jelaskan usulnya dan apakah ada respons. Jika ada perbedaan pendapat, jelaskan nuansanya tanpa melebih-lebihkan konflik.

Struktur tambahan yang wajib membantu user cepat mengambil tindakan. “Link Penting” mengumpulkan URL agar tidak tenggelam di narasi. “Pertanyaan Belum Terjawab” menunjukkan lubang informasi. “Follow Up” mengubah ringkasan menjadi daftar tindakan. “Statistik” memberi konteks volume: jumlah pesan, anggota aktif, dan anggota paling aktif jika tersedia. Statistik bukan bagian paling penting, tetapi membantu menilai apakah group sedang ramai atau sepi.

Aturan praktisnya: ringkasan harus menjawab tiga pertanyaan. Pertama, “Apa yang terjadi?” Kedua, “Kenapa ini penting?” Ketiga, “Apa yang perlu dilakukan setelah ini?” Jika ringkasan hanya menjawab pertanyaan pertama, ia masih terlalu dangkal. Jika menjawab ketiganya dengan bahasa sederhana, ringkasan menjadi alat kerja, bukan sekadar arsip.

6. Telegram topic berguna untuk memisahkan konteks kerja

Telegram topic membantu memisahkan ruang kerja. Tanpa topic, semua percakapan masuk ke satu DM: operasional server, ide konten, coding, AI news, marketing, dan percakapan santai bercampur. Bagi agent, campuran seperti ini membuat konteks mudah kotor. Perintah teknis bisa terbawa ke sesi kreatif, atau gaya marketing bisa masuk ke debugging. Topic memberi batas yang lebih bersih.

Dalam penggunaan Basim, beberapa topic punya fungsi berbeda: Operations, Social Media, Developer, AI News, Marketing, Creative Writing, dan lainnya. Ini bukan sekadar label. Setiap topic bisa membawa persona kerja yang berbeda. Developer boleh fokus pada kode, test, dan root cause. Marketing boleh fokus pada positioning, copy, dan funnel. AI News boleh menjadi radar perkembangan. Creative Writing boleh menjaga tone dan gaya.

Manfaat terbesarnya adalah konteks yang lebih tajam. Ketika user bertanya di topic Developer, Hermes bisa mengasumsikan tugasnya lebih dekat ke engineering. Ketika user menulis di topic Social Media, Hermes bisa menyesuaikan output ke format konten. Ini mengurangi kebutuhan user menjelaskan ulang niat setiap kali.

Tetapi topic juga punya risiko UX. Jika DM utama berubah menjadi lobby atau system-command-only, user bisa bingung kenapa percakapan biasa tidak berjalan seperti sebelumnya. Perubahan topic, icon, atau routing perlu diverifikasi karena Telegram Bot API bisa menolak topic ID atau menghasilkan error seperti topic invalid. Jadi topic harus diperlakukan sebagai routing layer yang perlu observability, bukan dekorasi.

Aturan praktisnya: topic bagus jika setiap topic punya fungsi yang jelas. Jangan membuat terlalu banyak topic tanpa definisi. Buat dokumen kecil berisi nama topic, tujuan, gaya respons, dan contoh tugas. Setelah mengubah topic atau icon, verifikasi lewat API/log, bukan hanya melihat UI. Dengan begitu Telegram menjadi dashboard kerja yang rapi, bukan labirin percakapan.

7. Hermes perlu selalu memverifikasi hasil, bukan hanya menjalankan command

Salah satu perbedaan penting antara chatbot dan agent adalah side-effect. Agent tidak hanya menjawab; ia menjalankan command, menulis file, memanggil API, mengubah config, menjalankan proses, dan mempublish konten. Karena itu standar laporannya harus lebih tinggi. “Saya sudah menjalankan” belum cukup. Yang penting adalah “hasilnya benar-benar terjadi dan sudah diverifikasi”.

Dalam penggunaan Basim, banyak tugas yang menuntut verifikasi nyata: cek kesehatan gateway, cek port WhatsApp bridge, cek keberadaan creds.json, cek response API, cek kuota Codex, cek publish cerita, dan cek URL publik. Setiap tugas punya bukti yang berbeda. Untuk proses, buktinya process list atau service status. Untuk file, buktinya file exists, permission, dan isi yang relevan. Untuk API, buktinya HTTP status dan response JSON. Untuk website, buktinya status page publik.

Kebiasaan verifikasi juga membantu mencegah laporan palsu. Tanpa verifikasi, agent bisa berhenti setelah membuat payload dan berkata publish berhasil padahal endpoint mengembalikan 401. Atau agent bisa restart service dan menganggap masalah selesai padahal service crash ulang. Dalam sistem produksi, tindakan tanpa verifikasi adalah separuh kerja.

Ada prinsip penting: verifikasi harus dekat dengan tujuan akhir. Jika tujuannya publish artikel, membuat file lokal belum cukup. Harus POST ke API, dapat response sukses, lalu cek URL publik. Jika tujuannya memperbaiki WhatsApp, menjalankan pairing belum cukup. Harus ada session credential, bridge aktif, inbound masuk, dan outbound terkirim.

Aturan praktisnya: setiap laporan akhir harus menyebut bukti. Bukan log panjang, cukup inti: status code, path file, process, atau URL. Jika verifikasi gagal, jangan menutupi dengan bahasa optimis. Laporkan blocker yang sebenarnya dan langkah berikutnya. Untuk Basim, gaya terbaik adalah ringkas tetapi evidence-aware: apa yang dilakukan, bukti apa yang terlihat, apa yang masih berisiko.

8. Codex/OpenAI quota bisa dicek dari endpoint penggunaan

Pengecekan kuota OpenAI Codex memberi pelajaran bahwa keberadaan credential tidak sama dengan ketersediaan quota. Credential bisa valid, tetapi limit pemakaian bisa hampir habis. Sebaliknya, CLI codex bisa tidak terpasang di PATH, tetapi Hermes tetap bisa punya credential OAuth openai-codex yang dapat dipakai untuk membaca usage melalui endpoint internal.

Dalam kasus Basim, pengecekan berhasil menampilkan status allowed, limit window 5 jam, limit mingguan, plan, dan reset time. Informasi seperti ini lebih berguna daripada sekadar “token ada”. Untuk penggunaan agent coding, quota adalah resource operasional. Jika quota habis di tengah pekerjaan besar, agent bisa berhenti pada saat yang buruk. Karena itu pengecekan usage perlu dilakukan sebelum task berat, bukan setelah gagal.

Ada dua jenis window yang perlu dipahami. Window pendek menunjukkan pemakaian dalam periode beberapa jam. Ini relevan untuk sesi intensif. Window mingguan menunjukkan batas yang lebih besar, relevan untuk planning beberapa hari. Jika window pendek hampir habis, strategi bisa diubah: tunda task besar, gunakan model/provider lain, atau pecah pekerjaan. Jika window mingguan hampir habis, perlu prioritas lebih ketat.

Pembelajaran lainnya adalah jangan bergantung pada satu interface. Jika CLI tidak terpasang, masih mungkin ada API atau credential pool yang bisa dicek. Jika endpoint usage berubah, perlu fallback ke auth list, logs, atau provider dashboard. Agent harus membedakan “tidak bisa mengecek” dari “quota aman”.

Aturan praktisnya: sebelum menjalankan pekerjaan coding panjang dengan Codex, cek usage. Laporkan persen terpakai, sisa perkiraan, dan reset time. Jika data tidak bisa dibaca, katakan tidak bisa diverifikasi. Jangan mengarang sisa kuota dari asumsi plan. Untuk keputusan teknis, status quota harus berbasis response nyata.

9. Creative/social writing perlu dibuat natural dan sesuai platform

Tugas creative writing dan social writing menunjukkan bahwa output agent tidak cukup benar secara informasi; ia juga harus cocok dengan platform dan rasa manusia. Untuk Threads, misalnya, tulisan harus pendek, modular, dan punya hook yang jelas. Jika terlalu formal, terasa seperti brosur. Jika terlalu teknis, pembaca umum hilang. Jika terlalu salesy, trust turun.

Preferensi Basim untuk konten product/project engineering cenderung natural: mulai dari problem nyata, bukan klaim kosong. Narasi seperti “banyak ide bagus mati bukan karena idenya jelek, tapi karena eksekusinya tidak rapi” lebih kuat daripada “kami menyediakan jasa terbaik”. Ini membawa pembaca masuk lewat pengalaman yang mereka kenal. Setelah itu baru dijelaskan bagaimana Basim membantu: merapikan scope, membuat MVP, memperbaiki sistem, menghubungkan ide bisnis dengan eksekusi teknis.

Setiap platform punya batas dan ritme. Threads membutuhkan potongan pendek yang tetap mengalir. WhatsApp broadcast mungkin perlu lebih personal. Artikel blog bisa lebih reflektif dan panjang. Telegram bisa lebih langsung. Karena itu satu pesan tidak seharusnya dipakai mentah-mentah di semua kanal. Agent perlu menulis ulang sesuai medium.

Ada juga pelajaran tentang voice. Basim membutuhkan tulisan yang terlihat punya pengalaman, bukan template AI. Itu berarti menghindari frasa generik, klaim terlalu besar, dan struktur yang terlalu simetris. Tulisan yang bagus boleh punya kalimat pendek, contoh konkret, dan sedikit ketidaksempurnaan manusia. Yang penting tetap jelas dan tidak berlebihan.

Aturan praktisnya: untuk konten sosial, mulai dari masalah nyata, lanjutkan dengan insight, beri contoh, lalu tutup dengan ajakan yang ringan. Jangan hard selling terlalu cepat. Untuk Threads, pecah ide menjadi beberapa post yang masing-masing punya satu fungsi. Untuk artikel, beri konteks dan pelajaran. Untuk semua format, jaga agar tulisan terasa seperti Basim berbicara, bukan seperti landing page generik.

10. Persona “Meisya” dan identitas bot

Identitas bot bukan detail kecil. Foto profil, nama, dan gaya bahasa memengaruhi cara user merasakan komunikasi. Ketika bot Telegram diberi persona “Meisya”, itu bukan hanya kosmetik; itu membentuk ekspektasi. User bisa merasa sedang berinteraksi dengan asisten yang punya karakter tertentu, bukan mesin tanpa wajah.

Tetapi identitas visual juga perlu dikelola dengan standar teknis. Setelah mengganti foto profil Telegram, UI aplikasi bisa cache foto lama. Karena itu verifikasi tidak cukup dengan melihat satu layar. Perlu cek API seperti profile photos, cek apakah file yang dikirim benar, dan tunggu kemungkinan delay cache. Jika media dibuat lewat image generation, hasilnya harus dilihat dulu sebelum dipakai sebagai foto profil.

Persona juga harus konsisten dengan fungsi. “Meisya, Menteri Komunikasi dan Digital” memberi nuansa tertentu: komunikatif, rapi, strategis, dan sedikit formal. Namun persona tidak boleh mengalahkan preferensi utama user. Jika user meminta analisis tajam, jawaban tetap harus kritis. Jika user meminta status singkat, jangan berubah menjadi teatrikal. Persona adalah lapisan gaya, bukan pengganti akurasi.

Ada risiko jika identitas bot terlalu “hidup” tanpa batas. Agent bisa terdorong untuk roleplay ketika yang dibutuhkan adalah eksekusi. Karena itu perlu membedakan mode: kadang cukup sapaan dan tone; kadang perlu persona penuh; kadang harus netral teknis. Untuk pekerjaan server, persona sebaiknya tidak mengganggu bukti dan langkah kerja.

Aturan praktisnya: identitas bot boleh dibuat hangat dan khas, tetapi output tetap harus sesuai konteks. Foto profil harus diverifikasi. Perubahan identitas harus diuji di platform. Persona boleh memperhalus komunikasi, tetapi untuk keputusan penting, prioritasnya tetap evidence, risiko, dan kejelasan.

11. System prompt, rules, agent, dan MCP harus disiapkan di awal

Diskusi tentang setup rules, agent, MCP, linting, dan automation menunjukkan bahwa kualitas pekerjaan agent sangat dipengaruhi oleh persiapan awal. Agent coding yang diberi akses besar tanpa aturan mudah overengineering, mengganti terlalu banyak file, atau berhenti sebelum verifikasi. Sebaliknya, agent dengan rules yang jelas bisa bekerja lebih hemat token dan lebih konsisten.

System prompt dan rules berfungsi seperti SOP. Ia menetapkan gaya kerja: gunakan tools, verifikasi hasil, jangan mengarang output, jangan membalas WhatsApp group, simpan rahasia di .env, dan sebagainya. Tanpa SOP, setiap sesi harus mengulang instruksi yang sama. Dengan SOP, Basim tidak perlu terus mengingatkan hal-hal dasar.

MCP dan tool integration juga perlu dipilih dengan sadar. Terlalu sedikit tool membuat agent tidak bisa bertindak. Terlalu banyak tool membuat konteks berat dan risiko salah pakai meningkat. Tool yang baik adalah tool yang jelas gunanya, punya credential aman, dan bisa diverifikasi. Jika sebuah workflow sering dipakai, lebih baik dibuat skill atau script daripada selalu dilakukan manual dari nol.

Linting dan testing adalah pagar untuk pekerjaan coding. Agent bisa menulis kode yang tampak benar tetapi gagal test. Karena itu rules seperti “jalankan test yang relevan”, “cek diff”, “jangan berhenti di stub”, dan “laporkan blocker” sangat penting. Untuk task besar, plan juga membantu agar pekerjaan tidak melebar.

Aturan praktisnya: sebelum project besar, siapkan empat hal. Pertama, rules perilaku agent. Kedua, akses tool dan credential yang diperlukan. Ketiga, definisi sukses dan cara verifikasi. Keempat, batas scope agar agent tidak overbuild. Persiapan ini terasa lambat di awal, tetapi menghemat banyak waktu saat eksekusi.

12. Hal yang masih perlu dibereskan

Beberapa hal masih perlu dirapikan agar sistem lebih tahan lama. Pertama, dokumentasi recovery WhatsApp perlu dijadikan playbook. Saat WhatsApp putus, langkahnya sudah terbukti: cek log, backup session, reset session, fix dependency, pairing ulang, verifikasi. Jika playbook ini tersedia, recovery berikutnya lebih cepat dan tidak bergantung pada ingatan sesi.

Kedua, ringkasan group perlu checkpoint yang jelas. Jika cron berjalan berkala, ia harus tahu pesan mana yang sudah diringkas. Tanpa checkpoint, ada risiko ringkasan duplikat atau pesan lama terlewat. Jika suatu hari perlu replay data lama, sistem juga harus punya mode khusus agar tidak mengacaukan checkpoint produksi.

Ketiga, taxonomy Telegram topic perlu distandarkan. Topic yang terlalu banyak tanpa definisi akan membuat user bingung. Dokumen kecil yang menjelaskan fungsi tiap topic, persona, contoh penggunaan, dan delivery rule akan membuat Telegram menjadi workspace yang lebih efektif.

Keempat, alur publish cerita perlu punya endpoint update yang jelas. Saat ini publish via admin API berhasil, tetapi route publik yang aktif adalah /cerita/d/<slug>. Jika ingin mengedit artikel yang sama berkali-kali, idealnya ada endpoint update/upsert resmi atau dokumentasi apakah POST dengan slug sama akan overwrite, create revision, atau gagal duplicate.

Kelima, keamanan token harus terus dijaga. Token admin cerita sudah disimpan sebagai environment variable privat, tetapi tidak boleh masuk artikel publik, log yang dikirim ke chat, atau payload yang tidak perlu. Setiap automation yang memakai token harus membaca dari .env dan meredaksi output.

Aturan praktisnya: setelah sistem bisa berjalan, tahap berikutnya adalah membuatnya repeatable. Semua hal yang pernah rusak dan berhasil diperbaiki perlu masuk playbook. Semua job berkala perlu checkpoint. Semua kanal perlu aturan. Semua publish flow perlu verifikasi URL. Dengan begitu Hermes tidak hanya bisa membantu hari ini, tetapi makin kuat untuk pekerjaan berikutnya.

Penutup

Penggunaan Hermes bersama Basim menunjukkan pola yang jelas: agent terbaik bukan yang paling banyak bicara, tetapi yang paling bisa dipercaya. Bisa dipercaya berarti tahu kanal mana yang boleh dibalas, tahu kapan harus diam, bisa memverifikasi hasil, menjaga rahasia, dan punya prosedur recovery saat integrasi rusak.

Telegram cocok sebagai pusat kontrol. WhatsApp berguna sebagai kanal ingest dan DM, tetapi perlu diperlakukan hati-hati. Cron membuat agent proaktif, tetapi harus silent jika tidak ada hal penting. Ringkasan harus naratif dan actionable. Publishing harus diverifikasi sampai URL publik. Semua ini membentuk satu prinsip besar: agent lintas kanal harus dikelola seperti sistem produksi kecil, bukan sekadar bot chat.