Mendesain Meeting Operations Agent

Call selesai bukan berarti pekerjaan meeting selesai. Justru setelah layar ditutup, keputusan, PIC, dan follow-up paling mudah tercecer.

Keputusan masih tercecer di transcript. Action items belum tentu punya PIC. Deadline bisa disebut sambil lalu, atau tidak disebut sama sekali. Seseorang perlu merapikan semua itu, membuat format yang mudah dipindai, meminta konfirmasi, lalu membawa hasilnya ke channel tempat tim bekerja.

Karena itu, Meeting Operations Agent yang sedang gue desain tidak berhenti di “ringkas meeting”. Summary hanya satu bagian. Job utamanya adalah membawa bahan meeting sampai menjadi follow-up yang dapat direview dan dijalankan.

Saat ini flow tersebut masih berupa blueprint. Implementasinya direncanakan untuk dibangun live di workshop Building AI Employees. Jadi artikel ini membahas desain dan batasnya, bukan hasil dari sistem yang sudah berjalan di production.

Tentukan Job Sebelum Memilih Platform

Meeting agent mudah melebar. Hari ini diminta merangkum, besok membuat calendar event, lalu mengirim reminder, memperbarui project board, dan menjawab pertanyaan dari seluruh transcript.

Supaya tidak berubah menjadi asisten serba bisa tanpa batas, job perlu ditulis secara spesifik.

Versi kerja yang sedang dipakai adalah: menerima informasi meeting yang sudah dikonfirmasi dan sample notes dari Fathom, memisahkan summary, keputusan, dan action items, menandai informasi yang tersedia, membuat preview, lalu mengirim hasil ke Telegram setelah approval.

Definisi ini memberi tiga batas penting.

Pertama, agent memproses sumber yang ditentukan, bukan mencari sendiri semua data di organisasi. Kedua, ia mengekstrak informasi yang tersedia, bukan melengkapi field dengan tebakan. Ketiga, pengiriman adalah action setelah approval, bukan default otomatis.

Flow yang Sedang Dirancang

Blueprint-nya terdiri dari delapan tahap yang saling terhubung.

1. Membuat event dari informasi yang sudah dikonfirmasi

Calendar event hanya boleh menggunakan tanggal, waktu, peserta, dan agenda yang tersedia. Kalau ada detail yang belum jelas, flow perlu meminta klarifikasi atau menandainya. Agent tidak memilih waktu sendiri agar form terlihat lengkap.

2. Memproses sample meeting notes dari Fathom

Notes menjadi input utama untuk tahap ekstraksi. Sumbernya perlu jelas supaya tim dapat memeriksa dari mana sebuah keputusan atau action item berasal. Transcript atau notes tidak otomatis dianggap sempurna, jadi ambiguity tetap harus kelihatan.

3. Memisahkan summary, keputusan, dan action items

Tiga jenis informasi ini punya fungsi berbeda. Summary memberi konteks. Keputusan mencatat hal yang sudah disepakati. Action items menunjukkan pekerjaan berikutnya.

Kalau semuanya dicampur menjadi satu paragraf, follow-up sulit dipindai. Struktur output perlu membantu reviewer melihat apakah ada keputusan tanpa action, action tanpa PIC, atau topik yang masih terbuka.

4. Menandai PIC dan deadline yang tersedia

Kata kuncinya adalah “yang tersedia”. Agent boleh mengekstrak PIC dan deadline yang disebutkan. Ia tidak boleh mengarang detail agar tabel terlihat rapi.

Field kosong dapat diberi label Belum ditentukan dan dimasukkan ke daftar klarifikasi. Output seperti itu lebih jujur dan lebih berguna daripada tanggal yang plausible tetapi tidak pernah disepakati.

5. Mengubah action plan menjadi mind map

Mind map direncanakan sebagai cara melihat hubungan antara keputusan, pekerjaan, owner, dan follow-up. Format visual ini bukan pengganti sumber. Ia adalah representasi dari action plan yang sudah diekstrak.

Artinya, informasi di mind map harus tetap tunduk pada data yang sama. Format baru tidak memberi izin untuk menambah hubungan atau prioritas yang tidak disebutkan.

6. Menampilkan preview dan meminta approval

Preview perlu menunjukkan output yang akan dikirim, tujuan pengiriman, serta field yang belum pasti. Reviewer seharusnya dapat memperbaiki atau menolak sebelum action terjadi.

