Blueprint Meeting Agent: Dari Calendar sampai Telegram

Panah paling penting dalam blueprint bukan yang menghubungkan dua aplikasi. Panah paling penting adalah titik ketika agent tidak boleh lanjut.

Bayangkan satu diagram lurus: Calendar event masuk, notes dibaca, summary dibuat, action items dikirim ke Telegram, lalu memory diperbarui. Dari jauh, kelihatannya clean. Namun, diagram itu belum menjawab siapa yang mengonfirmasi waktu, apa yang terjadi ketika PIC tidak jelas, dan apakah agent boleh broadcast tanpa review.

Karena itu, blueprint Meeting Operations Agent bukan daftar integrasi. Ia adalah peta keputusan, termasuk titik ketika manusia perlu mengambil alih.

Blueprint ini menjadi target build di workshop Building AI Employees pada Sabtu, 5 September 2026, pukul 08.30-11.00 WIB via Zoom. Sistemnya dirancang untuk dibangun dan diuji dalam sesi; ini bukan laporan hasil production.

Target Flow secara Utuh

Alur yang direncanakan bergerak seperti ini:

Calendar event -> sample Fathom notes -> summary dan action items -> mind map -> preview -> human approval -> Telegram -> selective memory.

Setiap panah menyimpan aturan. Tanpa aturan tersebut, panah hanya membuat diagram terlihat lengkap.

Calendar event memberi context tentang meeting. Sample notes menjadi sumber isi. Agent menyusun output terstruktur. Mind map membantu melihat hubungan topik. Preview memberi ruang pemeriksaan. Approval menjadi izin sebelum action eksternal. Telegram menerima hasil yang sudah disetujui. Memory hanya menyimpan informasi yang memang berguna untuk pekerjaan berikutnya.

Urutan ini adalah blueprint. Detail implementasi dapat berubah ketika diuji terhadap tool, credential, format data, dan behavior aktual di environment.

Calendar Bukan Sumber Kebenaran untuk Semua Hal

Calendar bisa memberi judul, waktu, peserta, dan deskripsi jika field tersebut tersedia. Ia tidak otomatis menjelaskan semua konteks meeting.

Kalau tanggal atau jam belum dikonfirmasi, agent tidak boleh memilih sendiri hanya supaya event berhasil dibuat. Kalau daftar peserta tidak lengkap, workflow perlu meminta klarifikasi atau menandai bahwa informasi belum tersedia. Kalau event sudah ada, agent juga perlu tahu apakah tugasnya membaca, mengusulkan perubahan, atau mengedit langsung.

Perbedaan ini menentukan permission. Read access cukup untuk mengambil context. Draft access dapat dipakai untuk membuat preview. Write access memungkinkan perubahan nyata dan membawa risiko lebih tinggi.

Blueprint yang sehat menyebutkan level action tersebut secara eksplisit. Label "terhubung ke Calendar" saja terlalu broad.

Notes Menjadi Sumber, Bukan Alasan untuk Mengarang

Sample Fathom notes dipakai sebagai bahan untuk summary, keputusan, dan action items.

Agent perlu memisahkan apa yang benar-benar tertulis dari apa yang belum diputuskan. Kalimat seperti "Rina akan follow up hari Jumat" dapat menjadi action item jika notes mendukungnya. Sebaliknya, kalau notes hanya menyebut "perlu follow up" tanpa PIC dan deadline, agent tidak boleh mengisi nama atau tanggal berdasarkan tebakan.

Output dapat memakai label seperti PIC belum ditentukan atau Deadline perlu konfirmasi. Alternatif lain adalah membuat daftar pertanyaan sebelum workflow lanjut.

Ini mungkin membuat output terlihat kurang otomatis. Justru itu point-nya. Ketidakpastian yang terlihat lebih aman daripada tabel lengkap yang isinya sebagian fabricated.

Summary dan Action Items Punya Job Berbeda

Summary menjawab apa yang dibahas dan diputuskan. Action items menjawab siapa melakukan apa dan kapan, sejauh informasinya tersedia.

Kalau keduanya dicampur, reviewer susah melihat mana context dan mana commitment. Blueprint dapat menetapkan struktur output yang konsisten, misalnya:

1. ringkasan pembahasan;
2. keputusan yang tercatat;
3. action items dengan PIC dan deadline;
4. informasi yang masih belum lengkap;
5. pertanyaan atau risiko yang perlu ditindaklanjuti.