Approval tidak ditempatkan di setiap langkah. Agent dapat membaca, memisahkan, dan memformat data tanpa menunggu klik manusia terus-menerus. Checkpoint ditempatkan sebelum hasil menjadi komunikasi keluar.

7. Mengirim ke Telegram setelah disetujui

Telegram adalah destination yang direncanakan untuk demo flow. Pengiriman hanya berjalan setelah approval. Kalau approval belum ada, statusnya tetap preview.

Rule ini membedakan draft generation dari external action. Model boleh capable menghasilkan pesan, tetapi workflow-lah yang menentukan kapan pesan boleh dikirim.

8. Menyimpan keputusan dan follow-up yang masih relevan

Tidak semua bahan meeting perlu masuk memory permanen. Keputusan yang masih aktif, action item terbuka, PIC, deadline, dan masalah yang perlu ditinjau dapat berguna untuk pekerjaan berikutnya.

Transcript lengkap tidak otomatis perlu dipertahankan sebagai memory. Penyimpanan dan retrieval perlu dirancang berdasarkan kegunaan, sensitivitas, dan masa berlaku informasi.

Satu Flow, Banyak Komponen Agent

Blueprint ini sengaja dipilih karena menyentuh banyak komponen penting dalam satu pekerjaan yang relatable.

Context menentukan informasi yang dibutuhkan di tiap tahap. Instructions menjelaskan cara memisahkan keputusan dan action items. Tools menghubungkan calendar, notes, mind map, dan Telegram. Permission membatasi data serta action. Approval menjaga pengiriman tetap berada di bawah tanggung jawab manusia.

Memory membawa informasi terpilih ke pekerjaan berikutnya. Error handling menentukan apa yang terjadi ketika notes kosong, field tidak lengkap, atau tool gagal. Evaluation mendefinisikan apakah output akurat, lengkap sesuai sumber, dan benar-benar terkirim hanya setelah approval.

Komponen-komponen ini tidak berdiri sendiri. Permission yang baik bisa rusak oleh instruction yang menyuruh agent “selalu lengkapi semua field”. Approval yang baik tidak membantu kalau preview tidak menampilkan uncertainty. Memory yang rapi bisa tetap berbahaya kalau retrieval memuat informasi lama tanpa seleksi.

Itulah kenapa desain flow perlu dibaca end-to-end.

Happy Path Saja Tidak Cukup

Di whiteboard, flow sering terlihat linear: input masuk, agent memproses, output terkirim. Kondisi nyata lebih banyak cabangnya.

Bagaimana kalau meeting notes tidak tersedia? Bagaimana kalau dua orang disebut sebagai PIC untuk action yang sama? Bagaimana kalau deadline berbunyi “minggu depan” tanpa tanggal referensi yang clear? Bagaimana kalau Telegram gagal menerima pesan setelah approval?

Blueprint perlu memberi respons untuk masing-masing kondisi. Agent dapat berhenti dan meminta input, menandai konflik, memberi label belum ditentukan, atau menyimpan status gagal untuk dicoba ulang sesuai aturan. Yang tidak boleh dilakukan adalah menyembunyikan masalah dengan output yang terdengar confident.

Desain Dulu, Baru Build

Tool memang penting, tetapi tool tidak menentukan batas tanggung jawab. Hermes atau platform lain dapat membantu mengimplementasikan workflow. Ia tidak otomatis menjawab sumber mana yang valid, kapan manusia harus masuk, atau field mana yang tidak boleh diasumsikan.

Makanya blueprint dikerjakan sebelum build. Tim dapat menguji logika di atas kertas: trigger-nya jelas atau tidak, input wajibnya apa, output-nya untuk siapa, action mana yang reversible, dan bagaimana status gagal terlihat.

Kalau desain ini masuk akal, implementasi menjadi lebih terarah. Kalau desainnya masih kabur, menambah integrasi biasanya hanya membuat kekaburannya berjalan lebih cepat.

Meeting Operations Agent ini direncanakan untuk dibangun live sebagai bagian dari workshop Building AI Employees. Flow yang dijelaskan adalah target blueprint saat ini dan masih perlu diuji saat implementasi.

Kalau lo ingin melihat proses dari blueprint sampai workflow yang bisa diuji, detail kelasnya ada di sini:

https://goakal.com/ai-builders-id/building-ai-employees

Ringkasan yang rapi baru langkah antara. Meeting selesai ketika keputusan dan tindak lanjutnya punya bentuk yang bisa diperiksa dan dipertanggungjawabkan.