Struktur bukan jaminan bahwa isi pasti benar. Ia membuat output lebih mudah diperiksa dan dievaluasi terhadap sumber.

Mind Map Membantu Navigasi, Bukan Mengganti Sumber

Mind map dapat merangkum hubungan antara keputusan, pekerjaan lanjutan, owner, dan isu terbuka. Format visual berguna ketika meeting membahas beberapa stream sekaligus.

Namun, mind map tetap merupakan representasi dari notes. Kalau satu node tidak dapat ditelusuri kembali ke sumber, reviewer perlu mempertanyakannya. Kalau visual menghilangkan qualifier penting, output juga perlu diperbaiki.

Dalam blueprint, mind map berada sebelum approval agar manusia dapat memeriksa apakah grouping dan relasinya masuk akal. Ia bukan bukti bahwa meeting telah dipahami secara sempurna.

Approval adalah Batas sebelum Telegram

Telegram merupakan external action. Begitu pesan dikirim ke grup, konsekuensinya tidak lagi berada di ruang draft.

Karena itu, target flow menampilkan preview sebelum broadcast. Reviewer dapat memeriksa summary, action items, missing information, dan tujuan channel. Ia bisa approve, meminta revisi, atau menolak pengiriman.

Rule setelah penolakan juga perlu jelas. Agent dapat kembali membuat draft berdasarkan feedback, menyimpan status sebagai rejected, atau menghentikan flow. Yang tidak boleh terjadi adalah menganggap tidak ada respons sebagai izin.

Approval yang hanya berupa kotak di diagram belum cukup. Implementasi perlu memastikan tool Telegram tidak dipanggil sebelum status approval valid.

Selective Memory Menutup Flow

Setelah pengiriman, bukan berarti seluruh transcript harus masuk ke long-term memory.

Memory dipilih berdasarkan kebutuhan retrieval berikutnya. Informasi yang mungkin berguna mencakup keputusan aktif, follow-up, PIC, deadline, masalah terbuka, serta preferensi format yang memang stabil. Small talk, duplikasi, dan detail sensitif yang tidak diperlukan sebaiknya tidak disimpan secara default.

Blueprint juga perlu menyebutkan kapan memory dapat diperbarui atau dikoreksi. Kalau keputusan berubah, retrieval tidak boleh terus mengangkat versi lama tanpa context.

Selective memory membuat penyimpanan menjadi keputusan desain. Tujuannya bukan mengingat sebanyak mungkin, tetapi mengambil informasi yang tepat ketika dibutuhkan.

Jalur Gagal Harus Terlihat di Peta

Happy path hanya satu bagian dari workflow.

Notes bisa gagal dibaca. Calendar event bisa tidak ditemukan. Mind map tool bisa error. Telegram bisa menolak request. Approval bisa tertunda. Setiap kondisi membutuhkan respons yang proporsional.

Agent dapat berhenti dan melaporkan error, menyimpan draft untuk retry, atau meminta input tambahan. Ia tidak boleh menyamarkan tool failure dengan mengklaim action sudah berhasil.

Ketika error path dimasukkan ke blueprint, tim bisa melihat perbedaan antara kegagalan yang aman dan kegagalan yang meninggalkan state setengah jadi.

Cara Membaca Blueprint untuk Use Case Lo

Lo tidak perlu memakai Calendar, Fathom, mind map, Telegram, dan Hermes untuk mendapatkan manfaat dari pola ini.

Ambil workflow lo sendiri, lalu tandai:

• event yang memulai pekerjaan;
• sumber data yang dianggap valid;
• transformasi yang dilakukan;
• output yang perlu diperiksa;
• action yang mengubah sistem atau menghubungi orang;
• titik approval;
• data yang layak disimpan;
• serta respons ketika input atau tool gagal.

Kalau diagram lo hanya berisi nama aplikasi, berarti layer keputusan belum kelihatan.

Di Building AI Employees, lo akan membedah blueprint Meeting Operations Agent lalu menerjemahkannya menjadi target build dengan Hermes.

Lo akan memetakan perpindahan data, titik approval, dan batas tindakan dari Calendar sampai Telegram.

Lihat detail Building AI Employees.

Tools membuat agent mampu bergerak dari Calendar sampai Telegram. Boundary memastikan setiap perpindahan masih berada di jalur yang lo maksud.